More Hands, Not Always Faster

Imagine hiring ten capable people and discovering that your project still has a one-person speed limit.

In 1967, computer architect Gene Amdahl argued that the parts of a computing job that cannot be parallelized limit the gains from adding processors. The insight became known as Amdahl's law. He was analyzing computers, not creative departments, but the distinction between parallel and sequential work is useful well beyond computing.

1. The mechanism

A task contains work that can be divided among workers, plus work that has to happen in sequence. If a fixed workload takes one processor a certain amount of time, let p be the fraction of that time spent on perfectly parallelizable work. With N processors, the ideal speedup is:

Speedup = 1 / [(1 - p) + p/N]

Suppose 80% of a job can be divided perfectly and 20% cannot. With four processors, the normalized runtime is 0.20 + 0.80/4 = 0.40. The job becomes 2.5 times faster, not four times faster.

Even with unlimited processors, the remaining 20% limits speedup to five times. Additional processors cannot make the serial portion vanish.

This is a mathematical ceiling under ideal assumptions: fixed work, unchanged output quality, perfect balancing, and no communication or coordination overhead. Real systems often perform worse.

2. Outside CPG: An observatory's data

Imagine a hypothetical observatory processing one night's images. Eight hours of the original ten-hour workload consist of independent image tiles that can be distributed across machines. The remaining two hours are sequential setup and final validation.

Give the parallel work four equally capable machines. Under the ideal model, tile processing falls to two hours, but validation and setup still take two. Total runtime falls from ten hours to four, a 2.5-fold speedup.

The example is illustrative, not a reported observatory result. Actual astronomical workflows have dependencies, data-transfer costs, and different validation designs.

The lesson is that the fastest part of a workflow may not be the part worth accelerating next.

3. Bring it into a beverage launch

Consider a hypothetical package refresh. A creative team can now generate and refine artwork much faster. That's valuable. But the product may still need decisions about claims, formulation accuracy, printer proofing, and final signoff.

If those steps must happen in a strict sequence, speeding up artwork alone has a limited effect on the end-to-end date.

The commercial decision: Before adding freelance design capacity or buying another rendering tool, measure where the elapsed time actually goes. Separate production work from approval waits, rework, and dependencies. Bring the relevant reviewers into the brief early, clarify decision rights, and agree on proof criteria. Do not remove necessary safety or compliance checks just to make a timeline look better.

This application is an analogy, not a claim that an approval workflow literally follows the processor formula. Human coordination, waiting time, and rework need their own measurements.

4. Challenge an assumption

"More capacity should make the whole project proportionally faster."

Only when the added capacity accelerates enough of the work that determines completion.

There is a serious counterargument. Sometimes extra capacity lets you change the workflow itself, parallelize previously sequential stages, or undertake a larger and better project. In 1988, John Gustafson emphasized that the fixed-problem-size assumption does not describe every computing objective. Amdahl's law is not an argument against growing a team. It is an argument against expecting proportional gains without understanding the work.

5. Your mental operator

Identify the irreducibly sequential fraction before optimizing the easily accelerated fraction.

Ask what must happen after everything else, what can genuinely happen at the same time, and which dependency can be redesigned without weakening the outcome.

6. Reasoning exercise

A hypothetical scientific simulation takes 12 hours on one machine. Three hours are sequential setup and verification; nine hours can be divided perfectly among six processors.

Before looking below: How long does the job take with six processors? What is the maximum possible speedup if the processor count approaches infinity?

Worked answer

With six processors, the parallel work takes 9/6 = 1.5 hours. Add three sequential hours: 4.5 hours total. Speedup is 12/4.5 = 2.67 times (rounded).

Even with infinitely many processors, the job cannot beat the three-hour sequential portion under these assumptions: 12/3 = 4 times maximum speedup.

Today's takeaway: Don't confuse making one task faster with making the whole system faster. First find what still has to happen in sequence.

Educational editorial content. Hypothetical examples are labeled in the original edition.