Engineering Management Is an Elegant Puzzle: Fix the System, Not the Events

There’s already a leadership series on this site (Becoming a Tech Leader), so why start another one?

Because that book is about how a person grows into a leader — influence, self-awareness, vision. Will Larson’s An Elegant Puzzle: Systems of Engineering Management is about the system that leader is holding: how big a team should be, how to diagnose the state it’s in, where the risk sits, how technical debt actually gets repaid, how policy gets written, how levels get defined, how hiring gets measured. Larson’s résumé is what earns him the angle — Digg, Uber, Stripe, the last two places where the org grew so fast that a management problem got rewritten by scale before you’d finished solving it.

The title isn’t decoration, it’s a stance: Larson writes every management problem as a systems problem, with stocks, flows and lag. That happens to be the lens this blog keeps using — earlier series pointed “the system” at databases and clusters; this one points it at the organization.

The shift: your output isn’t “things handled”, it’s “things that stopped happening”

The book’s first and most important claim: what you operate on is the system, not the events.

A release broke again, a request jumped the queue again, someone got burned out again, a candidate no-showed again — those are events. They land on your desk one at a time, and the faster and more gracefully you catch them, the more they get taken for granted. What actually decides how many land on you next week is the system upstream that keeps emitting them: who’s on which team, what needs your sign-off, which rules are written down and which ones only live in your head.

This week's workload looks about the same on both sides. Next week is where they diverge: the left never touched the source, the right emits a little less — and the right pays nothing back this week, which is exactly why most people never do it

Two consequences follow. First, the way you measure yourself has to change: “how many things I caught this week” is a timesheet; “which class of thing stopped happening this month” is output. Second, every change to a system pays back late — a policy takes a quarter to show, a hire takes three to six months to produce, a levelling system takes a full cycle before you know whether it’s fair. Changing code tells you today; changing an organization doesn’t. That lag runs through the whole book, and this series keeps flagging it.

One line you can actually use: when the same thing happens for the third time, stop handling that thing — go change the system that keeps emitting it.

The shape of the book: five chapters, five questions

There are seven chapters: chapter 1 is the introduction, chapter 7 an appendix (tools sorted by management level, plus reading lists). The five in between are the body — and instead of memorizing chapter names, read them as five questions in order:

The five chapters are one line, not five topics: each one moves something from "it works because someone remembers" to "the system does it anyway" — structure first, then tools, then your defaults and your culture, and finally the career systems that nail fairness down

One appetizer from each chapter:

Chapter	The question	One signature move
Ch2 Organizations	How big, and what state is it in	The four states of a team: falling behind / treading water / repaying debt / innovating — four states that need four different prescriptions, not “hire more people” every time
Ch3 Tools	What can you use to change things	Migrations are the only scalable fix to tech debt: de-risk → enable → finish, and an unfinished migration is the most expensive debt of all
Ch4 Approaches	What’s your default	Work the policy, not the exceptions — every “just this once” is an instruction to the system with no version control on it
Ch5 Culture	Who gets opportunity, who gets to belong	Kill your heroes: a hero makes it impossible for everyone else to contribute meaningfully, and burns out first anyway
Ch6 Careers	How people stop guessing	Hiring is a production line you can measure; a career ladder isn’t for ranking people, it’s so nobody has to guess where they stand

I’m unpacking none of those here — each is its own post later. For now, notice one thing: they’re all the same move in different clothes — take the thing that keeps recurring and go solve it one layer up, in the system.

Three marks this series carries in every post

The failure mode of reading management books is nodding all the way through and then going back to your desk to fight the same fires. So this series holds itself to three marks, and every post has to answer them:

【Which system is emitting this】 — what exactly is the system behind the recurring event in this post? If you can’t name it, the post is just an essay with opinions.
【Time to effect】 — how long until this works? Hiring takes three to six months, a migration is measured in quarters, a levelling system needs a full cycle. Skip this and the reader quits after two weeks of no visible change.
【The Four-Engineer Version】 — with no HR, no career ladder, no recruiter, and four people on the team, what’s the minimum viable version of this move? Which moves shouldn’t be made at all?

The third one is this series’ signature — and it’s what the next section is about.

The honest part: a book written for rocket ships, read by four engineers

