An Elegant Puzzle: Systems of Engineering Management

by Will Larson

Organizational design gets the right people in the right places, empowers them to make decisions, and then holds them accountable for their results.

Organizations

.h1

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.

2.1 Sizing teams

.h2

the fundamental challenge of organizational design is sizing teams.

Managers should support six to eight engineers

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

.c1

it’s a role with limited career opportunities.

.c2

Coaches. Managers supporting more than eight or nine engineers typically act as coaches and safety nets for problems. They are too busy to actively invest in their team or their team’s area of responsibility.

Managers-of-managers should support four to six managers

On-call rotations want eight engineers

Small teams (fewer than four members) are not teams

Keep innovation and maintenance together.

Teams should be six to eight during steady state.

To create a new team, grow an existing team to eight to ten, and then bud into two teams of four or five.

Never leave managers supporting more than eig...

2.2 Staying on the path to high-performing teams

.h2

2.2.1 Four states of a team

.h3

A team is falling behind if each week their backlog is longer than it was the week before.

A team is treading water if they’re able to get their critical work done, but are not able to start paying down technical debt or begin major new projects.

A team is repaying debt when they’re able to start paying down technical debt, and are beginning to benefit from the debt repayment snowball:

A team is innovating when their technical debt is sustainably low, morale is high, and the majority of work is satisfying new user needs.

2.2.2 System fixes and tactical support

.h3

When the team is falling behind, the system fix is to hire more people until the team moves into treading water.

When the team is treading water, the system fix is to consolidate the team’s efforts to finish more things, and to reduce concurrent work until they’re able to begin repaying debt (e.g., limit work in progress).

When the team is repaying debt, the system fix is to add time.

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!

Innovating is a bit different,

.c1

In this case, it’s to maintain enough slack in your team’s schedule that the team can build quality into their work,

There is not much work or activity.

In this case, it’s to maintain enough slack in your team’s schedule that the team can build quality into their work,

.c2

2.2.3 Consolidate your efforts

.h3

For each constraint, prioritize one team at a time.

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.

2.2.4 Durable excellence

.h3

2.3 A case against top-down global optimization

.h2

2.3.1 Team first

.h3

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,

The lesson is that you have to account for re-gelling costs after periods of change,

2.3.2 Fixed costs

.h3

most teams have high fixed costs and relatively small variable costs:

Spliting a team into two doubles the fixed cost.

2.3.3 Slack

.h3

you can often slow a team down by shifting resources to it,

The Goal by Eliyahu M. Goldratt10 and Thinking in Systems: A Primer by Donella H. Meadows11 are both phenomenal books on this topic.

.rl

2.3.4 Shift scope; rotate

.h3

If a team has significant slack, then incrementally move responsibility to them, at which point they’ll start locally optimizing their expanded workload.

do this slowly to maintain slack in the team,

Shifting scope works better than moving people because it avoids re-gelling costs, and it preserves system behavior.

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

2.4 Productivity in the age of hypergrowth

.h2

2.4.1 More engineers, more problems

.h3