What should Engineering Managers do?
Views on a role that is more art than science
The Spotify model has been a de facto standard of organizational structure in the technology industry for the best part of the last decade. And recently an article outlining its failures has got a lot of attention. It shines some light in a model that nobody understood, but everybody tried to copy.
While I don’t want to dissect all that has been said on it (read it, it’s excellent), I want to go deeper in one topic that has been on my mind for a while: What should engineering managers do?
In the description of the Spotify Model, Jeremiah writes:
Engineering managers in this model had little responsibility beyond the career development of the people they managed. Even then, their ability to help with interpersonal people skills development was limited. An engineering manager would not manage enough of the other people on the team or be involved enough in the daily context to independently assess conflict within the team.
The description above does resonate with my recent experience in engineering management, especially in one of my last companies. When the manager’s attention is spread amongst different people in different teams, the lack of context makes the manager less effective.
In my period in this company, we had moved from a manager-across-a-discipline model (the web development manager) to a manager-per-team model, for the reason described above. While I believe the move was positive, we struggled to define the new role across the organization. In the end, some engineering managers were mostly people managers, some were high-level tech leads, and some focused on team delivery.
There were multiple rounds of open discussion, and we couldn’t get to an agreement. The lack of general alignment on even the primary goals for this role is reflective of the state of the industry at large, as far as I can see.
A Balancing Act
Engineering management comes in many flavors nowadays. It’s a relatively new role in the industry, and it also has to adapt to each company’s situation. It’s a role that usually fills different gaps depending on the context, which makes it hard to describe it.
Pat Kua has recently done a great job of dissecting it here, using four different skill areas to define different archetypes: technical, team, process, and product.
People are performing this role at an excellent level in many ways, and that needs to be respected. Companies and teams are different, and there are multiple ways to create a high performing organization.
But we can pick one side. At least I can. My goal here is not to analyze multiple options but to flip the question: how should you frame the Engineering Manager role in your organization?
Before we do that, though, let’s look at some relevant context.
Stepping Back
Back in 2001, the Agile Manifesto came to life. It proposed a refined and more interactive way to deliver software products, in contrast with previous less flexible management structures that were inspired in other engineering disciplines.
It took the industry by storm. The idea of iterative software and product development, working in close collaboration with the whole team and customers, proved to be much more useful than existing methods at the time and became a de facto industry standard.
Agile wasn’t created in a vacuum. It took significant inspiration from Lean/Toyota Production Systems. They were both based on the principle that planning (or building) too much ahead is wasteful, and the best approach is to reduce the batch of work to its minimum size. While there are investments to be made to make that reduction possible, they are quickly paid off by the mistakes you didn’t make when trying to predict the future.
Both were also heavily invested in the process. For agile to work, there are engineering, project, and product practices that need to be in place so that small batches can be possible. Think CI/CD and automated tests on the technical side, but also writing user stories that are iterative on the product side, amongst many others.
Mostly, they relied on the idea that the process, not just individual talent, drives productivity. Iterative methods propose that the right process will enhance individual performance while optimizing for the group’s flow of work.
If you can’t describe what you are doing as a process, you don’t know what you’re doing.
― W. Edwards Deming
Agile is now mainstream. Most companies today use some form of it to manage their projects. But many of its principles, which allowed the idea to work effectively, have decayed in my experience. Especially the collaboration part.
This situation can be explained by the way the industry evolved. Technology companies needed to scale, and engineering talent is scarce. With that, management and process in engineering moved towards finding individual stars: the rise of rockstars and 10x engineers. In this context, of VC funding, scaling tech companies, and hard to find talent, the engineering manager role was formed.
What’s the problem with that?
Engineering management became very focused on people, and mentoring careers, more than process, or how to make teams productive. And managing how the work works has lost relevance.
With that, engineering teams are less efficient. It makes sense to create asynchronous and more individual ways of work if you need to quickly onboard and manage thousands of engineers (and funding is not an issue). Any management style can do well in an expanding market.
But it doesn’t work for most companies. For the reality of teams in startups and smaller organizations out there, where you count engineers on the tens and not thousands and where how much you spend is still a concern, focusing on team productivity is still the best bet.
Examples of that shift towards individual contributions are around us. From avoidance of pairing, which makes it hard to spread knowledge around a team, to GitFlow models, which delay delivery in favor of not interrupting the flow of individuals.
How companies manage engineering is a crucial aspect of enabling this shift.
The engineering manager’s role
There are plenty of decisions to be made when shaping a high performing technology organization. And the Engineering Manager role provides significant leverage when aiming for this goal.
If your company has cross-functional product engineering teams and is looking for excellent execution, the EM’s role should focus on people and delivery execution. If the group is not performing well, or the job is not fulfilling for engineers, it should s the EM’s responsibility.
This is not to say that the EM should not be involved in technical and product decisions, but they should not be what they are accountable for. Here is why:
Managers who manage how the team works can be accountable for delivery. By setting the process and how the engineering team is working, the manager has significant leverage in the team’s performance.
Managers who manage the engineers and process in a team can have a broader impact on an individual’s career. By having more control of the environment where the engineer works and what kind of work they do, the manager can more easily adapt work to focus on individual interests.
Managers managing all engineering in a team understand the work better. By managing all engineers, the manager has a better understanding of the work being executed. And more capacity to adjust.
Managers who are accountable for results and people’s work fulfillment at the same time will be able to make the best trade-offs. Team and business objectives are not always in sync with individual goals. Making managers responsible for both sides will allow them to make the best decisions in the area.
Since success means saying no to most things, here are the reasons why EMs should not spend most of their time in other activities.
EMs should not be the primary technical decision-maker on engineering projects. Managers work on a manager’s schedule, which makes it very hard to have enough time to comprehend all the technical details of a system. While EMs should help drive decisions in technology, relying on them to make them usually leads to ivory-tower-architecture situations. If the team is big enough to need technical guidance, the tech lead role is appropriate for that.
EMs should not be responsible for product decisions. While EMs and engineers should work closely with product and design, there are usually 4–8 engineers to one product person in a team. Not investing in how engineers work together in favor of other disciplines means not investing in the area of highest leverage (and cost) in a group.
These are guidelines and not rigid rules. Everything is contextual when it comes to organizations. But remember that you should be in the search for the 10x team, not the 10x engineer. Being intentional about managing your teams is the shortest path to get there.
