An Elegant Puzzle

Larson's distinctive move is treating an organisation as a system with stocks, flows and feedback loops rather than as a collection of people with attitudes.

His argument is that most management problems that appear to be about individuals are actually about rates — how fast work enters a team, how fast it leaves, how much is in progress — and that changing the rate is usually more effective and far less personal than changing the people.

Most problems that look like people problems are rate problems, and rates are easier to change than people.

Devmark’s reading — not a quotation from the book

His specific guidance, which is more concrete than most: teams of six to eight engineers, with managers supporting no fewer than four and no more than eight.

His reasoning is structural. Below four, a manager has spare capacity and will fill it by doing individual work, which makes them a bottleneck. Above eight, they become a pure coordinator with no time for the coaching that makes the team improve.

His framework for diagnosing where a team actually is: falling behind, treading water, repaying debt, and innovating — each requiring a different intervention.

The prescriptions are specific and counter-intuitive. A falling-behind team needs to hire; a treading-water team needs to consolidate work into larger batches; a debt-repaying team needs time; and only an innovating team should be given additional scope.

His warning against the reflex to solve a struggling team by moving people into it: adding engineers to a team that is already struggling with coordination increases the coordination burden.

His alternative sequence — reduce work in progress, consolidate, then staff — is a direct application of the systems view and contradicts the common instinct.

One of his sharpest claims: migrations are the only mechanism by which a technical organisation escapes accumulated constraints, and they are chronically under-invested in because they produce no new features.

His practical guidance on running them — derisk, enable, then finish, with the finishing step explicitly owned — addresses the standard failure of migrations that reach ninety per cent and stop there permanently.

Migrations are the only way out of accumulated constraint, and they reliably stall at ninety per cent.

Devmark’s reading — not a quotation from the book

His treatment of decision-making at scale: as an organisation grows, the question shifts from making good decisions to designing the system that makes them, including who has authority and how disagreement is escalated.

His work on architecture review, technical specifications and design documents is aimed at that — creating a process that produces consistent decisions rather than relying on any individual's judgement.

His material on levelling, promotion and performance management is unusually direct about the mechanics: how to write a levelling rubric, how promotion committees actually behave, and how performance distributions get applied.

His observation that most perceived unfairness in promotion comes from undocumented criteria rather than from bias in application is contestable and worth arguing with.

It is written for engineering management in venture-funded technology companies at a specific scale — roughly fifty to several hundred engineers — and much of it assumes that context.

Managers in smaller organisations, in non-technical functions, or in companies without the resourcing to run migrations and hire into falling-behind teams will find the prescriptions harder to apply.

It is a collection rather than a book, assembled from Larson's blog, and reads that way: essays of varying length and depth, some overlapping, without a developed through-line.

That makes it excellent as a reference and poor as a linear read. Most readers get more from dipping into the relevant essay when a problem arrives than from working through it.

The four-states diagnostic is the single most useful tool here, because it prevents the most common management error — giving a struggling team more scope, or hiring into a team whose problem is coordination.

And the rate-based framing, which converts a great many uncomfortable conversations about individuals into tractable conversations about how work flows.