The Engineering Manager Role
Manage all these tech people, but while you’re at it, do all this tech stuff too!
I make no apology for quoting Charity Majors widely in this article. She swears a lot (which is a scientifically-proven good thing) and doesn’t have time for bullshit. She has spent a lot of time in this area and knows what works and why it works.
Being back in the job market again, I’ve noticed that there’s a bit of a change happening in job descriptions for Engineering Managers. Most notably, many of them specify that the successful candidate should be doing some/all of:
- Coding
- Code reviews
- Driving sprints/being a scrum master
- Breaking down work into tickets for the team
- Architecting solutions
- And many more tech-focused functions
There are more, but the above list carries the gist of what is being asked for. In response, I ask those with job descriptions matching the above to really think about what you’re looking for.
I understand where the hunt for the above type of Engineering Manager comes from; I’ve been at companies where we’ve had the same kind of problem in finding it hard to recruit good people managers who retain an appropriate level of technical knowledge, so we resorted to promoting Tech Leads into the Engineering Manager role with vague promises of how they’d still get a chance to do tech stuff whilst we supported them in the people management side.
The thing is, in almost all of these cases you end up with the worst of both worlds… you get an Engineering Manager yearning for more time to do tech stuff, who wants to act as a leader of the tech team, therefore taking away the agency and autonomy that the team needs, and they cannot give the level of people management that the team will benefit from. These are two separate roles and mashing them together will almost always result in a suboptimal experience. You’ll get an unhappy manager and unhappy engineers, and this results in an unhealthy organisation. Ask Patrick Lencioni how well that works out.
Asking an Engineering Manager to carry out the above kind of tasks is mixing and matching both roles (manager, architect, scrum master) and career paths (management and individual contribution). Yes, I know that it is feasible to do both, but to borrow a sports analogy, how many player/managers are there in professional football? *
I don’t mean that Engineering Managers shouldn’t be technical — there are rare exceptions where non-technical managers have succeeded — but generally it seems obvious (and more importantly, is well-established as something that, well, just works) that to manage a technical team and understand the challenges, you need to have some experience of the industry to a pretty good level, e.g. previously a senior developer or tech lead.
You need both social and managerial skills, and technical engineering skills. Furthermore, you need to learn to wield them together.
You need to be able to look at a team that isn’t shipping very fast and figure out whether it’s because of under-skilled engineers, legacy code, a weak product culture, a leaky CI/CD pipeline, or a team that has given up and lost confidence in itself. And then you need to start influencing people to do things that visibly and materially improve the system. — Charity Majors
An IC role requires a lot of focus time to allow the flow state to emerge in which that person does their best work. A managerial role is interrupt driven. This means you must be available for your team, or your manager/senior leadership team at the drop of a hat. As a manager you rarely get the luxury of being able to focus on deep work, unless you’re really good at syncing up that kind of work with a period when all of your team is in their own flow state. You have to accept that your role changes when you step into management. Your team comes first now, not your desire to prove that you can write better code than any of them (yes, even if you can, don’t! Nothing good ever comes from proving (or trying to…) you’re the smartest person in the room.
I know what some of you will say at this point, that there are many types of Engineering Manager, and that’s true. The legendary Pat Kua identified five archetypes to start with. The truth is, there is no unbroken mould from which Engineering Managers spring in a uniformly-shaped object of coruscating perfection; there are so many different scenarios at companies in different stages that it’d be weird to think that just one archetype could fit all requirements.
So how do you know which archetype is right? You don’t. Sorry, that’s life. You could look for the highly technical hands-on type and then discover a few months in that they’re hogging the decision making, preventing the team from getting the opportunity to, well, fuck things up and learn from it, basically. You may well know damn well that the path they’re on is doomed to failure (and, hey, if it really is a catastrophic failure looming, then you do need to step in) but unless you let them find this out for themselves then you run the risk of being seen as an interfering know-all and your team will simply learn to defer to you and switch off their critical thinking and innovation braincells.
This is the ideal situation for a team: to have a technically-skilled manager who can weigh in but knows their boundaries, doesn’t hog all the decision-making for themselves, and lets engineers own engineering decisions. — Charity Majors
What you can do though, is stack the odds in your favour when looking for Engineering Managers. I’ve heard countless small to medium size companies claim “we’re different” or “those rules don’t apply to us” or “that’s not how we do things around here”. Newsflash: you’re not different, the rules do apply to you and you’re likely doing things wrong, in that case. Nature has a way of reverting to the average. Many smarter people than you or I have agonised over the thorny problem of Engineering Managers for a long time, even why do we even need them? (spoiler: one simple reason is just because that’s what the industry has learned just works).
So do some reading, (You’ll realise by now I highly recommend Charity Majors. If you’re doing stuff that conflicts with what she’s suggesting, you’re likely to be edging towards that “we do things differently around here” space mentioned above.) A good starting point that covers the basics of what Engineering Managers should do is in this article. It contains the following, which I think is a nice summary of the fundamentals.
“Engineers are responsible for delivering products and outcomes, but managers are responsible for the systems and structural support that enables this to happen.
Managers don’t make all the decisions, but they do ensure the decisions get made. They make sure that workstreams are staffed and resourced sufficiently, that engineers are trained and improving at their craft. They pay attention to the contracts and commitments you have made with other teams, companies, or orgs. They advocate for your needs at all levels of the organization. They connect dots and nudge and suggest ideas or solutions, they connect strategy with execution.
Breaking down a complex business problem into a software project that involves the collaboration of multiple teams and ensuring that every single contributor has work to do that is challenging and pushes their boundaries while not being overwhelming or impossible… is really fucking hard. Even the best leaders don’t get it right every time.”
In conclusion, should you believe you need an Engineering Manager that will code, perform code reviews, be the person that tells the team how to do their work and spoon-feed them already-written Jira tickets, I wouldn’t say you’re wrong, because, hey, you might just be that company for which this approach will work, but the odds are truly stacked against you on this one, as there is very little support for this kind of Engineering Manager among the thought leaders and subject matter experts in this field (and not because they haven’t thought of it, before that comes to your mind!).
My experience shows that, quite simply, a happy team is an effective one and will produce great work for the right intrinsic reasons (refer to Dan Pink’s work in this area for more) and I’m yet to see a happy team in which there is an Engineering Manager directly calling the technical shots (but I absolutely acknowledge the possibility that such teams exist). Get your organisation healthy (refer to the Patrick Lencioni link above for the level of importance this holds), build trust in your engineering teams and you won’t go far wrong.
* Caveat: I know there are circumstances in which it can be appropriate for an Engineering Manager to occasionally do some IC tasks, but it should never be a long-term solution, you are not getting the best out of the role with this approach.
Don’t just take my word for it; further reading from people far more clever and experienced than me: