The Perfect Engineering Manager

In my last post I introduced a practical approach to engineering leadership and the skills required in any engineering organisation.

The post must have struck a nerve as it got a lot of reads, especially on Medium in The Startup magazine where I cross-post some of my blog posts.

However, I’m sure people have many new questions on the practical side of how this works in practice. The key insight I tried to convey was that all engineering organisations are built around four distinctly different skill sets and that you need engineers who jointly cover all the skills, no matter how you distribute the responsibilities: code development skills (the developer), task priority and tradeoff handling (the backlog owner), technical architect skills managing long-term vs short-term (the architect), as well as people and team skills to keep people happy, make them work on the right things, and make sure things get delivered (the manager).

The larger the organisation, the more roles tend to be specialised. As a result, the coordination cost goes up. You typically then get elaborate frameworks and formal development processes to ensure coordination. This is a drain on time and motivation for most software engineers. On the other hand, in successful and small startups, you typically see very flat organisations where everybody seems to do everything. How then can you successfully scale an engineering organisation and keep the energy and productivity? Amazon’s 2-pizza teams is a famous approach, but reality is that it all starts with the people you recruit, so you need to start early. If you hire a project or program manager who has been managing projects and processes, but without delivering own content into these projects, you will get more projects that are managed by process, not by purpose.

And “purpose” is a keyword. You want people who are driven by purpose, not process. And here we get to the Perfect Engineering Manager. If you have one Perfect Engineering Manager on each team, focus will be on purpose and you can reduce coordination to a minimum. So, who is this Perfect Engineering Manager? In fact, he or she probably does not exist, or there are very few of them out there. Luckily, the skills can be trained. Not surprisingly given the lead-in to this post, the Perfect Engineering Manager is a person who is a brilliant coder, loves enabling and helping out others to make them successful, takes natural responsibility for delivering high-quality code into production, knows the code base inside-out and will re-factor quickly while adding new abstractions and code that will help others deliver in the future. Mentoring more junior developers comes as a given, and the natural authority of the Perfect Engineering Manager makes it a breeze to drive prioritisation, sprint planning, daily stand-ups, or any other chosen development approach. Of course, the social skill set of the Perfect Engineering Manager means that other developers love working for her or him and necessary interactions with other teams are always pleasant and smooth!

The Perfect Engineering Manager is an ideal and getting closer should be an aspiration for well-rounded, senior engineers. Not in the sense that everybody should strive to become Perfect Engineering Managers, but that one or more skills can be chosen and improved as part of developing as an engineer and a human being.

Without at least one such person, or a team of people who together cover the Perfect Engineering Manager skills, you will not have a 2-pizza team, you will have a small group of developers that rely on others to get things done. Developing great software and great products is not rocket science, but it requires systematic and careful grooming, development, and attention. In too many organisations, software engineers are left on their own without much help or guidance on how to grow their career, job satisfaction, contributions, and as human beings. The Perfect Engineering Manager is of course instrumental in facilitating and making the right decisions to make sure that the engineers on his or her team are not in that unhappy group.