This book’s raw material comes from places that add a whole team every quarter. The stretch of leading people I’ve written about on this blog was a different scale entirely — six engineers, with only four on the storefront line, no estimation and no demos, fully remote, with product handled full-time by a CTO who didn’t write code. And it didn’t end in growth: development was paused, the contract went into renegotiation, the team was three people a month later, and then it shut down.

So let me be explicit from post one about how this series reads the book: it’s a translation, not a repost. Three rules for it:

Ask what a move is solving before you look at the shape it takes. The shape — a committee, a calibration meeting, a promotion packet — is a product of scale. The problem behind it (who decides, on what grounds, does it still hold next time) exists just as much on a team of four; it’s just that the answer shrinks from an institution to a shared understanding and a one-page doc.
No written system doesn’t mean no system. A team without a written career ladder still has one — it lives in the manager’s head, and nobody can be sure this time’s standard matches last time’s. The trouble with that implicit system is that it can’t be checked.
When the org is shrinking, one prescription disappears outright. The book’s material comes almost entirely from growing organizations, and the first prescription in its four states of a team is “hire”. When headcount is going the other way, that road is gone and you’re left with consolidating your efforts and adding time. The shrinking half gets its own post at the end of this series — which is exactly where the ending of that stretch falls.

Larson deserves credit here, though: he opens chapter 6 with a section titled Roles over rocket ships, and why hypergrowth is a weak predictor of personal growth — what actually decides how fast you grow is the role and the opportunities you get, not how fast the company grows. So the small-team lens isn’t an argument with the book; it pulls that line further.

Reflection

Four practices from back then: two handed to tools, two resting on a person

In the first leadership post on this blog I described what I was doing at the time: passing on knowledge through code review, holding the team together with a coding style, a type checker to take the weight of consistency off everyone’s shoulders, regular 1-on-1s. The reflection in that same post named two problems: “when I let code review sit too long, I become the thing slowing the team down; and 1-on-1s without follow-up end up feeling like a formality.”

Read that list again through this book and it splits cleanly. Of the four practices, coding style and type consistency were handed to tools — that post itself says the type checker is there “to take the weight of consistency off everyone’s shoulders”, and the team post says it outright: “Matters of form never reach a human brain — ruff and mypy mechanise style and types”. The two that got flagged as problems are exactly the two that could only run on a person: the rhythm of review, and the follow-up on 1-on-1s. That’s the class of thing this book’s first shift is aimed at — a mechanism that rests on a person rises and falls with that person, and when it slips, nothing usually raises a warning first.

The book’s prescription turns straight into a habit: when you’re about to say “just a reminder”, count which time this is. If it’s the third, what needs fixing isn’t anyone’s memory — it’s whatever keeps making this need a reminder. A checklist, a default, a CI rule, anything, as long as it isn’t somebody’s attention.

”Speed is a function of process shape” — the same shift, from the trenches

In the reflection of that post about the team I wrote this: “Speed is structural, not heroic. … To reproduce this team’s speed, don’t look for four superhumans — dismantle those four frictions first — speed is a function of process shape; people are the coefficient and the shape is the exponent.” The same post lists how those four frictions were taken apart: near-zero ritual, merge equals release, order the queue rather than schedule it, zero translation of specs.

Read next to this book, the two are saying the same thing: don’t put more force into the events — change the shape that produces them. Heroics is exactly putting more force into the events — somebody pushing harder, holding out longer; Larson treats it as serious enough to title a chapter 5 section Kill your heroes, stop doing it harder.

The next question this book asks: does that shape still run with a different set of people? How much of it is written down, how far a new hire can follow it on day one, which piece actually rests on one person — the later posts on where risk sits and on heroes will come back to it.

With AI in the room, the layer this book covers matters more

In The Responsibility Funnel I described a shape: what AI eats is the wide top of the funnel — code, tests, research, first drafts; what it can’t eat is the person at the neck who has to sign.

Lay that shape over this book and you can derive an extension — an inference, not something the book says: as AI pushes down the unit cost of handling events, the gap between managers becomes more concentrated on whether they’re changing the system. The book came out in 2019, and nothing in its table of contents is about AI; but the layer it covers — structure, process, policy — is exactly what the person at the neck still has to decide. That’s also where this series and the AI series divide the work: the responsibility axis of AI stays out of here — that line already has its own series. This one is about the organization itself.

One verdict to close this post on: the most expensive illusion in management is mistaking “I caught everything” for doing the job well — catching it only means the system hasn’t been fixed yet, and it’s still charging you interest.