4 truths about leadership in software development I wish I knew before becoming a manager

A man standing in front of a group of colleagues holding a little shark figurine.
Sometimes you need to stand in front of people holding a small shark figurine to establish… authority?

1. There is a HUGE difference between being an individual contributor and being a manager.

If you have transitioned from the role of a single contributor (e.g. software/QA/DevOps engineer) to the role of manager, you might have gone through the frustrating journey of realising that your work’s impact is initially invisible to you. Time you invest in your work seemingly doesn’t return any instant value — instead it returns its value with a delay, multiplied by the amount of team members you successfully led forward.

  • If you’re the most senior person in a meeting, your role is not to pitch ideas —You should not be at the front coming up with ideas. Instead, you should read the room; see non-verbal cues and stop the meeting if you sense that people are confused.
  • Proposals are verbal leadership: If you have experience in a topic and you’re talking with your team about where to go next, propose where to go and decide as a team. The mental (and verbal) shift from deciding to proposing what to do next will empower your team to grow decision-makers and stop relying on your limited expertise. If your team struggles to react to open questions, provide them with potential options and ask for input to check your proposals.
  • Strong managers exhibit kindness and compassion. This is not a signal of weakness. If you consider yourself a servant leader whose purpose it is to grow, develop and enable your team, then you should radiate this with everything you do. Of course, should there be a difficult topic to address, you have to stand your ground — but even that can be done with kindness and compassion.
  • Tech skills depreciate, soft skills appreciate over time — This hurts most if you’ve grown tech skills for years, just to jump into being a junior manager all over again. While the tech stack you’re comfortable with slowly will rust, the soft skills you’ll acquire along the way of becoming a manager will only increase in value. Moderating meetings, delivering bad news, interviewing applicants and pulling the best out of a junior developer will be skills others will appreciate for the rest of your career as a manager.
  • You’re a cultural trendsetter. As Roger Nesbitt said in his wonderful essay on building a great culture in tech teams: “A culture is a set of acceptable behaviours that is formed by every action of each individual in a group”. Managers are cultural trendsetters. You have the resources and, at times, the authority to implement changes for the better. Whatever behaviour you decide to promote, will have a multiplied effect by those in your team who reciprocate it. Be aware of your role as a behavioural influencer.
  • Language makes culture. We tend to treat language as something waterproof; as if it were a bulletproof way of communicating thoughts. If you have ever received an unannounced meeting invitation labeled “important update”, you will understand that these two words can mean anything between “you’re fired” and “I want to let you know that we now have an integration branch ahead of our production branch”.

2. Failing is essential and experimentation is key.

This is an important mental shift, so I’ll dive deeper into why you should create a culture of experimentation. If you lead a team of engineers, you have access to a group of creative and capable people who can probably do things that you wouldn’t even be able to think of. Very often, engineers will not be able to translate their ideas into the management’s beloved KPIs; keeping the ideas from landing on the proposal board. Maybe your engineers might not have the resources to really prove that the idea is worth pursuing. They might also be scared to fail as it turns out that their idea was not viable after all. In your role as a cultural trendsetter you need to make one thing clear:

Even an experiment resulting in *nothing* needs to be seen as a successfully tested hypothesis.

Once you have established failure as a constructive part of your team’s progress, you’re opening the door for everyone to treat failure as something to learn from; rather than something to get in trouble for.

The sin is not in failure; the sin is in failing to notice and making the same mistake twice.

You should ensure that you and your team learn from mistakes. It should not be an issue if someone makes a mistake. However, you need to ensure that a culture is in place preventing it from happening again.

3. Meetings are a bug, not a feature — or are they?

“Yes, I’d love to schedule another daily with all stakeholders” — no one ever

“Bugs cause friction; features add value”.

Should you realise that the meeting you set up is hassling people around you, then you probably implemented a bug. You now understand that in order to make your meeting a feature, you need to figure out how to add value for your invitees. Once you have understood your responsibility and know how to bring order into the chaos you brought to your team, it is time to figure out how to align the stars within your team. In my opinion, you should never schedule a meeting just in case. If you’re unsure whether a meeting will be helpful, you haven’t done your homework sufficiently. Do your homework and reconsider.

  • Start / Stop / Continue. Talk about what your talking partner would propose you start, stop & continue doing. Write these things down, work on them and reflect two weeks later how it affected their life.
  • Glad, Sad, Mad. Collect qualitative stories about what left your colleague glad, sad & mad and see if you can celebrate things that made them happy or investigate things that dissatisfied them. Write things down and discuss them two weeks later to see how things evolved since. What’s special about this exercise is that it doesn’t include the creative part of your talking partner coming up with proposals what to do next. Be aware of that limiting factor.
  • The 4 L’s: Liked, Learned, Lacked, and Longed for. A combination of the two above patterns. This exercise helps people open up about troublesome topics and teaches them to celebrate things they liked while putting in context what was missing.

4. An obsolete engineering manager is a good engineering manager.

I can’t wait to change my mind on this. So far, my own engineering mindset is still going strong: “if I automate the process well enough, the work will never have to be done by anyone again”. Does that translate to “if I develop the team strong enough, they will never have to be managed by anyone again”?

If you’re on a sabbatical retreat for 3 months and your team delivers products at the same rate as before, you’re either a horrendous or a fantastic manager. Either way, you probably don’t need to come back.

To add to the above, Dave Rensin, former Google Engineering Director, drops some real truth bombs in his interview with Exponent. A great engineering manages gets a great deal of personal satisfaction by growing other people, he says. To them, developing another person is equal to shipping a great product.

Portrait of an engineering manager who built a self-sustaining tech team.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store