the-elegant-puzzle | Danny Zuckerman

Kindle Highlights: An Elegant Puzzle: Systems of Engineering Management

Highlights

Organizational design gets the right people in the right places, empowers them to make decisions, and then holds them accountable for their results. Maintained consistently and changed sparingly, nothing else will help you scale more. — location: 178 ^ref-28242

if process is too weak a force, and culture too slow, then organizational design lives between those two. — location: 205 ^ref-26051

Small teams (fewer than four members) are not teams — location: 247 ^ref-50340

Keep innovation and maintenance together. — location: 253 ^ref-37823

you’ll get higher morale and a culture of learning, and will avoid creating a two-tiered class system of innovators and maintainers. — location: 255 ^ref-54929

playbook that I’ve developed is surprisingly simple and effective: 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 create empty teams. Never leave managers supporting more than eight individuals. — location: 257 ^ref-24387

Teams want to climb from falling behind to innovating, while entropy drags them backward. Each state requires a different tact. — location: 287 ^ref-39677

If your company is designing systems to last one order of magnitude and is doubling every six months, then you’ll have to re-implement every system twice every three years. This creates a great deal of risk—almost every platform team is working on a critical scaling project—and can also create a great deal of resource contention to finish these concurrent rewrites. — location: 453 ^ref-57518

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. — location: 456 ^ref-15728

system that we can use to reason about developer productivity: 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. Linking these pieces together, we see a feedback loop, in which the system’s downstream behavior impacts its upstream behavior. With a sufficiently high defect rate or slow recovery rate, you could easily see a world where each deploy leaves you even further behind. If — location: 639 ^ref-35867

Compounding leverage. What are the composable blocks you could start building today that would compound into major product or technical leverage10 over time? I think of this category of work as finding ways to get the benefit at least twice. These are potentially tasks that initially don’t seem important enough to prioritize, but whose compounding value makes the work possible to prioritize. — location: 700 ^ref-39925

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. — location: 767 ^ref-5653

When you read good guiding policies, you think, “Ah, that’s really going to annoy Anna, Bill, and Claire,” because the approach takes a clear stance on competing goals. — location: 794 ^ref-19057

When you apply your guiding policies to your diagnosis, you get your actions. — location: 795 ^ref-65034

I’ve found that the hardest part of writing a good strategy is pretty mundane. You must be honest about the constraints that are making the challenge difficult, which almost always include people and organizational aspects that are uncomfortable to acknowledge. No extent of artistry can solve a problem that you’re unwilling to admit. — location: 807 ^ref-4225