The Coordination Tax: Why Splitting Work Has a Cost

A manager facing a deadline reaches for the most natural lever available: add people. The intuition is arithmetic and comforting, that two engineers finish in half the time and four in a quarter. Yet anyone who has shipped software knows the lever slips. Somewhere past the first collaborator, the schedule stops shortening and starts to fight back, consumed by meetings, merge conflicts, clarifying questions, and the slow re-explanation of intent that never appears on any task board. That friction has a name worth taking seriously. It is a tax on coordination, it is levied on every unit of shared work, and unlike the labor it accompanies, it does not scale in your favor. This article makes that tax explicit, derives its shape from established results, and shows why the arithmetic of splitting work is quadratic where the benefit is at best linear.

What the coordination tax is

Define coordination cost as any effort spent keeping separate contributors consistent that does not itself produce the artifact. Writing a function is production. Explaining what the function must do, agreeing on the interface it exposes, reconciling it against a change someone else made, and rebuilding your mental picture after an interruption are all coordination. The distinction matters because the two kinds of effort obey different laws. Production work is roughly divisible: a task of size W can, in principle, be shared. Coordination work is not divisible in the same way, because it is generated by the relationships between contributors rather than by the task itself.

This framing lets us state the thesis precisely. The benefit of adding a person is bounded above by the production work they can absorb, which falls as the team grows and each person's slice shrinks. The cost of adding a person is the new set of relationships they introduce, which rises as the team grows. When a rising cost meets a falling benefit, there is a crossover, and beyond it every additional contributor makes the whole slower. The remainder of this piece is an attempt to locate that crossover using results that predate the argument by decades, and then to ask what artificial-intelligence assistance does to its position.

Nothing here argues against collaboration in general. Large systems, long-lived products, and high-stakes changes derive real value from multiple minds, and that value is treated honestly in the closing section. The claim is narrower and more useful: for a single, well-scoped unit of work with a clear plan, the coordination tax is a first-order cost that is routinely ignored in staffing decisions, and ignoring it produces teams that are provably too large for the job in front of them.

Brooks's arithmetic: communication paths grow quadratically

Frederick Brooks, reflecting in 1975 on the IBM OS/360 effort, observed that the number of communication channels among a group does not grow with its headcount but with the pairs of people in it. A group of n contributors has n(n-1)/2 potential channels, the count of distinct pairs. Two people share one channel; add a third and there are three; a fourth brings the total to six; by eight people there are twenty-eight relationships that must, at some level, be kept coherent. This is the combinatorial engine underneath Brooks's better-known aphorism that adding manpower to a late software project makes it later.

The consequence is that the marginal person is more expensive than the last. Moving from four to five contributors does not add one relationship; it adds four, because the newcomer must be connected to everyone already present. The production capacity added by that person is at most one worker's worth and usually less, since they must first be brought up to speed. Set the linear gain against the quadratic cost and the shape of the problem is already visible before any human factor is introduced.

The table below tabulates the raw arithmetic. The final column, the paths introduced by the incoming person, is the honest marginal cost of that hire measured purely in relationships, and it is the term that any staffing decision should weigh against the fraction of the task the newcomer can actually take off the critical path.

Amdahl's mirror: coordination is the serial fraction

Gene Amdahl's 1967 argument about parallel computing turns out to describe teams as faithfully as it describes processors. Amdahl noted that if a fraction of a job is inherently serial, then no quantity of parallel resource can make the whole job faster than that serial part allows. If a proportion p of the work can be parallelized and the remainder cannot, the speedup from n workers climbs ever more slowly as staff are added, and its ceiling, no matter how many people you add, is one divided by the serial fraction.

Read coordination as the serial fraction and the analogy becomes a claim. The parts of a feature that genuinely divide, the independent modules and separable tests, are the parallel fraction p. The parts that do not divide, the shared decisions, the interface agreements, the integration and reconciliation, are the serial remainder 1-p. Amdahl's ceiling then says that a team's throughput on a coupled task is capped by how much of the work is irreducibly shared, no matter how many people are thrown at the parallel part. A task that is ninety percent parallelizable cannot be sped up more than tenfold even with infinite staff; if it is only seventy percent parallelizable the ceiling is barely more than threefold.

The uncomfortable corollary is that coordination and the serial fraction are not independent. Adding people tends to raise 1-p, because more contributors means more interfaces to agree and more state to keep consistent. In Amdahl's original setting the serial fraction is a fixed property of the algorithm; in a team it grows with n. That makes the team's ceiling worse than a naive reading suggests, and it is the formal reason the speedup curve does not merely flatten but can bend back down once the human costs of the next two sections are included.

