“I sent it.”
Three words that can explain an extraordinary amount of organizational dysfunction, especially when everyone involved can prove they completed their part. The request was emailed, the report was shared, the issue was escalated, and the customer’s requirements were forwarded to someone who presumably knew what to do with them. There is a record of activity everywhere you look, yet the customer is still waiting.
What bothers me is how easily sending something becomes the point where responsibility ends. For the work to progress, someone else has to understand what arrived, have everything needed to use it, and possess the time and authority to act. We can complete our own task while leaving the next person completely unable to begin theirs.
Once you start looking at work this way, the issue becomes much broader than communication. It includes how we schedule production, release orders, allocate resources, approve decisions, connect systems, and measure performance. The handoff is where all those choices meet, sometimes rather awkwardly.
Where the work gets stuck
Imagine an order that requires six hours of actual work but takes twelve days to deliver. Engineering finishes the drawing, purchasing waits for authorization, and materials arrive separately. The job misses its production slot and eventually reaches inspection, where a missing document sends someone searching through an email chain that apparently contains the entire history of the company.
If we only measure the activities themselves, we could miss most of what the customer is experiencing.
This is why I find value-stream mapping useful. The Lean Enterprise Institute describes it as examining the material and information flows across the whole process, including activities that create no customer value. Separating processing time from total lead time changes where we look for improvement, because it makes the waiting between activities visible.
Consider how differently a completed task can look from the receiving side:
Production released the order, but the next operation lacks the tooling, materials, or available capacity to start it.
Engineering approved the design, but manufacturing still needs clarification before it can build the product reliably.
Maintenance identified the problem, but nobody has aligned the spare part, technician, permit, and shutdown window.
Sales captured the requirement, but it never became part of the specification used to configure the solution.
These situations make me question what we mean by “done.” If the next person must find missing information, negotiate priorities, or reconstruct the intended outcome, we have transferred unfinished work along with the responsibility.
Another lesson from research is that releasing more work can make the situation worse. John Little’s foundational queueing research established the relationship between average work in a system, throughput, and average time in the system. For example, a stable process averaging 100 open jobs and completing 20 daily has an average elapsed time of five days. Adding jobs does not automatically create the capacity to finish them. I think this is easy to overlook because starting work feels productive. A project gets launched, a machine stays busy, and somebody’s backlog moves into somebody else’s department. We can celebrate all three while the overall waiting time continues to grow.
Wallace Hopp and Mark Spearman’s research on pull production explains why limiting work in progress matters once a process becomes saturated. Their paper describes an application at Moog where streamlining assembly flow and introducing a system that capped work in progress helped reduce lead time from 23 days to six. That single application illustrates the potential of improving how work moves through a system.
What I find particularly interesting is that a department can contribute to the delay while doing exactly what its performance targets encourage. Imagine purchasing rewarded for bulk discounts while production needs smaller deliveries, or engineering measured on designs released while manufacturing absorbs unresolved problems. Each team has a reasonable explanation for its behavior, which is precisely why asking everyone to “collaborate better” may accomplish very little. Someone has to reconcile the conflicting objectives.
There is experimental evidence that operating practices make a difference. In a randomized study of Indian textile plants, Nicholas Bloom and colleagues found that introducing management practices increased productivity by 17% in the first year, through improved quality and efficiency and reduced inventory. It was a broad intervention, but it reinforces my view that substantial opportunity can exist in how we organize resources we already have.
Ownership matters just as much. Gerardo Okhuysen and Beth Bechky’s review of organizational coordination identified accountability, predictability, and common understanding as conditions that coordination mechanisms help create. My practical interpretation is that a handoff needs an accountable next owner, a shared understanding of readiness, and a reasonably predictable sequence of actions. Putting everyone on the same dashboard does not automatically establish any of those things.
This is also why I think carefully about where AI enters a process. In Shakked Noy and Whitney Zhang’s experiment involving 453 professionals, ChatGPT access reduced average completion time on writing tasks by 40% and improved assessed quality by 18%. Those are substantial improvements within the tasks studied. But a quotation drafted in seconds can still wait three days for approval. My concern is that accelerating an upstream activity without addressing downstream constraints may simply produce unfinished work faster, leaving us with more impressive technology and a larger queue.
Five practical ways to reduce the gaps
I would begin with one process that matters to customers, then work through five changes before expanding the effort across the organization.
Measure what happens between activities. Follow ten recent orders, service requests, or engineering changes from beginning to end. Record when each step finished, when the next began, and why work stopped. Separate processing, waiting, transport, and rework so you can address the largest avoidable delay instead of the most visible complaint.
Define readiness with the receiving team. Agree on what must be available before work can proceed, including materials, usable information, tools, permissions, and system access. Make acceptance criteria explicit, and investigate recurring reasons for rejection. A handoff should give the next person a workable starting point without requiring a scavenger hunt.
Give someone authority across the process. Establish who can resolve conflicting priorities, secure resources, and challenge unnecessary approval layers. Define what happens when work stalls and how unresolved issues escalate. Assigning ownership without decision rights risks creating a highly informed spectator who spends the week documenting problems they cannot fix.
Control how much work enters the system. Match releases to constrained capacity and reconsider batch sizes, scheduling rules, and avoidable interruptions. Preserve appropriate protection against variability: Hopp and Spearman explain that removing inventory buffers without considering capacity or time can worsen delivery. The aim is reliable flow with a deliberate balance of resources.
Reward outcomes that cross departmental boundaries. Track total lead time, delivery reliability, throughput, and rework alongside local productivity. When introducing automation, verify that the customer’s wait decreases and that a queue has not simply moved elsewhere. Recognize teams for making the next step successful, even when doing so changes their own routines.
Two conveyor belts can each operate efficiently while the transfer between them remains unreliable. The organizational equivalent deserves deliberate design too, including timing, capacity, acceptance criteria, and responsibility when something goes wrong. That is the standard I would bring back to “I sent it.” The responsibility extends to making the next step possible, because the customer experiences the entire process, including every gap we have learned to work around.
References:
Bloom, N., Eifert, B., Mahajan, A., McKenzie, D., & Roberts, J. (2013). Does management matter? Evidence from India. The Quarterly Journal of Economics, 128(1), 1–51. https://doi.org/10.1093/qje/qjs044
Hopp, W. J., & Spearman, M. L. (2004). To pull or not to pull: What is the question? Manufacturing & Service Operations Management, 6(2), 133–148. https://doi.org/10.1287/msom.1030.0028
Lean Leaper. (2022, August 25). Understanding the fundamentals of value-stream mapping. Lean Enterprise Institute. https://www.lean.org/the-lean-post/articles/understanding-the-fundamentals-of-value-stream-mapping/
Little, J. D. C. (1961). A proof for the queuing formula: L = λW. Operations Research, 9(3), 383–387. https://doi.org/10.1287/opre.9.3.383
Noy, S., & Zhang, W. (2023). Experimental evidence on the productivity effects of generative artificial intelligence. Science, 381(6654), 187–192. https://doi.org/10.1126/science.adh2586
Okhuysen, G. A., & Bechky, B. A. (2009). Coordination in organizations: An integrative perspective. Academy of Management Annals, 3(1), 463–502. https://doi.org/10.5465/19416520903047533
