A procurement manager at a mid-sized manufacturer decided to switch a secondary supplier. The analysis took about twenty minutes. The data was clear, the alternative was better on every metric that mattered, and the cost case was straightforward. The approval took eleven days!
She spent three of those days locating the right people to sign off. Two days reformatting data from the supplier system into a structure the finance team could review. One day waiting on legal, who asked the same compliance questions already answered on a different supplier two months earlier. The remaining days were scheduling: aligning four decision-makers across two time zones for a review meeting that ran forty minutes and approved the change unanimously.
The software worked correctly throughout. Every piece of information needed for this decision existed in a system. The CRM had the contract data. The ERP had the spend figures. The compliance database had the prior approval on record. None of the tools failed.
They just didn't connect to each other, and nobody had designed them to. So a person did. Several people, in fact, doing the same context translation at each handoff point. Of those eleven days, almost none was lost to technology failure. The failure was coordination.
This pattern has a name: coordination debt, the accumulated cost of using humans as the translation layer between systems. Status chasing, context reconstruction, reformatting, routing, re-answering questions already on record somewhere. Each instance looks manageable. Across an organisation, it compounds.
The operating model predates the problem
Modern enterprises are still running on a coordination model inherited from a slower information age. Companies were designed for physical proximity, layered sign-off chains, and departmental structures where information moved in weekly batches. That design worked when the information environment matched it.
The information environment changed. The operating model largely did not.
The result is a coordination stack that most organisations don't examine because they're too close to it: meetings to align on context that should already be shared; inboxes as routing queues for decisions that could have clear owners; approval chains that duplicate questions already answered elsewhere; spreadsheets as the flexible connective tissue between systems that don't integrate. Each layer exists to translate information from one context to the next.
Then software was added. CRM, ERP, data warehouse, AI assistant. Each new tool raised capability within its domain. Each one also created at least one new handoff point between the people using it and the people receiving its outputs. The coordination stack didn't shrink, it had more things to sit on top of it.
Coordination debt is hard to see from inside it
The eleven-day supplier switch doesn't appear on any dashboard as a coordination problem. It shows up as an eleven-day lead time, or as a process note in a quarterly operations review, or as a lesson learned in a post-mortem about cross-functional dependencies.
What makes coordination debt hard to see is that its costs are distributed. The procurement manager, the finance reviewer, the legal contact, and the four people in the final meeting each experienced a fraction of the total friction. Individually, each looks like a normal workday. The systemic cost only becomes visible at the level of the whole โ measured in decision latency, missed signals, duplicated context reconstruction, and errors that occur specifically at handoff points rather than inside any single system.
This is not a failure of individual productivity. Each person in that eleven-day chain was doing their job competently. The CRM, the ERP, and the compliance database were functioning as designed. The failure is structural: it lives in the gaps between systems, and those gaps were built in by a coordination model that assumes humans will fill them.
More software, same architecture
Enterprises have spent the last decade adding software to this structure. Most of it worked. Process automation reduced manual work within defined boundaries. Analytics tools surfaced patterns that were previously invisible. AI assistants have made people faster at their individual tasks.
None of it changed the coordination topology.
Local efficiency tools reduce friction at a single node. They don't redesign the handoffs between nodes. An individual contributor who completes their work twice as fast still passes an output to a team that processes handoffs on a weekly schedule. The bottleneck shifts. It stays in the system.
The more uncomfortable version of this argument applies directly to AI: adding AI assistants to the same human-middleware architecture doesn't change the architecture. It makes the same coordination model faster at certain nodes, while leaving the gaps intact. If six people need to translate information between systems before a decision can be made, tools that help each of those people individually do not reduce the number of translations required. They may reduce the time each translation takes. The structural gap remains.
What the problem actually is
Coordination debt doesn't accumulate because employees lack skill or because the wrong software was chosen. It accumulates because the dominant coordination model requires human middleware at every boundary between systems, and every new system adds new boundaries. The debt compounds as organisations grow more complex, more distributed, and more dependent on real-time information for decisions that used to move slowly enough to allow for human translation.
The path out of it isn't another tool layered onto the same structure. It requires a different model for how coordination works, one where the translation between systems doesn't depend on human middleware by default.
That shift is harder to see than a new product feature. It doesn't show up in a demo. But it's the difference between software that makes the current operating model marginally faster and a different operating model entirely.