Conway's law: the communication graph becomes the artifact

Melvin Conway's 1968 observation adds a structural twist that raises the stakes of the tax. Conway argued that any system designed by an organization is constrained to reproduce the communication structure of that organization. The seams in the software end up where the seams in the conversation are. Two teams that talk through a weekly sync will build two components joined by a coarse, defensive interface, because that interface is a mirror of how they actually coordinate.

This means coordination cost is not only paid in time; it is paid in design. The relationships enumerated by Brooks's arithmetic do not merely consume schedule, they imprint themselves on the architecture, and a poorly chosen team boundary becomes a poorly chosen module boundary that outlives the project. When a single feature is split across several contributors, the split leaves a scar on the code exactly where the human interface ran, whether or not that is where a clean design would have placed it.

The practical reading of Conway's law for a single well-scoped task is stark. If one person holds the whole task, the internal interfaces can be drawn where the problem wants them, and redrawn freely as understanding improves. If the task is divided, its internal boundaries harden around the communication structure of the people, and every later change must be negotiated across a seam that exists for organizational reasons rather than technical ones.

The human ledger: cognitive load, flow, and interruption

The arithmetic so far is bloodless; the human factors are where the tax is actually felt. John Sweller's cognitive-load theory, introduced in 1988, distinguishes the intrinsic load of a problem, set by its inherent complexity, from the extraneous load imposed by how the work is presented. Working memory is severely capacity-limited, and when extraneous load consumes it, less capacity remains for the real problem. A hand-off is, in these terms, a machine for manufacturing extraneous load. The receiver must reconstruct context that the originator already held for free, and that reconstruction competes for the same scarce working memory the task itself demands.

Tom DeMarco and Timothy Lister, writing about the economics of knowledge work, name the state in which this scarce capacity is fully engaged as flow, and observe that it is both highly productive and expensive to re-enter after a break. An interruption does not cost only its own duration; it costs the ramp back to full context, which for genuinely hard work can dwarf the interruption itself. Coordination is, structurally, an interruption generator. Every question, review request, and synchronization is a small demand on someone else's attention, and in a team of n the number of possible such demands tracks the same quadratic that Brooks counted.

The ledger below separates the human costs by mechanism and by who pays them. It is framed as a synthesis of Sweller's load model and DeMarco and Lister's flow economics rather than a measured result, because the point is structural: these costs are real, they are borne unevenly, and they are invisible to a plan that counts only production work.

Evidence from delivery science and the AI trial

Two bodies of evidence let us connect the model to observed outcomes without inventing numbers. The first is the DORA program summarized by Nicole Forsgren, Jez Humble, and Gene Kim, which found that high delivery performance is associated with small batch sizes, short lead times, and loosely coupled teams that can make progress without broad synchronization. The mechanism is consistent with everything above: reducing the amount of work that must be coordinated at once reduces the serial fraction, which raises the achievable throughput. Delivery performance, in this reading, is in part the art of keeping the coordination tax small.

The second is the controlled trial reported by Sida Peng and colleagues in 2023, in which developers using an AI coding assistant completed a defined programming task markedly faster than a control group, with the study reporting on the order of a fifty-five percent reduction in completion time. The number itself matters less than what it does to the model. An assistant that compresses one person's production work shrinks the W that a team was formed to divide. If the work a person can now absorb alone has grown, the justification for splitting it across several people has correspondingly weakened.

Put the two together and the direction is clear. Delivery science says throughput improves when less work must be coordinated; the AI trial says an individual can now carry more work before coordination is needed at all. Both push the optimal team size for a bounded task downward, and both do so through the same variable that the next section makes explicit.

• Smaller batches lower the serial fraction that Amdahl's ceiling depends on.
• Loose coupling reduces the number of Brooks relationships that must be live at once.
• AI assistance shrinks per-person production work, weakening the case for division.
• All three effects move the crossover point toward fewer contributors.

A model of the coordination tax

The pieces now assemble into a single expression. Let W be the production work of a well-scoped task, measured in person-time, and let it divide across n contributors as W/n in the ideal case. Let each pair of contributors incur a coordination cost k per unit time, so the total coordination burden tracks Brooks's pair count, k times n(n-1)/2. The total time to complete is then the sum of a falling production term and a rising coordination term. This is a deliberate simplification, framed as my own synthesis, and its value is not precision but the crossover it exposes.

