An Elegant Puzzle: Systems of Engineering Management

by Will Larson

When I have a problem that I want to solve quickly and cheaply, I start thinking about process design. A problem I want to solve permanently and we have time to go slow? That’s a good time to evolve your culture. However, if process is too weak a force, and culture too slow, then organizational design lives between those two.

Managers should support six to eight engineers This gives them enough time for active coaching, coordinating, and furthering their team’s mission by writing strategies,2 leading change,3 and so on.

Tech Lead Managers (TLMs). Managers supporting fewer than four engineers tend to function as TLMs, taking on a share of design and implementation work.

Adding new individuals to a team disrupts that team’s gelling process, so I’ve found it much easier to have rapid growth periods for any given team, followed by consolidation/gelling periods during which the team gels. The organization will never stop growing, but each team will.

Fundamentally, I believe that sustained productivity comes from high-performing teams, and that disassembling a high-performing team leads to a significant loss of productivity, even if the members are fully retained. In this worldview, high-performing teams are sacred, and I’m quite hesitant to disassemble them.

However, the real productivity killer is not system rewrites but the migrations that follow those rewrites. Poorly designed migrations expand the consequences of this rewrite loop from the individual teams supporting the systems to the entire surrounding organization.

you only get value from projects when they finish: to make progress, above all else, you must ensure that some of your projects finish.

One specific tool that I’ve found extremely helpful here is an ownership registry, which allows you to look up who owns what, eliminating the frequent “Who owns X?”

the best solution to frequent interruptions I’ve seen is a culture of documentation, documentation reading, and a documentation search that actually works.

Succession planning is thinking through how the organization would function without you, documenting those gaps, and starting to fill them in.

Product management is an iterative elimination tournament, with each round consisting of problem discovery, problem selection, and solution validation.

Strategies are grounded documents which explain the trade-offs and actions that will be taken to address a specific challenge. Visions are aspirational documents that enable individuals who don’t work closely together to make decisions that fit together cleanly.

A structure that I’ve found extremely effective13 is described in Good Strategy/Bad Strategy by Richard Rumelt,14 and has three sections: diagnosis, policies, and actions.

I believe that, at quickly growing companies, there are two managerial skills that have a disproportionate impact on your organization’s success: making technical migrations cheap, and running clean reorganizations.

Finish small, leveraged things. If you’re doing leveraged work,40 then each thing that you finish41 should create more bandwidth to do more future work.

and it grated on my belief that consistency is a precondition of fairness. Since then, I’ve come to believe that environments that tolerate frequent exceptions are not only susceptible to bias but are also inefficient.

Satisfying global constraints inevitably leads to local inefficiency, sometimes forcing some teams to deal with deeply challenging circumstances in order to support a broader goal that they may experience little benefit from. It’s hard to ask folks to accept such circumstances, harder to be someone in one of those local inefficiencies, and hardest yet to stick to the decisions at real personal cost to the folks you’re impacting.

Folks who communicate a no effectively are not the firmest speakers, nor do they make frequent use of the word itself. They are able to convincingly explain their team’s constraints and articulate why the proposed path is either unattainable or undesirable.

Even with the best intentions, a member cannot optimize for their team if they’re not familiar with other members’ work. The first step to moving someone’s identity to their peers is to ensure that they know about their peers’ work.

dominant strategy is one that is expected to return the maximum value regardless of the actions of other players. Team collaboration is not a dominant strategy. Rather, it depends on everyone participating together in good faith. If you see someone acting against the interests of the team, you, too, will likely defect to pursue your own self-interest.

Luck plays such an extraordinary role in each individual’s career progression that sometimes the entire concept of career planning seems dubious. However, as managers, we have an outsize influence in reducing the role of luck in the careers of others. That potential to influence calls us to hold ourselves accountable for creating fair and effective processes for interviewing, promoting, and growing the folks we work with.

