TL;DR
A team's drafting tool made one task much faster, and the department's total output did not move. Tracing real cases showed that some of the time had moved into the work around the tool, such as approvals, corrections, and handoffs that no business case counted. No source shows how often this happens, so the paper offers a test: trace one workflow before counting automation savings.
What the paper develops
Automation can cut the effort a task takes and still leave the work around the task untouched. It can even add to that work. Someone still has to route the job, reconcile the numbers, approve the output, explain it, and fix what breaks. The claim here is narrow. When a business case counts only the time saved on the task, the saving it reports can be real while the department keeps less of it, because some of the time moves into the work around the task. This paper does not say that happens in every workflow, and its sources do not say how often it does. It offers a way to find out for one workflow.
One review I carried out makes the problem concrete. A team's drafting tool had made one task much faster, and the team was proud of it. The department's total output had not moved. Tracing real cases from request to delivery showed that some of the time had moved into work around the tool, including an approval step that existed only because the output was now machine-drafted. This paper calls that surrounding work the coordination tax: the work between the tasks, such as routing, waiting, approval, reconciliation, explanation, and repair. A task-level business case often has no line for it, because it is spread across many roles and owned by no one.
The evidence is partial. Researchers define coordination as managing the dependencies among activities, which names this work. A Danish survey of about 25,000 workers found that some chatbot users reported new tasks, such as checking the tool's output, and users reported saving about 3 percent of their work hours. That shows new work can follow adoption. It does not show that the new work cancels a saving in any one workflow. The economists' productivity J-curve and two software studies are analogies, and a 2026 preprint on avoidable coordination is a hypothesis. The paper's claim is a test, not a forecast.
The test is a review of one workflow, run before a decision to scale. Tracing work across a process is not new, since Lean value-stream mapping and process mining both do it. What this paper adds is using the trace to test an automation's business case. The six disciplines have an order. First, trace real cases, not the process diagram, and sort each handoff, wait, and approval along the way by what it produces: worth keeping, reducible, avoidable, or created by the change itself. Next, look in three places, in any order: the work around the tool, the handoffs that remain, and the cases the tool cannot handle. The fourth group, work created by the change, is filled in from what those three find. Last, measure the whole path against the traced baseline, because that is what shows whether the changes worked.
Run the first review on a workflow that already has an automation proposed or recently shipped: about a dozen traced cases as a starting sample, a few observation sessions, and one wall of mapped journeys. As a planning estimate, that is about two weeks of part-time effort. Price the added work at the seniority of the people who do it, and count freed capacity, the staff time the automation actually releases, only after the whole path confirms it. A flat path under a celebrated task measure is a reason to trace, not proof that coordination ate the savings, because demand, staffing, or the mix of cases may also have changed.
The white paper adds how to choose the workflow and what to do when cases cannot be traced, the four-bin sort with a worked example, the handoff contract (a short agreement on what is passed, how the next team accepts it, and who owns each side), the sibling paper The Exception Path Is the Real Automated Workflow for the cases the tool cannot handle, the objections, and the limits of the evidence.
What to do next
Before you count an automation's savings, pick one workflow and trace about a dozen recent cases from request to delivery as a starting sample. Sort every handoff, wait, and check by what it produces, price the added work at the seniority of the people who do it, and count the staff time actually freed only after the whole path confirms it.
Inside the white paper
- A six-part review that traces where an automated task's saved time may have gone, and the order to run it in
- How to sort each handoff and check into four bins, from worth keeping to created by the change
- How to choose the workflow, what the review costs, and how much the evidence shows
Sources and notes
- Thomas W. Malone and Kevin Crowston, "The Interdisciplinary Study of Coordination," ACM Computing Surveys 26, no. 1 (1994): 87–119 — Malone and Crowston's 1994 survey defines coordination as managing dependencies among activities and describes kinds of dependency, including shared resources and the link between a producer and a consumer. It is a survey of theory, not a measurement of automation.
- Anders Humlum and Emilie Vestergaard, "Still Waters, Rapid Currents: Early Labor Market Transformation Under Generative AI," NBER Working Paper 33777 (May 2025, revised March 2026; first circulated as "Large Language Models, Small Labor Market Effects") — A Danish study that links a late-2024 survey of about 25,000 workers in 11 occupations to administrative records. Users reported time savings of about 3 percent of work hours, and about 8 percent reported entirely new tasks created by chatbots. The answers are self-reported, cover chatbots, and the study finds no sizeable effect on earnings or recorded hours.
- Rob Cross, Reb Rebele, and Adam Grant, "Collaborative Overload," Harvard Business Review, January–February 2016 — Cross, Rebele, and Grant report from their own two decades of organizational data that time spent collaborating has grown by 50 percent or more and takes about 80 percent of people's time at many companies. It measures collaboration time in general, not the cost automation creates.
- Erik Brynjolfsson, Daniel Rock, and Chad Syverson, "The Productivity J-Curve: How Intangibles Complement General Purpose Technologies," NBER Working Paper 25148 (2018); published in American Economic Journal: Macroeconomics 13(1), 2021 — Brynjolfsson, Rock, and Syverson show that measured productivity can lag when firms invest in unmeasured complements to a general-purpose technology. The evidence is at the level of firms and economies, so the paper uses it as an analogy.
- D. Sculley, Gary Holt, Daniel Golovin, et al., "Hidden Technical Debt in Machine Learning Systems," Advances in Neural Information Processing Systems 28 (NeurIPS 2015) — Sculley and colleagues describe how machine-learning systems that are cheap to build become costly to maintain. It is an engineering analysis of one kind of software, used here as an analogy.
- Chintan Amrit, Jos van Hillegersberg, and Kuldeep Kumar, "Identifying Coordination Problems in Software Development: Finding Mismatches between Software and Project Team Structures," 2012 — Amrit and colleagues mined code and communication records in a corporate environment and found clashes between software structure and team structure in many projects. A software case study, used here as an analogy.
- Harang Ju, "When Coordination Is Avoidable: A Monotonicity Analysis of Organizational Tasks," 2026 preprint — A 2026 preprint that proposes a test for when coordination is required for correctness and applies it to 65 standard workflows and 13,417 job tasks using its own breakdowns. It is not peer reviewed, and the paper treats it as a hypothesis.