4 truths about leadership in software development I wish I knew before becoming a manager
TL;DR: 1. you are not a single contributor, 2. making mistakes is great if you make sure to learn from them, 3. meetings are only good if they aren’t bad, and 4. excellent and horrible managers, both, leave nothing to be desired for when they leave.
This article is meant for aspiring and practicing engineering managers at various levels of experience. Even if you’re not a manager, but instead leading the way as a tech lead or senior software engineer, this list of thoughts and tools might be helpful for you to grow as a leader from within. My hypothesis for this essay is: leaders in software development are cultural trendsetters — those who build a culture of clear communication, strong collaboration and trusting relationships.
The following thoughts are based on my personal experience and conversations with fantastic peers I met along my way of growing as a software developer and engineering manager. I have collected a list of thoughts and also some tools which I categorised by four (highly subjective) truths about successful leadership in software development.
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.
As a manager, it is not your responsibility to contribute by developing software within a sprint in isolation. You’re not just fighting the chaos which you or other engineers created during plannings, groomings, demos, and reviews anymore. You’re fighting chaos everywhere. All. The. Time.
Organisations tend to move towards chaos, the bigger they get. It is your job to fight that chaos back and bring order into your team’s development environment for them to excel.
When I took over my first role as a non-developing manager, I had this strong urge to lead by example: complete all my todos in time, set up extensive Trello boards to organise myself, be active in design meetings and prove to my team that I could walk the talk by contributing with my knowledge of the craft. I was so busy enabling myself to do the best work possible, that I became completely oblivious for the actual task: enabling my team to do the best work possible.
Here are some mantras for software leaders I came upon ever since:
- 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.
However, there’s an important mantra to keep in mind:
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?
If you have a background in software engineering, you probably have experienced this before: Your product manager, stakeholder or line manager invites you for a ‘quick’ call and pulls you out of your engineering tunnel. You discuss why your user story’s scope suddenly changed and leave the meeting to continue working that story. After the meeting, it takes you 30 to 60 minutes to finally get back into your tunnel. That meeting was disruptive and broke your flow. Are meetings therefore a bug or a feature?
“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.
However, there are exceptions! It is important to always collect feedback. Some topics will never come up in your scrum rituals, so try to have at least a bi-weekly 1:1 exchange with your directs. In order to ensure that my meetings add value to the team’s collaboration efforts, I do the following things:
1) Use standardised meeting templates to collect qualitative feedback
Sometimes you have to talk about difficult topics. Fortunately, there are tools to allow us to meaningfully talk about them. The following three templates are inspired by retrospective exercises I’ve done with various engineers in the past. They’re pretty much identical. See if one of them could spice up your 1:1s…
- 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.
2) Measure ‘Return of Time Invested’ (ROTI). At the end of my workshops, plannings and groomings, I like to collect quantitative feedback from all participants on a scale from one to five; one being low and five being high. If most participants rate the session with a 4 or higher, it was a success. Should the overall rating be lower than that, then I take that with me to reflect or use the remaining time to ask participants how things should have been different.
3) Set the lifespan of all recurring meetings to a maximum of 3 months. Even for 1:1s with my directs, I define a lifetime cycle with an agreed template and commit to it as an experiment. At the end of the cycle, we discuss if the frequency and template were helpful and decide how to continue. I do this with all recurring meetings to ensure that form follows function and not the other way around. No exceptions.
You see, these methods all enable you to improve your peers’ lives while providing them with continuity. Once you’ve built the trust and proven that you use your learning from the meetings to improve their lives, they’ll look forward to you taking up valuable space in their calendars.
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.
But where does developing others end? I honestly don’t know yet, but am eager to find out. If you enjoy creating personal development plans, empowering others to host engineering showcases, or enabling engineers to provide their own content for product roadmaps, you’re likely on the right track. Every time an engineer corrects what I say or makes a better proposal than I could make in a big round of people, it feels like a success.
Originally, this essay had a fifth truth which circled around software managers being monolithic structures within their own organisation. I meant to write about how you need to move outside of your organisation to continue growing yourself. It will be much harder for you to find idols to copy as a singular manager, so it is essential for you to reach out and talk. I collected the following list of follow-up literature to challenge your monolithic perspective:
- Peopleware: Productive Projects and Teams
- The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
- EMPOWERED: Ordinary People, Extraordinary Products
- ShapeUp: Stop Running in Circles and Ship Work that Matters
- INSPIRED: How to Create Tech Products Customers Love
- The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change
Were some of these thoughts & tools new to you? Let me know what you think in the comments. I’m always looking for conversation partners to broaden my horizon. Reach out to me on LinkedIn if you’d like to talk about software management.
