On being a dev team manager: Lessons learned from different managers I have had

I’m not huge on clickbait lists of “Top five habits of good managers” and this post is a little bit… like that…. so I am sorry 😬. But I’m writing it because I am a manager of people and I have also been managed by a variety of people and I often think about what I learned from each of them and how it has shaped me as a leader, or just changed how I think about leadership in general.

I also imagine that different people with different experiences would have a completely different list! So I’m curious, after reading this, if you agree or disagree or think I missed out anything super important. And tell me in the comments!

On coaching new developers and setting them up for success with their first projects.

I’ll never forget when I started a new job as a fairly inexperienced developer and for my first task, my boss carefully laid out for me

• what I needed to build
• exactly how it needed to behave
• what files I should take a look at before I got started
• a general overview of how the app worked and what the hierarchy was, file-wise

It was the perfect mix of hand-holding without micromanaging. There was enough room for me to solve the problem on my own, but enough structure that I wasn’t floundering.

As I grew over time, their approach with me changed, and I slowly got less and less direction and more and more autonomy to make my own decisions on how to architect solutions.

I think their approach was fantastic and it’s something I try to emulate when we hire junior developers.

Forget about blame, focus on solutions

I once caused a major bug on production. I was horrified. My boss looked chagrined and said, “Yes it sucks but I’m even more to blame than you, because I didn’t catch it when I reviewed your work, and I’m supposed to be the experienced one.”

I definitely took this to heart and feel the same way with any of the developers that I manage. We all are responsible for making sure production is stable, and no mistake lays on one person’s shoulders.

When something goes wrong, in my opinion it’s best to completely avoid mentioning who you feel like should be blamed (and yes, we are all human, it’s easy to roll your eyes and want to blame the person who wrote the code. RESIST THE URGE. In addition to not being solely responsible, they are also already beating themselves up internally.), and instead just focus on the problem itself and how to fix it/make sure it doesn’t happen again.

Celebrate successes by name

The opposite of blame! My absolute favourite thing to do is to post in our company chat whenever something ships, and make sure I include the names of the people involved in building it. If you are a manager and you were also involved, in my opinion you should downplay your own role. Celebrate your developers, there’s nothing to be gained by trying to upstage them.

It’s ok to redo work. It’s good for improved quality, and it’s good for learning.

I was once asked by my boss to re-write a feature 3 different times using 3 different approaches.

It was a complicated feature that could be solved in many ways. The first attempt was my own solution, the second was a solution that we came up with together, and the third was when my boss looked at how I had interpreted our “solution” and was like, “um that’s not exactly what I had in mind when we discussed this.” And so I had to then re-do the third time.

It was frustrating having to scrap and start over, but I was extremely proud of the finished product in the end, and it still works quite well to this day, many years later!

Saying no and saying yes

I once had an engineering manager who was very scrappy and more than happy to push back on anything that they felt was a bad decision from a performance/technical architecture point of view. I liked it because it made me feel very protected, knowing that my boss was keeping the designers and product managers from forcing us to build “bad” things.

Then I had a manager who was a bit more pragmatic. “One thing some devs do,” they told me, "is to say no too often. Almost anything is possible, you just need to think about it carefully and find the right solution.”

I think about this a lot. Whenever I’m asked if we can build something that intimidates me, I don’t generally say “no” up front. Instead I say something like, “Interesting, let me think about how we might build that and get back to you.”

Sometimes, in the end, even if it’s possible, it’s not advisable given time (or other) constraints. But it’s always worth considering and thinking through. I’m actually surprised by how often something that seems scary at first ends up being 100% doable, given more serious consideration. And often even if the original proposed feature doesn’t make sense, by thinking it over you can usually come up with reasonable alternatives that make everybody happy.

Kindness is so important

I have had a lot of terse and intimidating dev bosses. I have had bosses who were generally very happy with me and my work, but occasionally left cutting code reviews that would be so harsh I’d go home and cry that night. Don’t get me wrong: I liked these bosses. They were smart and organized and capable, and generally we got along very well! We’d go out for beers after work and had genuine friendships. But they were not warm and fuzzy.

Then one day I had a boss who was the total opposite. Compassionate and thoughtful. They instituted a culture of one-on-one chats in which we focused on how I was doing, how I was feeling, what I needed, what my concerns were.

It was a total 180 from what I was used to, and it taught me a lot about the value of kindness in a manager.

You can provide constructive criticism and be kind at the same time.

My favourite bosses are the ones who seem like they are in control

I want to trust that I can rely on my boss and not worry about them dropping the ball. I want to feel like they know what they’re doing, they know what the team is doing, they understand the big picture, and they aren’t asking anything of the team that is beyond what is possible for that team. I like bosses that seem calm and even-keel. If there’s a huge deadline looming, I feel a lot better if my boss seems zen about the situation. Zen doesn’t mean apathetic or disengaged. Just capable of keeping calm and focused and not causing the team needless extra stress during a stressful time.

You don’t have to be a closed book

I am a big believer in being candid and open with my team. The only thing that I think is off-limits is speaking poorly of others on the team/at the company. And of course not talking about anything that is confidential 😛

You can make mistakes, just own them

Apologize to your team when you mess up. Then move on and do better next time.

Be an advocate for your team

The people on your team are your responsibility, and should be your number one priority. Be loyal to them.

Fin. For now. Until someone comments with another great point that I forgot 😁

Reading this over it actually makes me think: These are all the qualities I try to embody as a manager, but I know there are areas where I fall short sometimes. Sometimes I am a better manager than other times. I find when I’m feeling overwhelmed I begin to slip and not be the kind of manager I want to be.

A better manager than I can probably compartmentalize this and continue to be excellent. Maybe that’s something I can strive towards in the future.

But I also think it’s ok to show a little self-compassion. We are all human. We are not perfect. Be the best you can be, and take care of yourself too.