An Elegant Puzzle: Systems of Engineering Management

by Will Larson

the focus here is on helping people transition from a personal view of productivity to a team view.

Especially for a team that started out falling behind and is now repaying debt, your stakeholders are probably antsy waiting for the team to start delivering new stuff, and your obligation is to prevent that impatience from causing a backslide!

The hard part is maintaining faith in your plan—both your faith and the broader organization’s faith. At some point, you may want to launder accountability through a reorg, or maybe skip out to a new job, but if you do that you’re also skipping the part where you get to learn. Stay the path.

For each constraint, prioritize one team at a time. If most teams are falling behind, then hire onto one team until it’s staffed enough to tread water, and only then move to the next. While this is true for all constraints, it’s particularly important for hiring.

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.

it most fruitful to move scope between teams, preserving the teams themselves.

The other approach that I’ve seen work well is to rotate individuals for a fixed period into an area that needs help.

problems bubble up from your peers, skip-level one-on-ones,16 and organizational health surveys.

What I’ve found most successful is to identify a few areas to improve, ensure you’re making progress on those, and give yourself permission to do the rest poorly. Work with your manager to write this up as an explicit plan and agree on what reasonable progress looks like.

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

They focus on four measures of developer velocity: Delivery lead time is the time from the creation of code to its use in production. Deployment frequency is how often you deploy code. Change fail rate is how frequently changes fail. Time to restore service is the time spent recovering from defects.

Pull requests are converted into ready commits based on our code review rate. Ready commits convert into deployed commits at deploy rate. Deployed commits convert into incidents at defect rate. Incidents are remediated into reverted commits at recovery rate. Reverted commits are debugged into new pull requests at debug rate.

Product management is an iterative elimination tournament, with each round consisting of problem discovery, problem selection, and solution validation. Problem discovery is uncovering possible problems to work on, problem selection is filtering those problems down to a viable subset, and solution validation is ensuring that your approach to solving those problems works as cheaply as possible.

Write a customer letter. Write the launch announcement that you would send after finishing the solution. Are you able to write something exciting, useful, and real? It’s much more useful to test it against your actual users than to rely on your intuition.

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.

If you’re targeting more than eight engineers per manager, then it’s worth reflecting on why you believe your managers can support a significantly higher load than industry average: Are they exceptionally experienced? Are your expectations lower than typical?

A few questions to ask yourself before you decide to fully commit: Are the changes meaningful net positive? Will the new structure last at least six months? What problems did you discover during design? What will trigger the reorg after this one? Who is going to be impacted most?

In general, the actual tactics for doing this are: Discuss with heavily impacted individuals in private first. Ensure that managers and other key individuals are prepared to explain

the reasoning behind the changes. Send an email out documenting the changes. Be available for discussion. If necessary, hold an organization all-hands, but probably try not to. People don’t process well in large groups, and the best discussions take place in small rooms. Double down on doing skip-level one-on-ones.

A prototypical head of engineering will be skilled at organizational design, process design, business strategy, recruiting, mentoring, coaching, public speaking, and written communication.

you can always find an opportunity to increase your scope and learning, even in a company that doesn’t have room for more directors or vice presidents.

Scarce feedback, vague direction

craft it into a strategy,

Make a clear decision on each of those pivots, write up a document explaining those decisions, and then see if you can get anyone to read it. They’ll disagree with a lot of what you’ve written, or else they’ll be confused by it. Keep testing, and refine the confusion down to the smallest group of controversial problems possible.

Once you have those problems, return to your rounds of engaging with experienced leaders at other companies, and ask them how they’ve made those trade-offs before. Ask them for their stories. Ask them for the context that made one path perfect early on, and why they changed their minds as their company grew larger. Incorporate everything you’ve learned into your strategy document, and you’re done. Well, almost. The one remaining problem is that almost no one will have the time to soak up the full detail of your overly precise document, so the final step is to distill it into something comprehensible without hours of close reading. I’m still working on the best way to do this, but I suspect that it’s cutting all unnecessary, and even most essential, complexity in order to capture as much of the meaning as possible in three to four bullet points.

For every problem that comes your way—an

Close out.

Solve. Design a solution such that you won’t need to spend time on this particular kind of ask again in the next six months.

Delegate.

The most effective way to provide opportunity to the members of your organization is through the structured application of good process. Good process is as lightweight as possible, while being rigorous enough to consistently work.

Team lunches

membership measurement

membership measurement

This is so important that I’ve come to believe that having a wide cohort of coworkers who lead critical projects is one of the most important signifiers of good organizational health.

I believe that on such teams coordination is only possible when the manager or a highly respected member operates as a referee, holding team members accountable for good behavior.

evaluation.

Partnership. Have they been effective partners to their peers, and to the team that they’ve managed? Execution. Can they support the team in operational excellence? Vision. Can they present a compelling, energizing vision of the future state of their team and its scope? Strategy. Can they identify the necessary steps to transform the present into their vision? Spoken and written communication. Can they convey complicated topics in both written and verbal communication? Can they do all this while being engaging and tuning the level of detail to their audience? Stakeholder management. Can they make others, especially executives, feel heard? Can they make these stakeholders feel confident that they’ll address any concerns?

Kill your heroes, stop doing it harder

Debugging or extending an existing codebase on a laptop (ideally on their laptop).

Roleplays (operating off a script that describes the situation.)

(architecting a system together, giving feedback on poor performance, running a client meeting, and so on).

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

Find role models. Write up a list of ideal candidates for the role and write down what makes them ideal.

Test for each skill. For each skill, design a test to evaluate the candidates’ strengths.

Don’t hire for potential. Hiring for potential is a major vector for bias, and you should try to avoid it.

to read after the book, about hosting a paper reading hub