8 min read · Jul 15, 2020
Engineers looking to grow their career in people management are sometimes flummoxed by the myriad of titles and roles out there. What exactly is the difference between a Manager and Manager II? Senior Manager and Director? This is made further complicated by these titles not meaning the same thing across companies. For example, a Director of Engineering in a 50 person startup is a very different role than a Director of Engineering in a large public company with 10,000+ engineers.
This problem is also felt by founders in growth stage startups. What leadership structure and roles to create? How do you figure out what background or profile to hire for a role you opened?
Due to this lack of clarity, engineers, hiring managers and recruiters often lean on team size as a measure of career progression on the management track. For example, a manager with a team of 8–15 might be entry level, 20–30 might be a senior manager, 50+ a director and so on.
While team size can be a reasonable proxy to get a sense of a manager’s scope of responsibility, it is by no means perfect. A Director leading a team of 100 in a large public company and a Head of Engineering leading a similarly sized team in a growth stage startup are in quite different roles and could have had very different experiences in leadership. In my experience, to truly understand career progression in engineering management, you need to go beyond team size and understand the levels of abstraction at which managers operate in engineering teams.
Levels of abstraction in this context are analogous to those in computing. Each management level of abstraction has a certain scope of responsibility and contract with the abstraction level above and below them. Below I outline what in my opinion are the key levels of abstraction in an engineering organization. These are by no means comprehensive or universal; large orgs will need more levels, small orgs can get away with way fewer. But I think these represent the key step function changes in scope of responsibility.
Manager
In this role, a person is directly managing a team of engineers. They are responsible for the impact and health of that team. In small teams, the manager might be directly managing execution, i.e. running sprint planning, bug triage and task assignment. In certain cases, they might also be the technical lead for the team helping define the technical roadmap and overall system design (this type of role is sometimes called the Tech Lead Manager or TLM role).
In larger teams, the manager might delegate some of the day to day execution to engineers on the team, either senior engineers who own and drive multi-person projects or one or more Tech Leads (TL) who take accountability for execution and roadmap for a sub area of the team.
In all cases, the manager is ultimately accountable to the team’s impact. They are also directly managing all of the engineers on the team, and thus responsible for their engagement, morale, career growth and performance. First time managers who were previously tech leads or senior engineers sometimes underestimate or undervalue the ‘team health’ aspect of the role; in reality, it is a significant responsibility and as the team grows, effectively delegating execution and technical leadership responsibilities and investing more time on the people side becomes key to sustaining well performing teams. Additionally, recruiting responsibility sometimes falls directly on managers at this level, i.e. they need to figure out how the team needs to grow, make the case for adding roles and then go recruit.
Manager of Managers
The next step change in management abstraction is a manager of managers role. In my experience, the transition from manager to manager of managers is as significant a jump as individual contributor to manager. In this role, one has to recognize that they now have a layer of “strong” abstraction below them, which is quite different from directly managing a team or having a “weaker” abstraction through TLs. “Strong” abstraction means that the team manager reporting to them is ultimately responsible for that team’s success, and it is important for the manager of managers to recognize that and be aware of it. Their role is to empower and coach that manager to do their job well, and resist the temptation to get directly involved. For example, they might have a strong opinion on how the team should approach a certain initiative, but they should recognize that the manager is the one ultimately executing on it, so they should get to make the call (within reason, of course).
This aspect plays out in many subtle ways. For example, an engineer on the team might happen to have a technical discussion with the skip level manager where they arrive at a key decision. Or a cross functional counterpart like a Product Manager might have a product strategy discussion pertaining to a team with the manager of managers. In these situations, it is important to make sure that the team manager is not bypassed, and consistently feels empowered and in the loop. Without responsibility cannot come accountability, and you also aren’t going to help in their growth by doing their work for them.
Similarly, when it comes to team health, the manager of managers plays an indirect role for that specific team. This might be by collecting 360 feedback, regular skip level 1:1s and other means to keep connected with the team and provide regular feedback to the manager, and get a sense of their performance in role.
A manager of managers is typically overseeing a few different teams, so a lot of their time also goes in facilitating collaboration between those teams and ‘connecting the dots’ in team strategy and technical roadmaps.
Head of Org
The next step up in the ladder is overseeing an entire organization or focus area. For example, this could be the engineering head of a specific product or platform area, e.g. Infrastructure Engineering in a growth stage product company, Marketplace team in a marketplace product company, or leading the eng team for a product like News Feed at Facebook or Drive at Google.
This role can have a variety of titles ranging from Director to Vice President, depending on the scope and size of the team. But in this level of abstraction, the person reports into another engineering leader who has a larger scope, so is still a mid-level management role.
In the Head of Org role, the person is typically operating very independently and their manager is playing more of a supportive role. They are responsible for all aspects related to the functioning of that org: planning how the org should evolve, team structure within the org, strategy and roadmap planning with cross-functional counterparts, facilitating investment in long term system architecture evolution, and connecting the team’s charter and plans with broader company strategy.
This is an abstraction where proactive management is particularly important. This means they are responsible for not only problem solving, but also identifying the problems that need to be solved. No one is going to tell them what the problems are in their org, they need to figure it out — and this includes people, technology and product problems.
A person in this role must be an active force multiplier. Their work should amplify the impact of their org. They should be regularly thinking about what can be better, what processes can be improved, what gaps exist in strategy, where there is needless duplication of effort, whether the org structure should evolve, how to maintain regular communication up and down the org, what people in their org can take on new stretch challenges and so on.
This is a level of management at and above which “net neutral” just doesn’t cut it. That is, it is not sufficient to just keep the machine humming and reactively solving problems that arise. Net neutral leadership can lead to organizational stagnation and eventually disengage the best performers in the org. Opportunity cost in these roles is high since there are only a few roles at these levels. Hiring and developing strong leaders and managing out weaker leaders is one of the most challenging and important responsibilities of the management abstraction next level up.
Head of Function
This is the top level abstraction in an engineering management hierarchy. A head of engineering typically reports to the CEO, though might report to a General Manager in a large company. Titles could be Vice President, CTO or simply Head of Engineering. In some cases, multiple technical functions might report into this level, i.e. besides engineering, also functions like IT and data science.
This is the ‘buck stops here’ level in the engineering organization, which is what makes it a step function change from the Head of Org level. The Head of Org has a fallback in their boss when they face a challenge or miss something. The head of function typically does not have that, since their boss usually needs them to run their function completely independently. This is because their boss might have no knowledge or experience in running engineering teams, since they may not have an engineering background or engineering management experience.
At this level, proactive management described earlier is even more important. A person in this role sets the tone of the org and shapes the culture. Like in the Head of Org role they get to figure out organizational, technical and often product strategy, but at the company level rather than org level. They also need to be the ultimate cheerleader for the org, leading the team through the ups and downs that are part of company building and product development.
A number of engineering wide responsibilities fall directly at this level. For example, how should engineers be compensated? What sort of career ladders or growth paths do engineers in the org have? How to build a diverse and inclusive team? How to run an effective performance management and feedback process? How to facilitate strong processes for planning and execution? How to facilitate a strong recruiting pipeline? How to make the right investments in tech debt and long term architectural evolution?
Note, this doesn’t mean the person in this role solves all these problems themselves. They might delegate to their team members or partner with other functions like the People/HR team. But they are ultimately responsible for the outcomes in these areas.
As mentioned earlier, an important responsibility at this level is building a strong leadership team. This involves hiring great leaders, developing high potential emerging talent into leaders and managing out ineffective or net-neutral/negative leaders. [These are each meaty topics, I look forward to diving into them in future posts.]
Another aspect of this level of abstraction is they are part of the broader leadership team, typically company level leadership. This means they work with the CEO on matters at the company level, e.g. hiring peer executives, company strategy and vision, crafting company values and operating principles, fundraising, headcount and budget planning, board meetings and so on.
—
My hope with this post is to illustrate that team size alone is not a barometer of management progression. If you are looking for a head of engineering for a 50 person startup, don’t just build a pool of candidates who have managed 50+ person teams. Instead, understand what level of abstraction they have operated at as well. Likewise, for engineers entering the management track, hopefully this provides a framework for how to think about longer term growth and development.
