When I first became a development manager, I knew it was important to find my own approach to how I wanted to operate as a leader. Through trial and error, books, blogs, and mistakes, I eventually came into my own as a manager. I'm not going to pretend to have all the answers, but here are some things I tried that worked for me.
People management
The biggest flaw that I think managers make is not realizing that humans are involved. What motivates some may not motivate others, and it is my job to crack the code of what motivates the individuals on the team. Some are motivated by learning new things or feeling like they are a part of a team that does great work, while others are motivated by the projects they work on and the visibility that it affords.
Continuing education and project work
I wanted to show my team that I was invested in them. The way I did this was to leverage my passion for teaching and mentorship and apply this to our interactions. Because I have a Master's degree in Education, this gave me something of value that I could offer that not many other managers could.
Each member of my team assembled an individualized continuing education plan. The topics each individual chose to study was up to them. I then helped each person plot a roadmap to learn the things contained in the initial draft of the plan.
I felt it was vital to give each person the ability to come up with the initial draft without prompts that would steer the ship too much in one direction. This helped make sure that it was the individual's plan and not MY plan for the individual.
Seeing topics on their plan that weren't related to their job was as telling as the ones that were. It was also a good tool for me to see what their ambitions were, as well as establish a relationship of trust with members of the team. I could look for opportunities for them to start getting into these new areas if it was in line with the technical direction or projects.
Things that were omitted from the list but were part of their job function became topics of conversation. Maybe they felt like they knew a topic well enough already, but maybe they hated doing whatever it was and hadn't said anything. There were many helpful insights that came from this exercise.
Work visibility
My first foray as manager was at a media company who was going through a digital transformation. Since the overall direction of the company involved modernizing a traditional print business, development was heavily involved, and there were plenty of opportunities for my team to get recognition.
When we completed a big chunk of development or project, the project management team would send out an email. I made sure to provide information prior to the email so the project manager knew who to mention, as well as special callouts for cases where an individual really did something remarkable.
Involvement in decisions
I found that multiple perspectives were helpful in decision-making and often found myself soliciting the opinion of those who reported to me. Not everyone in the room has to be a senior staff member either. I got many great ideas and contributions from junior developers that were instrumental in our success as a team.
I found the approach from DynDNS innovative where they rank projects with an algorithm to assess priority and impact.
Salaries
If a person is happy with the type of work they do and the recognition they receive, that's a good reason to stay, but you can't discredit salary.
Unfortunately, salaries are often beyond the manager's control, and I think it's incredibly short-sighted of companies to not have a retention budget or say "let us know if you're looking" so they can try to keep their staff.
If there's a person on your team who is earning below their market value and you're happy with their work, it makes sense to try to keep them before they leave for other opportunities. Review the salaries on your team and fight for your people.
Frame it as business continuity and risk management. It doesn't always work, but maybe you'll be successful and be able to keep the team intact for longer and prevent knowledge from walking out the door.
Outside the team
The challenges as a new manager went beyond team leadership. There's also the management of processes, risk, and deliverables. Organizationally, it was difficult to get people to see my team as experts and partners instead of task executors. This realization helped me learn to ask the right questions. These questions included:
- What are the obstacles to doing X?
- What patterns can we identify to streamline the process?
- Is this request congruent to current product offerings or is it a new model that requires a new way of thinking?
- What is the business reason behind a project and how does it benefit our organization?
It was helpful information for the project to make sure we were building the right thing but also gave information to help learn more about the business. The questions also resulted in opportunities for suggestions, built our perception as experts, and established trust.
Maker time vs. manager time
When you're a manager, you have less time to contribute as an individual, so you need to get better at prioritization.
No, I won't just work more hours. I strive for work/life balance and want members of my team to do the same.
One of the first books I read after becoming a manager was Leading Snowflakes by Oren Ellenbogen. In the book, he talks about maker vs. manager time. As my calendar started filling up with new meetings, I began scheduling maker time on my calendar. This was a two-hour, daily block of time when I could work on whatever I needed without someone trying to schedule a meeting on top of it.
In the manager time, I keep meetings to a minimum. I use a lot of video messages and screencast demos. It keeps communication personal and frequent, but it also makes it async.
If an update can be an email, it is an email. I include an agenda for the meetings I schedule, and I also conduct one-on-ones with my team. Borrowing from academia, I have open office hours so people can ask questions or get help moving a project forward.
Estimates
Estimates are difficult. Mine were particularly bad as an individual contributor, but I was more accountable as a team lead. The solution for this one came from Steve McConnell's book, Software Estimation: Demystifying the Black Art. In this system, you do 3 different estimates for the work: best case, worst case, and the most likely case.
Once you do these, you use a weighted average to calculate a final number to provide. Once I did this, the accuracy of the estimates improved greatly.
Handling conflicts
Conflict is unavoidable, especially at the leadership table. You have multiple personalities who are experienced and approach a problem with their own biases and beliefs coupled with career ambition and sometimes egos.
Any time I was able to take someone's subjective belief and use data to make the argument objective, I found that this was the best way to handle the conflict. This meant that sometimes I wouldn't have the data on the spot, but unless it was an urgent decision that needed to be made right that second, most people were receptive to me saying "I'd like some time to collect data and reevaluate once we have more information."
Conclusion
Being a manager for the first time comes with a learning curve, but it was a rewarding experience for me. The most rewarding part was definitely the mentorship and watching the growth of the people on my team.