Operating layer
The coordination tax
The larger part of what coordination costs a company is elapsed time rather than working hours, and its causes are properties of how work moves rather than gaps in software.
Companies spent thirty years digitising their functions and almost none of that effort on the work between them. Finance has a system. Sales has a system. Procurement, support, HR and operations each have one. What sits between those systems is a large amount of human work that has no system at all, and no line in any budget.
That work is real, it is expensive, and it is almost entirely absent from the process maps a company draws of itself. This piece names it, gives you a way to measure it inside your own organisation, and explains why buying another application tends not to reduce it.
The work between the systems was never mapped
Open the documented version of any process that crosses functions. It will describe the steps, the owners and the order. It will not describe the messages, the meetings, the spreadsheet somebody keeps privately and the status checks that actually moved the work from one step to the next.
That omission is structural rather than careless. Process maps record the transformation of an object. Coordination is what happens to the object between transformations, and it is performed in email, chat, meetings, spreadsheets, notes fields and people’s memory. None of those leave a record in the shape a process map reads. What cannot be seen is not mapped, what is not mapped is not measured, and what is not measured is never the thing anybody sets out to fix.
The result is that a company can automate every step of a process and find the process barely faster.
Three kinds of coordination work
The following is our framework rather than an established one. It is useful because the three kinds have different causes and different remedies, which a flat list of activities hides.
Information
Finding out what the current state is. Locating the document, the number, the last message, the version that is actually current. Moving context from one system into another and translating it on the way, because the two describe the same thing differently.
Alignment
Establishing what should happen and who decides. Asking a question and waiting for the answer. Clarifying who owns a decision. Explaining context to somebody who needs it before they can act. Obtaining an approval.
Control
Making sure the agreed thing happened. Checking status, reminding, following up, reconciling two systems that disagree, catching the exception and escalating it.
Every organisation of any size runs all three continuously, and in most of them all three are performed by people rather than by anything else.
Effort is the smaller number
Coordination costs a company in two currencies and only one of them is visible.
The visible one is effort, meaning the hours people spend, and there is credible evidence that the volume is substantial. Mark, Gonzalez and Harris shadowed 24 information workers through more than 700 formal hours of observation, timing activity to the second. A person spent an average of 11 minutes 4 seconds in a working sphere before switching to another or being interrupted, and 57.1 percent of working sphere segments were interrupted. Where the work was resumed the same day, it took an average of 25 minutes 26 seconds to come back to it, with 2.26 other working spheres visited in between. That study is from 2005, before most of the tools now blamed for fragmentation existed, which makes it a conservative reading rather than an alarmist one.
Cross, Rebele and Grant reported in Harvard Business Review that time spent in collaborative activities has ballooned by 50 percent or more over two decades, and that at many companies people now spend about 80 percent of their time in meetings or answering colleagues. That rests on the authors’ own data collection across more than 300 organisations and the method is not published alongside it, so it indicates a direction rather than measuring a quantity.
The second currency is latency, meaning elapsed time. It is invisible in any calculation based on salaries, and it is usually the larger number.
Process mining gives it a name. Cycle time efficiency is the ratio of processing time to total cycle time: the share of a process’s elapsed duration in which somebody or something was actually working on it. Lashkevich and colleagues analysed a real manufacturing production process of 225 cases, 24 activities, 4,503 activity instances and 46 resources. Its cycle time efficiency was 6.81 percent. For every hour of work performed in that process, close to fifteen hours of elapsed time went by.
One process in one company is not a benchmark and should not be quoted as one. What matters more is the decomposition. The waiting time broke down into resource unavailability at 57 percent, batching at 22 percent, prioritisation at 9 percent, extraneous factors at 8 percent, meaning causes sitting outside the process itself, and resource contention at 4 percent.
Read that list again with a purchasing decision in mind. Not one of those five causes is a missing application. They are all properties of how work is scheduled, queued, handed over and prioritised. A company facing that profile and buying another tool has bought a sixth system whose state now also has to be coordinated.
The steps were never where the time was.
Estimating it in your own company
This is an estimate rather than an accounting figure, and it is worth doing because the order of magnitude is usually the surprise rather than the decimal.
Choose one process that crosses at least three functions and runs often enough to have history. Order to delivery, hiring a person, approving and issuing a purchase, resolving an escalated case.
Take twenty recent instances. For each, read two clocks off the systems that already log them: the elapsed time from the first event to the last, and the sum of the intervals in which somebody was demonstrably working on it. Divide the second by the first. That ratio is cycle time efficiency, the same measure used in the research above.
Then classify the gaps. For each significant wait, decide whether the work was stalled because information had to be found or moved, because a question or an approval was outstanding, or because somebody had to check, chase or correct something. Information, alignment, control.
The honest limitations. System timestamps record events rather than attention, so working time is approximate unless you instrument it properly. Twenty cases is an indication and not a distribution. A process chosen because it feels slow is not a random sample. And the ratio says nothing about whether the waiting was avoidable, only about how much of it there was.
Even with all of that, most organisations doing this for the first time find a number well below what anybody would have guessed, and find that the largest single gap sits at a handover rather than inside a step.
What this evidence does not show
The strongest objection is that the evidence base here is thinner than the argument wants it to be.
That is fair and worth stating plainly. The cycle time efficiency figure comes from one real process in one manufacturing company, and manufacturing is not representative of knowledge work. The fragmentation study is twenty years old and observed 24 people. The collaboration figure comes from authors who did not publish their method. None of these establishes that coordination overhead has a particular size in your company, and anyone presenting them as if they did is overselling.
What they do establish is narrower and still useful. Cycle time efficiency is measurable, it has been measured at levels far below intuition, and its causes can be decomposed into categories that are not about software. That is enough to justify measuring your own, which is the only number that should change a decision.
What becomes possible
A company that measures this usually reaches the same conclusion, which is that no part of the organisation is responsible for the state between its functions.
Every system knows its own half. Somebody, always a person, still has to work out what happened, what it means, who needs to know, what should happen next, whether it happened, and whether it produced the result it was supposed to. Those six questions are the coordination tax stated as work. They are asked and answered thousands of times a week in every company of any size, and they are asked by people because no system holds enough of the company to answer them.
That is the gap an operating layer occupies. Not another application beside the others, which would add a seventh set of state to reconcile, but a layer that holds the company’s state across all of them and can answer those six questions continuously. Whether it should then act on the answers is a separate argument. The first claim is smaller and harder to dispute: the questions are being asked either way, the answering is done by people, slowly, and nobody is counting the cost.
Sources
- No Task Left Behind? Examining the Nature of Fragmented Work Gloria Mark, Victor M. González, Justin HarrisProceedings of the SIGCHI Conference on Human Factors in Computing Systems, 2005
- Why Am I Waiting? Data Driven Analysis of Waiting Times in Business Processes Katsiaryna Lashkevich, Fredrik Milani, David Chapela-Campa, Ihar Suvorau, Marlon DumasAdvanced Information Systems Engineering, CAiSE 2023, Springer, 2023
- Collaborative Overload Rob Cross, Reb Rebele, Adam GrantHarvard Business Review, January 2016
The product behind it
The layer this piece argues for: what it holds, how it is read from the systems you already run, and where the bounds sit.