A decision can be ready long before the organisation is ready to make it. The analysis is complete, the relevant information exists, and the people involved know their jobs. Yet someone still has to find the owner, bring the information together, get the right approval, and make sure the decision reaches the team that will act on it.
Consider an illustrative supplier change. A procurement manager has compared the alternatives and recommends moving an order to another supplier. Finance needs the spending figures. Legal needs the contract terms and the earlier compliance review. Operations needs to know whether the change affects delivery. Each team holds part of the answer, and the procurement manager becomes responsible for connecting them.
The time spent making those connections is easy to overlook. It appears inside email threads, meetings, spreadsheets, and requests for updates. Coordination debt is the accumulated cost of repeatedly reconstructing context and moving work between people and systems. It becomes part of the normal working day, even when it consumes more effort than the decision itself.
The work between the systems
In the supplier example, the first difficulty might be identifying who can approve the change. The person who handled the previous request has moved roles. A colleague suggests another contact, who asks for a different version of the comparison. The manager prepares it and waits for a response. Nobody has made a bad decision; the request is still finding its route.
Once Finance receives the figures, another question appears. Does the quoted price include the same delivery terms as the current contract? The answer exists in the supplier correspondence, but it was omitted from the summary. The manager retrieves it, updates the comparison, and sends the revised document. Legal now needs to establish whether its review covers that revision.
These are small actions with real consequences. A missing assumption creates another round of questions. A revised document creates another version to check. A person who receives the request late needs the background explained again. The original analysis becomes surrounded by work needed to make it usable elsewhere.
The handoff is part of the process, even when nobody has designed it. If the normal route depends on someone remembering the right contact or explaining a spreadsheet, that person is carrying a responsibility the process has left informal. Their competence keeps the work moving, but the organisation depends on their availability and knowledge.
This is the meaning of human middleware: people acting as the connection between systems that cannot carry the work through together. Some translation requires judgment. Other translation simply repeats information in the format the next participant expects. Treating both as unavoidable administration makes it difficult to see which work could be removed.
Why the delay is difficult to measure
Each participant sees a different part of the supplier change. Procurement sees the effort of assembling the request. Finance sees a review that took a reasonable amount of time. Legal sees a question answered correctly. Operations sees a decision arriving later than expected. All those accounts can be accurate while leaving the overall delay unexplained.
A task dashboard may record when the review began and when it finished. The request might already have spent several days in an inbox before anyone opened the task. Another period of waiting may follow the approval, while the decision is passed to the team responsible for changing the order. Measuring only the formal review misses both intervals.
Following one request from beginning to end gives a more useful picture. The record needs to distinguish time spent doing necessary work from time spent waiting for an owner, missing information, or an earlier decision. It also needs to capture returns to a previous step. A request that moves backwards twice has a different problem from one that receives a single, careful review.
There is no reason to assume that all waiting is waste. A supplier check may depend on information that has not arrived. A reviewer may need time to assess an unfamiliar obligation. That work protects the business. The useful distinction is whether the delay has a clear purpose and owner, or whether the request has simply become hard to locate.
The same care applies to the title's claim about competitive cost. This article offers a way to examine that cost, rather than a measured result across enterprises. In a particular business, a delayed decision may affect delivery, customer commitments, or the ability to respond to a supplier. The size of that effect needs evidence from the business itself.
Why better tools can leave the same problem
A purchasing system can hold accurate order information while a contract system holds the terms and a finance system holds the spending history. Each system can serve its users well. Someone still needs to connect those records to the supplier change and explain which details matter for this decision.
Adding a new tool can improve that work. Search may make the earlier review easier to find. A shared document may reduce conflicting attachments. An assistant may prepare the comparison more quickly. The benefit should be measured where it occurs, without assuming it extends to every later step.
Suppose the comparison now takes half as long to prepare. If the next review still begins only when someone notices an email, the request can spend the same time waiting. Procurement has saved effort, but delivery may receive the decision on the same day as before. A local improvement and an unchanged overall result can exist together.
Integrating the systems also needs a purpose beyond moving information. Copying the supplier record into another application helps only if the recipient knows what action is required, which version applies, and who will handle the result. A connection that transfers data without those responsibilities can leave people doing the coordination around it.
The design question is how a completed task becomes usable work for the next participant. That includes the information they receive, the decision they are being asked to make, and what happens after they respond. Software contributes when it supports that whole relationship. Its presence alone does not establish it.
Necessary review needs better preparation
Removing coordination debt requires care around the work that should remain human. The procurement manager may recommend the supplier, while Finance owns the spending decision and Legal owns its assessment of the terms. Those responsibilities matter even if a system can assemble the request without help.
A useful improvement gives each reviewer the evidence needed for their decision and identifies the decision precisely. Finance should be able to see the relevant cost assumptions. Legal should know which terms have changed and which earlier review is being relied upon. Operations should be asked about the delivery consequence it actually owns.
This preparation can reduce repeated explanation while preserving disagreement. If Operations identifies a delivery risk, that finding needs to return to the recommendation and affect the next action. A process that collects approvals but loses the conditions attached to them has moved information without preserving the decision.
The same applies when authority is unclear. Faster routing will not settle a disagreement about who can approve the change. Someone responsible for the business must resolve that question. The process can then make the answer available the next time, rather than requiring another employee to negotiate it from memory.
Better coordination therefore makes human judgment easier to apply at the right point. It can reduce status chasing and repeated assembly while leaving a consequential decision with its owner. The value comes from preparing and carrying that decision reliably, including its conditions and any unresolved questions.
Start with one decision that repeatedly gets stuck
An organisation can investigate coordination debt without beginning with a company-wide redesign. Choose a recurring decision whose route crosses teams, then follow a real instance with the people who handled it. The supplier change is one possible example; a pricing exception or customer commitment could serve equally well.
Record what started the request and what would count as a completed outcome. Then establish who received it, what information they needed, and what they returned. Where the request waited, identify what was missing. This creates a shared account of the process instead of asking each department to defend its own response time.
That account can reveal a small, practical intervention. Perhaps the initial request needs the delivery terms attached. Perhaps the owner needs to be explicit before submission. Perhaps approval needs to include the conditions under which the order may change. Each improvement should address something observed in the decision path.
The result also needs to be checked beyond the improved step. A faster Finance review is useful, but the organisation should establish whether the order changed sooner, whether necessary checks remained in place, and whether downstream teams received a usable decision. Otherwise, work can simply move to a less visible queue.
The people doing this work should help assess the proposed change. They often know which detail a request routinely leaves out and which shortcut causes trouble later. A map drawn only from the formal procedure can miss those realities. Comparing the written route with an actual decision helps establish whether the improvement removes unnecessary work or merely leaves it for someone else to absorb.
Coordination debt becomes manageable when the organisation can explain where work waits and who owns the next action. The next investment can then address a specific gap. An AI assistant may help with some of that work; the next post, Why AI assistants don't solve the coordination problem, examines what faster individual output changes, and what still needs a shared process.
Related reading
- Next in the series: Why AI assistants don't solve the coordination problem — examines what changes when individual tasks become faster, while handoffs remain.
Documentation
- Agentic Enterprise Manifesto Outline: the coordination problem and the responsibilities people retain in a different operating model.
- Technical Platform Thesis: the design requirements for connected work, shared context, approvals, and a traceable result.
Synedrix OS — coordination debt
