Amdahl’s Law

Here is one feature's path from idea to customers, in weeks, through six of the lifecycle's seven stages. The seventh, organization (who the company serves and why it wins), is usually settled before any single feature starts. The numbers are illustrative, and the shape will be familiar:

Goals          █              1
Roadmap        █              1
Refinement     ███            3
Specification  █              1
Build          ██             2
Go to market   ██             2
Total                        10 weeks

Now give the team coding agents good enough that Build takes no time at all:

Goals          █              1
Roadmap        █              1
Refinement     ███            3
Specification  █              1
Build                         0
Go to market   ██             2
Total                         8 weeks

Infinitely fast engineering, and the feature ships 1.25 times sooner. That is the most it can improve, no matter how good the agents get, because Build was only a fifth of the trip. One CTO quoted on our homepage put the feeling more bluntly: "We spent all this money, and I'm in the same goddamn meetings."

Amdahl's Law is the observation that when you speed up one part of a job, the part you didn't speed up limits how much faster the whole job can get. If a fraction of the work can't be accelerated, the overall speedup can never exceed one divided by that fraction.

What Amdahl actually wrote

Gene Amdahl was at IBM when he presented "Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities" at a conference in Atlantic City in April 1967. The paper is three pages long. When the IEEE Solid-State Circuits Society reprinted it in 2007, the editors noted that "it has no equations and only a single figure." The formula people now call Amdahl's Law was written down by others later. Amdahl made the argument in prose.

The argument was aimed at enthusiasts of the day who believed computing's future lay in wiring many processors together. Amdahl looked at what real programs spent their time on. Data management housekeeping, he found, "accounts for 40% of the executed instructions in production runs," and "the nature of this overhead appears to be sequential so that it is unlikely to be amenable to parallel processing techniques." Even if a dedicated machine cut that overhead by half or by two thirds, he wrote, "overhead alone would then place an upper limit on throughput of five to seven times the sequential processing rate."

Then he drew the conclusion that gave the law its force: "the effort expended on achieving high parallel processing rates is wasted unless it is accompanied by achievements in sequential processing rates of very nearly the same magnitude."

Two decades later, John Gustafson at Sandia National Laboratories summarized the argument in the form most people now know: "even when the fraction of serial work in a given problem is small, say s, the maximum speedup obtainable from even an infinite number of parallel processors is only 1/s."

The product lifecycle has a serial fraction

Our essay on the modern product development lifecycle makes the same point about product teams without the math. The product development lifecycle is not the software development lifecycle. An idea travels through seven stages: organization, goals, roadmap, refinement, specification, build, and go to market. Coding agents work inside one of them.

Read through Amdahl, the rest of the lifecycle is the serial fraction. Refinement is research, legal, compliance, customer conversations and the meetings where a team decides what it's actually doing. Go to market is sales, support and marketing learning what changed. These stages run on people talking to people, and a faster code generator doesn't shorten a conversation with legal.

The arithmetic is unforgiving in the same way it was for Amdahl's processors. If Build is a fifth of the lifecycle, the ceiling is 1.25x. If it's a third, the ceiling is 1.5x. Teams that measured agent adoption by how much faster engineers write code are measuring the parallel part and wondering why the total barely moved.

Gustafson's correction makes it worse

Gustafson's 1988 paper, "Reevaluating Amdahl's Law," pushed back on Amdahl for supercomputers, and the pushback is worth taking seriously. His point was that nobody keeps the problem the same size when they get a faster machine: "When given a more powerful processor, the problem generally expands to make use of the increased facilities." On Sandia's 1024-processor system, the parallel work grew with the machine while the serial part stayed put, and the measured speedups were far better than Amdahl's fixed-size argument predicted.

Product teams do exactly what Gustafson described. When Build gets cheap, they build more: more experiments, more features, more parallel tracks. But in a product organization, unlike Gustafson's simulations, the serial work doesn't stay put when the problem grows. Every additional feature needs its own decision, its own review, its own spec and its own launch. More output from Build means more input to the stages that couldn't speed up. Our essay lists what that looks like from the inside: more asks for the data team, more time with compliance and legal, more coordination and status reporting.

That's the trap. Amdahl says faster Build won't speed up the whole. Gustafson says the team will use faster Build to do more. Put together, the serial stages get both the cap and the extra load.

Where Brief fits: working on the serial fraction

Amdahl's own prescription was to improve the sequential part at the same rate as the parallel part. For a product organization, that means the work between strategy and code: deciding, recording, finding out what was decided, and telling everyone who needs to know. That's where Brief works. As the homepage puts it, Brief "works across all product stages, not just Build. It captures decisions where they happen, connects them into one graph, and acts on them."

Here is what that does to the serial time, piece by piece.

Waiting for a decision stops being invisible. A lot of Refinement time isn't spent deciding. It's spent waiting for a decision nobody can see is stuck. Brief keeps proposed decisions separate from confirmed ones, and the decision list filters by status, so what's still awaiting confirmation is one filter away; coding agents can call brief_list_pending_decisions for the same queue. The homepage's example is a pricing decision "waiting on CPO sign-off since Sep 26," linked to the Slack thread, the Confluence spec, the Jira ticket and the GitLab merge request it affects. A stalled decision with a date and an owner attached is a much shorter conversation than a vague sense that pricing is blocked.

Build stops guessing, and stops stopping. Coding agents connected over MCP ask Brief before they write code. In the homepage example, an agent asked to add per-seat pricing calls brief_ask, learns the pricing decision is still pending, holds the change, and flags a related security review it found. From a terminal or CI pipeline, brief ask --mode check runs the same kind of check against existing decisions. The fast stage stops producing work the slow stages will have to undo, which matters more under Gustafson's version of the law, where Build is producing more than ever.

The question gets answered without a meeting. Much of the serial time in a product org is people asking what was decided. Brief reads decisions from Slack, Jira, Confluence and GitLab, self-hosted included, so engineers, sellers and their agents can ask what was decided and why and get the decision, its status and its source. Each answered question is one less entry on somebody's calendar.

Status reporting comes to the people who need it. The Weekly Strategic Brief sends the week's analysis by email, with a Discuss with Brief link that opens a chat with its context. That's coordination work a person used to assemble by hand each week.

None of this makes the serial fraction disappear, and Amdahl would be the first to say it can't. Deciding is still a human act: someone still has to weigh the pricing change, talk to the customer, and make the call legal needs to make. Brief shortens the time around those acts, the waiting, the asking, the re-explaining and the reporting, which is the part of the serial fraction that was never judgment in the first place. Amdahl's math applies to that too. Every week taken out of the stages around Build raises the ceiling on what faster code can deliver.

Which stage of your lifecycle would set the ceiling if Build took no time at all?

Objections