Class systems. Folks often look at new roles as less important, framing them as service roles to absorb work they’re not interested in. Sometimes roles are even explicitly designed this way, intended to reduce work for another role as opposed to having an empowering mission of their own.

Where everyone on a team was once able to perform all tasks fairly effectively, now if your project manager leaves, you’ll find that no one is able to fill the role very capably.

When a new role is created, the role’s designers have a very clear vision of how they want the new function to work. Many other individuals are not particularly concerned with how the creators want the function to work, and will view it as an opportunity to offload tasks that they find challenging, difficult, or uninteresting. This can lead to new roles being immediately underwater, which often feels like success to leaders attempting to grow the size of their organization. However, that can easily translate into an unlovable work experience for those performing the role.

For entirely great reasons, people want the first hires they make into a new role to be strong role models for the entire function. This often leads to a proliferation of requirements until it’s impossible for any candidate to pass the bar.

sometimes the existing organization has so little experience with the new function they wish to create that they simply don’t have a usable means by which to evaluate candidates.

Make sure that your recruiting team is able to support a new role! If they aren’t, the first step may be working with your executive sponsor to direct more head count toward recruiting.

New roles are frequently described in terms of how they’ll impact other functions, rather than in terms of what they’ll accomplish. For example, you might describe technical program managers (TPMs) as offloading project management responsibilities from engineering managers. This approach frames the role as an auxiliary, support function, which makes it difficult to recognize the work’s impact. You must be able to frame the role’s work without referencing other existing roles in order for it to succeed long-term.

Who will be the external and internal role models for this role?

Do you have a plan for changing how the company values the work? Creating a new role won’t inherently change how the company values this work. You’ll still need to do the hard work of expanding your company’s values.

Do not start designing a new interview loop until you’ve instrumented your hiring funnel.

Write up a list of ideal candidates for the role and write down what makes them ideal. Be deliberate about ensuring that your list of role models includes women and underrepresented minorities, helping avoid matching on correlating traits in a less diverse set of role models.

Avoid testing for polish. Many interviews accidentally test for the candidate’s polish as opposed to testing for any particular skill. This is especially true for experiential interviews in which folks are asked to describe their work, and less common in interviews that ask them to demonstrate skills. That isn’t to say that you shouldn’t deliberately test for polish—it’s quite useful—just that you shouldn’t do it inadvertently.

Avoid Boolean rubrics. Some tests tend to return Boolean results: for example, whether someone has experience managing someone is a good example of a common Boolean filter. These are inefficient tests because you pretty quickly get a sense of whether someone has or hasn’t ticked this box, and the rest of the interview doesn’t lend more signal. Likewise, you can almost always answer Boolean questions from an applicant’s resume or in a pre-interview screen.

Hiring for potential is a major vector for bias, and you should try to avoid it. If you do decide to include potential, then spend time developing an objective rubric for potential, and ensure that the signals it indexes on are consistently discoverable.

Writing a great interview loop is almost identical to writing a great career ladder.25 If you’ve already written expectations for the role, reuse those as much as possible.

Around the time your team reaches three engineers, you’ll want to be running a sprint process. There are many successful ways to run sprints. Try a few and see what resonates for you.

The criteria I use to evaluate if a team’s sprint works well: Team knows what they should be working on. Team knows why their work is valuable. Team can determine if their work is complete. Team knows how to figure out what to work on next. Stakeholders can learn what the team is working on. Stakeholders can learn what the team plans to work on next. Stakeholders know how to influence the team’s plans.

The mechanism I’ve found most helpful in this case is to ensure that every team has a clear set of directional metrics in an easily discoverable dashboard. The metrics should cover both the longer-term goals of the team (user adoption, revenue, return users, etc.) and the operational baselines necessary to know if the team is functioning well (on-call load, incidents, availability, cost, and so on.) For each metric, the dashboard should make three things clear: the current value, the goal value, and the trend between them.