Tooling lowers the cost of coordination but cannot remove the task's own dependencies

What it is

Collaboration tooling lowers the marginal cost of executing coordination actions — aligning on progress, transferring information, confirming status becomes faster, cheaper, and less error-prone — but it cannot remove the dependencies the task itself demands. If a piece of work structurally requires sequencing, shared resources, or handoffs between people, those dependencies survive whatever tool you adopt; the tool changes how much effort satisfying them takes, not whether they exist. This boundary is routinely misread as "the tool isn't good enough, collaboration still feels exhausting," when in fact part of the coordination cost is an intrinsic property of the task.

Why it happens

Coordination cost roughly splits into two parts. One is the operational friction of performing coordination itself — figuring out whom to ask, shuttling files back and forth, manually reconciling whether two views of the state agree. This part is compressible, and good tooling can cut it dramatically. The other is the waiting and alignment time that task dependencies demand — the next step cannot start until the previous step's output exists. This part is incompressible, because it is set by the structure of the task, not by the efficiency of information transfer. Tools act on the former. Mistaking tooling gains for improvement in overall coordination cost therefore overestimates what tools can do about the task's structural constraints, and leads to overly optimistic schedule predictions.

Where it stops holding

In some cases tools genuinely change the dependency structure itself rather than just reducing friction — for example, turning a sequential review into parallel asynchronous commenting by multiple people removes a sequential dependency at the structural level. That kind of change is process redesign, not tool acceleration, and telling the two apart requires checking whether who-must-wait-for-whom actually changed, not whether the number of steps got smaller. When the dependency cannot be redesigned — the foundation must be poured before the walls go up — the space tools can compress is very small, and expecting tooling to fix the schedule is a misdiagnosis.

Applying it

• Before introducing a collaboration tool, split current coordination cost into "operational friction" and "structural waiting," and set improvement expectations only for the former.
• If delays come mainly from structural waiting, evaluate redesigning the process itself — decomposing tasks, reordering, allowing partial parallelism — instead of shopping for a faster tool.
• When procuring or building tooling, validate it against concrete friction scenarios, such as "how many steps to confirm one status change," rather than a vague "does collaboration feel smoother."
• If overall cycle time fails to shorten after rollout, check whether the bottleneck sits in structural waiting before blaming tool selection and churning through replacements.

Related

• Same group: V1.06.1 Net benefit of collaboration equals division-of-labor gain minus coordination cost · V1.06.2 Coordination cost grows faster than output as headcount rises · V1.06.3 Task decomposability sets the floor on coordination cost · V1.06.4 Brooks's law
• Nearby: V1.02 Granularity of Collaboration · V6.04 Approvals and Review
• Search terms: coordination cost floor · process redesign · tool versus structure