Software needs great managers.
If you love software, have you thought about making the jump from programmer to manager?
In this post I’ll talk about how software engineering management can be a great career choice for the right person, and also about the sort of impact you, as a manager, can have on the world.
Over the last few years, it feels like engineering management has gone mainstream as its own discipline - it’s much rarer than it used to be for a coder to be managed by a product manager. Engineering management has become something to be good at and to be proud of.
We now have the opportunity to help create the next generation of managers, and change the world in the process.
We have a great foundation to start from. We have a new generation of great software engineers. The past few years has seen a huge influx of amazing people into the world of software thanks to coding bootcamps and diversity initiatives gaining momentum.
The industry talks and acts differently because of our newest members - a diverse, intelligent and life-experienced group that it scarcely deserved.
It’s my sincere hope that the leadership of these coders changes too, as a generation of developers start looking at a career in engineering management. This is important because everything is software now - and the better that software is, the better our lives are. And the more diverse and inclusive the software industry is, the better the software can be and the better our lives will be.
So… what does an engineering manager actually do?
Engineering managers make the machine that makes the machine.
Engineering managers are responsible for building software engineering teams and supporting individuals in their work and careers.
The word “management” has boring, dread-inspiring associations, but this is sooo wrong.
This vocation is a force of tremendous good in the world, and being a manager in the complicated context of software is a challenging job, worth doing well.
Think of the good managers you’ve had: probably they were the ones who understood technology, the way development sometimes goes (i.e., frustratingly) and the ways that folks like to work together. Those managers make a huge difference to the companies they work for and the individuals they work with. You could be one of those great managers.
As an engineer, your main output is product: code, screens, flows. As a manager, your primary output is your team.
The work you do and role you play will vary by organisation, but you can expect to be:
- Building teams through hiring and internal recruitment
- Helping teams grow and develop as needs change
- Coaching individuals with feedback and supporting their goals
- Championing and supporting teams and initiatives within your organisation
- Acting as an example of company values and behaviours
In short, you can expect to be working with people. And being a great manager means being great at working with people.
Working with people is different to working with computers.
When you’re working with people, you spend your time listening, observing and talking. People aren’t logic puzzles to be solved: they are complex beings whose every action is coupled with a lifetime of experiences. You can’t turn them off and back on again. You can’t ask them to re-do a failed task from a clean starting point. And growing and changing takes time — and they have to want to do it.
But you know all of this already: you’re a person yourself. Do you like being treated like a computer? No, you don’t. Think about how you’d like to be treated: that’s how a great manager will treat you.
Managing is a different skill to programming. The context of being able to code, and the experience of having shipped software, is invaluable - but managing people requires you to exercise different muscles.
And, fundamentally, you have to enjoy other people and care about other people.
You have to care about people because the more management responsibility you take on, the less software you will be directly building.
This is inevitable if you want to be an effective manager: one of the biggest mistakes a manager can make is prioritising building software over building teams. Once you are a manager, your achievements are the team’s achievements - the satisfaction of a job well done is seeing teams and individuals grow and then outgrow you.
You’re no longer looking for an elegant refactor or a beautiful abstraction. Instead, it’s the well-placed “are you alright?” and the earnest “yes, I heard that too. Why do you think that happened?”. It’s seeing somebody thriving in their job because of the responsibility and autonomy you gave them, when your instinct was to watch and criticise their every move. It’s providing the environment where people can move beyond the basics of having the resources to do their job and onto self-actualisation: the top of Maslow’s hierarchy of needs. By providing a role to people where they are becoming their best selves, they are motivated to stay with your team for a long time.
… what does a manager do on a daily basis?
As a manager you spend most of your time listening and talking.
The most important and powerful tool in the manager’s arsenal is the 1:1 meeting - the time that you spend with those you manage, just you and them. Rands (if you’re going to be an engineering manager, you’re going to read a bunch of Rands’ stuff) suggests that 1:1s should be 30 minutes, every week, never cancelled and consistently scheduled.
I really believe in the 1:1 meeting. You find out what’s actually going on, the nitty-gritty of problems, people’s general opinion on things. And they’re your opportunity to help, to mentor and to reiterate important messages. So, they’re well worth the time investment.
As it happens, I find a weekly 1:1 meeting to be overkill for some people - but it’ll give you a sense of how much time you’re now going to be dedicating just to these meetings. If you manage 10 people (which is towards the top end of what most people can do), and sit with each of them for 30 minutes every week, that’s 5 hours a week - essentially a whole day.
I also take between 5-15 minutes to prepare each 1:1 conversation, and write up notes. With 10 people, that’s another 1-2 hours a week invested in preparation.
That’s before you’ve got onto other time commitments: interviewing, working with other managers, etc. etc. It should go without saying: your time management needs to be good. You need to be timely on replying to emails, on booking calendar slots and keeping yourself organised.
Put it this way: if you see your manager late, stressed and disorganised all the time, it can give cause to worry.
If your time management is naturally good, then that’s a sign that this sort of role is suitable for you.
Of course, some of the many conversations you will have with people are difficult. Sometimes they’re awkward and sometimes feedback isn’t well-received. In fact, you sometimes have to make conversations more difficult.
The manager that’s always looking for harmony and always smoothing over the cracks is not actively developing their team members. If you’re interested in why a certain thing happened, even if the explanation might mean you have to ask questions, fix things or listen to tough feedback, then you are interested in people and you are interested in helping them be their best selves.
So, it’s important to enjoy working with people and you have to derive satisfaction from the achievement of creating a great team. Because you’ll be spending almost all of your time doing this stuff.
More reading: Lara Hogan has a great article where she discusses how she spent her time at different levels of manager.
And that’s why you’ll have a lot less time available to write software. And once you can’t write software for most of your time, trying to dip into it can be a real problem for the team. Some managers think they can dip into a project for a day - forgetting that they no longer have the context to do so, and when they’re inevitably called away to their other responsibilities, they have to leave the task hanging. If it’s a critical task, now somebody else has to pick it up.
The other big difference between jumping from programmer to manager is information.
As a developer, you mainly consume information. As a manager, you need to produce information.
I stole this idea from my friend Akash, because it’s perfect. As a manager, you have to be the one who produces information. You have to start answering questions that nobody is asking yet, radiating information between teams and being consistent as hell on your messaging.
Akash’s full post, Growing pains - consumer vs producer, is short and well-written. In the daily life of the manager, becoming a producer of information means things like:
- Communicating and facilitating decisions on the work of development: architecture, roadmaps, plans
- Sharing information you receive - updates, what others are working on, issues
- Consistent re-iteration of company and individual goals and values, in 1:1s, team meetings and even when you’re just making a coffee and chatting with somebody
A lot of the time, nobody asks you to communicate this information - your manager might not suggest you circulate it, your team might not know to ask about it. You have to realise on your own that your team will benefit from knowing more about this topic, be it for their immediate tasks, for context, or for their understanding of the direction of the overall company.
Talking of the overall company: communicating goals and vision is also a critical part of the information you will now be producing and relaying.
I believe that being “on song” is a critical part of the manager’s role: you need to be a consistent cheerleader and supporter of the plan, the vision and of the team. You can’t complain about your reports to others, and although you definitely should listen to their critique of how things are going, you shouldn’t join in.
This doesn’t mean saying things are perfect when they’re broken - it doesn’t mean lying, spinning or seeming delusional. You need to be honest, rigorous, consistent and authentic. You’re honest that things aren’t perfect but rigorous, consistent and authentic in your desire to improve them, and your expectation that your team will work to do the same.
This work is critical to building and maintaining morale, and sometimes it’s not easy. Sometimes you’re incredulous about how badly something has gone - but you keep that to your conversations with your own manager.
Maybe it’s not for you…
As they say, all software problems are actually people problems. I guess it’s fair to say that these problems are eventually people problems - there is plenty to delivering great software which is about detail, abstraction and the art of nice code.
Maybe solving the people problems isn’t for you - maybe you want to carry on with your primary focus being shipping code, either forever or at least for now.
If you’re still early in your career, ask yourself whether you have built up enough experience to be a useful manager: one with enough context and experience of shipping to really add value when building and growing a team. This isn’t about technical skills - eventually your technical skills will be irrelevant - it’s about having done a few laps of the track, solved real problems and delivered great software before you start coaching others.
Some people with this level of experience choose a technical lead role either as a separate path, or as a stepping stone, to being an engineering manager. Perhaps this is more suited to you and how you want to spend your time.
How is an Engineering Manager different to a Technical Lead?
A tech lead is still primarily focused on the technical outputs of the team, rather than the work of building up the team.
Of course, this distinction depends on individuals and organisations, but overall a Tech Lead can expect to be working on architecture, screens, code and technical direction.
They keep their technical skills sharp as they use them every day and they mentor and coach on technical pieces. You’ll still be in meetings, but probably fewer, and probably not 1:1s with team members.
A tech lead may find themselves coordinating between peers and teams, but this will usually be on details of the APIs and interactions between those teams, rather than working on the people on those teams and how to get them best working together.
In summary: great managers help create great software.
Simply put:
Because every problem is now a software problem,
It’s important that our software is built well…
And engineering managers have a crucial role to play in well-built software.
That’s why being that manager is a way to have a meaningful impact on the world. If you like software, you care about the goals of your company and you enjoy working with people, I think it’s a very worthwhile use of your time.
And most important of all - we need inclusive teams.
The diversity of our industry has changed and is improving. This is a cause for tremendous celebration and positivity - but the work isn’t done. Inclusivity is the second, harder step in building an industry that represents the world it helps shape.
We need to create environments where all types of people can thrive, do their best work and become their best selves. To be blunt: we require inclusive environments in which people want to stay part.
… and engineering management is critical to this, too.
Sounds great! How do I become an engineering manager?
If people are interested, this will become the first part of a series about this very topic.
Tweet me and tell me what you'd like to know! If you enjoyed this post, feel free to share it, too.
Hope that was helpful - thanks for reading :)
What to read next
The different stages of an engineering management career - Sally Lait
Advice for first-time managers - Aaron Randall and Amy Phillips (Humans+Tech)
Top comments (0)