Minimizing the total with respect to n gives an interior optimum whenever coordination is not free. Treating n as continuous and setting the derivative to zero yields an optimal team size that grows only with the cube root of the ratio of production work to per-pair coordination cost. The cube root is the whole story in miniature: to justify doubling the team you need roughly eight times the divisible work, or an eightfold reduction in the cost of a relationship. Most well-scoped tasks offer neither, which is why the honest optimum is so often one or two contributors rather than a squad.

The pseudocode below turns the model into a decision procedure a lead can actually run before staffing a task. It estimates the divisible work, estimates the per-pair coordination cost from the team's real communication overhead, and returns the team size that minimizes total time. Its output is not a mandate but a prior: a number to argue against with specific, named reasons rather than with the reflex that more people are faster.

function optimal_team_size(W, k):
    # W  = divisible production work (person-hours)
    # k  = coordination cost per pair per unit time
    # Returns n* that minimizes T(n) = W/n + k * n(n-1)/2
    best_n, best_T = 1, W            # solo baseline
    for n in 1..12:
        production   = W / n
        coordination = k * n * (n - 1) / 2
        T = production + coordination
        if T < best_T:
            best_n, best_T = n, T
    return best_n, best_T            # argue against this, don't obey it

Threats to validity and where the tax buys something real

The model is a lens, not a law, and honesty requires naming where it bends. It assumes production work is cleanly divisible, which understates coordination for tightly coupled problems and so understates the case for keeping them whole. It treats the per-pair cost k as constant, when in practice it varies with tooling, shared context, and trust, and a team that has paid down its communication overhead pays a smaller tax than the arithmetic assumes. It says nothing about task duration or fatigue, and it deliberately excludes the value a second person adds beyond raw throughput. Each of these is a real limit on how far a single expression should be pushed.

That last exclusion is the important one, because the coordination tax is a cost, not a verdict. There are ends the tax purchases that a solo contributor cannot buy alone. Review catches errors that the author is blind to. Shared ownership lowers the risk that a single departure strands a system. Mentoring and knowledge distribution are, by design, coordination that trades present speed for future capability. For work that must outlive its author, or fail safely, or grow a team, paying the tax is not waste but insurance, and the right question is never whether to pay it but whether the specific task in front of you needs what it buys.

The discipline this article argues for is therefore modest. Before adding a person to a bounded, well-understood task, name the production work they will genuinely take off the critical path, name the relationships they will introduce, and name the specific benefit beyond throughput that justifies the difference. If the honest answer is that the task is small, clear, and owned, the model and the century of experience behind it agree: let one mind carry it, and spend the coordination budget where the work actually needs more than one.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

inputs:
    W = estimate(divisible_person_hours)
    k = estimate(cost_per_pair_per_hour)   # from real comms overhead

function total_time(n):
    return W / n + k * n * (n - 1) / 2

function recommend():
    candidates = [ (n, total_time(n)) for n in 1..12 ]
    n_star = argmin_by_time(candidates)
    return {
        recommended_team_size: n_star,
        solo_baseline: total_time(1),
        note: "treat as a prior; override only with a named, specific reason"
    }

Glossary

Coordination cost

Effort spent keeping separate contributors consistent that does not itself produce the artifact.

Communication path

A relationship between a pair of contributors that must be kept coherent; a team of n has n(n-1)/2 of them.

Serial fraction

The portion of a job that cannot be parallelized and therefore bounds the maximum achievable speedup.

Amdahl's ceiling

The limit one over the serial fraction on how much faster parallel resources can make a partly serial job.

Conway's law

The principle that a system's structure is constrained to mirror the communication structure of the organization that builds it.

Cognitive load

The demand a task places on limited working memory, split into intrinsic complexity and extraneous, presentation-driven load.

Flow

A fully engaged, high-productivity working state that is costly to re-enter after an interruption.

References

1. Brooks, F. P. The Mythical Man-Month: Essays on Software Engineering (Anniversary ed., 1995), ISBN 0-201-83595-9
2. Conway, M. E. How Do Committees Invent? Datamation, 14(4), 28-31 (1968)
3. Amdahl, G. M. Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities. AFIPS Conf. Proc. 30 (1967)
4. Sweller, J. Cognitive Load During Problem Solving: Effects on Learning. Cognitive Science 12(2), 257-285 (1988)
5. DeMarco, T. & Lister, T. Peopleware: Productive Projects and Teams (3rd ed., 2013), ISBN 0-321-93411-3
6. Forsgren, N., Humble, J. & Kim, G. Accelerate: The Science of Lean Software and DevOps (2018), ISBN 1-942788-33-1
7. Peng, S., Kalliamvakou, E., Cihon, P. & Demirer, M. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590 (2023)