Amdahl’s Law for Org Charts
What a three-page paper from 1967 explains about two-pizza teams, monoliths, and why your calendar time refuses to shrink
Amdahl’s Law for Org Charts
What a three-page paper from 1967 explains about two-pizza teams, monoliths, and why your calendar time refuses to shrink
Washington DC
Gene Amdahl presented a short paper at the AFIPS Spring Joint Computer Conference in 1967. He was the chief architect of the IBM System/360, and he stood in front of a room full of people excited about parallel machines to tell them the excitement had a ceiling. The paper, “Validity of the Single Processor Approach to Achieving Large-Scale Computing Capabilities,” runs about three pages. It contains no equation. The formula everyone now cites as Amdahl’s Law was distilled later, by other people, from an argument he made mostly in prose.
The argument goes like this. Every program contains work that must run sequentially: housekeeping, data management, and bookkeeping that cannot be split across processors. Amdahl pegged this overhead at a large fraction of executed instructions, and he observed that it had stayed stubbornly constant for a decade despite everyone’s best efforts. However many processors you add, that sequential fraction sits there, unmoved, setting a hard limit on your speedup.
The math, once someone wrote it down: if 10 percent of a program is sequential, infinite processors buy you at most a 10x speedup. Not 100x. Not 1000x. Ten. You can spend any amount of money on parallelism, and the serial fraction will quietly cap the return.
Amdahl was arguing about mainframes. The argument works just as well on org charts.
Teams are processors
An engineering organization is a parallel machine. Teams are the processors. Adding a team is supposed to add throughput, and headcount plans are written on exactly that assumption. The assumption holds only for the parallelizable fraction of the work.
The serial fraction of an organization looks like this: the release approval, the architecture review board, the shared staging environment, the security sign-off, and the cross-team decision that needs a meeting that needs a week to schedule. None of these are parallelized. Every team funnels through them. When an organization doubles its team count and delivery speed barely moves, the usual diagnosis is that the new teams need time to ramp. The better diagnosis is that the organization just added processors to a machine whose serial fraction was already the constraint.
There is a second cost stacked on top. Communication paths grow as n(n-1)/2. Six people share 15 paths. Twelve share 66. The visible symptom is meetings, but the real cost is context decay: past a certain size, no one holds the whole picture, so the group spends increasing effort reconstructing shared state that a smaller group would simply have. A twelve-person team pays this tax and then pays the serial-fraction tax on top of it.
Work time and clock time
Take a feature that shipped last month and split its history into two numbers. Work time: hours someone actively typed, designed, reviewed, and tested. Clock time: days between the ticket opening and the change reaching production.
A feature with six hours of work time routinely posts eleven days of clock time. The gap between those numbers is queue time, and queue time is where handoffs live. The frontend change waits for the API team. The API change waits for the review rotation. The reviewed change waits for the release train. The release waits for the sign-off. At each boundary, the work stops being work and becomes an item in someone else’s queue, and it sits there at the mercy of that queue’s priorities, not yours.
Estimates measure work time. Customers experience clock time. Roadmaps track neither queue explicitly, which is why a roadmap can look healthy while delivery feels slow: every task is “in progress,” and almost nothing is moving. When leadership asks why things take so long, the honest answer is usually that things don’t take long at all. Things wait long.
This is the serial fraction made visible. Handoffs are the organizational equivalent of Amdahl’s sequential instructions, and each one converts cheap work time into expensive clock time.
What two pizzas buy
The two-pizza rule gets retold as a headcount heuristic, a cute way of saying keep teams small. Small is a side effect. What the size actually buys is a closed loop.
A team small enough to feed with two pizzas can hold an entire feedback cycle inside its own boundary. It senses the problem, decides the fix, builds it, ships it, and gets paged when the fix breaks. Sense, decide, build, ship, observe, all inside one room. No queue between decide and build. No queue between build and ship. The serial fraction shrinks to the set of decisions the team can settle in a hallway conversation.
This gives ownership a definition sharper than anything on an org chart. Ownership is the failure domain: the team that gets paged owns the thing. If an incident in your system wakes up another team, the boundary is drawn wrong, whatever the wiki says. Ownership drawn any other way produces a diagram, not a behavior.
The loop matters more than the number. Cut a large team into small ones without closing each loop, and you get small teams with more handoffs than before, which is the worst of both configurations: the context decay of separation plus the queue time of dependency.
Why monoliths make this hard
Companies on monolithic repositories tend to struggle with all of the above, and the reason sits in the previous section. A monolith imports a serial fraction into every team’s loop.
One trunk, one build, one release train, one deployment pipeline. Every team’s change waits in every other team’s queue. Your two-pizza team decides quickly, builds quickly, and then joins a release that also carries four other teams’ changes, one of which just failed integration tests. The boxes on the org chart look independent. The queue underneath them is shared. You have drawn a parallel machine on top of a serial one.
The counterexamples prove the point rather than refuting it. Google runs a famously effective monorepo, and it does so by spending enormous, continuous effort on build isolation, ownership files, automated presubmit checks, and tooling that lets a change land without a human coordination step. That spending has one purpose: driving the shared serial fraction toward zero. Most companies copy the repo shape and skip the spending, which gets them to the queue without the machinery that makes the queue short.
The older version of the same mistake is the layer-based org: a UI team, a services team, a database team. Every feature crosses all three, so every feature pays three queues. Worse, ownership of the outcome belongs to nobody, because each layer owns a skill rather than a result. The UI team optimizes UI metrics, the database team optimizes database metrics, and the feature that spans them has no owner and no failure domain. These boundaries feel natural because they follow expertise. They fail because expertise is not what breaks at 3 AM. Systems break at 3 AM, and systems cut across layers.
Contracts instead of coordination
Dependencies don’t disappear because you dislike them. The platform team exists. The payments service exists. The question is what carries the coordination load at each boundary: a meeting or a contract.
A versioned API with a published schema, an SLA, and a deprecation policy lets two teams move at full speed without talking. The interface does the coordinating. A meeting does the same job slower, doesn’t scale, and has to be repeated every time context decays. Where a boundary is genuinely necessary, invest in the contract until the synchronous conversation becomes rare, then reserve the synchronous time for the ambiguity contracts can’t resolve.
And where a boundary isn’t necessary, move it. Draw team lines where the failure domains already fall, not where the skills cluster, so that an incident resolves inside one team instead of spawning a bridge call across three.
The honest complication
In 1988, John Gustafson, working at Sandia, pushed back on Amdahl with a simple observation: in practice, people who get bigger machines don’t run the old workload faster. They grow the workload to fit the machine.
Organizations do the same thing. Add teams and scope expands to absorb them; the same features rarely ship faster, but more features ship. Sometimes that’s exactly what the business needs, and the honest version of a headcount plan says so. The trouble starts when the plan promises Amdahl’s outcome, faster delivery of the current scope, while the organization quietly delivers Gustafson’s, more scope at the current speed. Those are different products, and only one of them fixes a slow roadmap.
Where to start
Before adding a team, find the serial fraction. Pull the last five features you shipped and compute both numbers for each: work time and clock time. The gap tells you where the queues are. The queues tell you which handoffs to eliminate, which contracts to build, and which boundaries to redraw. Amdahl needed three pages to make the argument for machines. For an org, the argument fits in a spreadsheet with two columns.
By Joshua McDonald on July 23, 2026.
Exported from Medium on August 26, 2026.
Reader discussion