The Tasks Were Marked Done. Why Was the Outcome Still Stuck?
When the work looks complete but the shared result won’t move, don’t assume the fix is better communication. Don’t assume it’s a reorg either. Follow the work to where it changed hands, and look there first.
What if the biggest obstacle to collaboration isn’t the people, but what we’re overlooking between them?
My new book, Collaborate Better, explores how we can break through organizational silos, solve problems together, and turn individual contributions into shared success.
Your road to better collaboration starts here. Get your copy today at
Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.
The kickoff call starts on time.
The customer signed three weeks ago. Sales logged the deal. Product locked the scope. Engineering shipped the configuration. Marketing sent the welcome sequence. Customer Success staffed the account and booked this call.
Then the onboarding lead asks a friendly opening question. “So, what are you hoping to achieve with us?”
There’s a pause on the line. The customer answered that exact question during the sales cycle. More than once. They answer it again, a little slower this time.
Pull up the tracker and every box is green. Sales: done. Product: done. Engineering: done. Marketing: done. Customer Success: done. The thing everyone actually wanted, a customer getting value from what they bought, is still waiting.
A note on that scene before we go further. It’s an illustrative scenario, built from a kind of moment that people who work between Sales and Customer Success will recognize. It is not one company’s case file, and I’m not presenting it as one.
Now, the honest part. Maybe the account executive skipped the notes. Maybe Customer Success was short-staffed that month. Maybe the customer’s goals changed after signing. Any of those could be the answer.
Before you pick one, notice what the green checkmarks can’t tell you. Task status is not outcome status. The tracker doesn’t show what needed to cross the boundary between teams, or whether it arrived. And it doesn’t show what else could explain the stall.
That’s where this series starts. Not with blame. With the work.
Follow the work before assigning the blame.
Over the next eight Wednesdays, The Collaboration Trap chases one question: what is making capable people struggle to do good work together? Each week takes one piece of the answer and hands you one tool you can use without permission to redesign the company. This week’s piece is the gap between finished and delivered.
Marked done isn’t the same as delivered
The first trap hides in plain sight, inside the tool everyone trusts.
A completion record answers one question: did this task close? It says nothing about a second question: did the shared result arrive? We read one record and quietly assume it answers both.
Look at the two finish lines. The left one reads Task complete. The right one reads Outcome not yet verified. Same project, same week, two different states. Notice the right one isn’t labeled failed. It’s labeled not yet verified. A status report shows you only the left one.
Three things follow from that.
A closed task is a status record. It tells you someone moved a card. It doesn’t tell you the next person can use what’s on it.
Quality still needs evidence. “Done” means the assigned work was marked complete. It doesn’t mean the work was wrong. It also doesn’t prove the work was enough.
Delivery needs its own check. The customer, the launch, the shared result: somebody has to look at that directly, not infer it from a column of green.
None of this accuses anyone of sloppy work. No one has to be dishonest or incompetent for two records to tell different parts of the story. Even if every person in our scene did exactly what was asked, the tracker alone couldn’t tell us the result arrived. Doing what was asked and delivering what was needed are two separate claims, and they need two separate checks.
Here’s a receipt on my own homework. Before writing this, I went looking for a study showing teams hitting their measured targets while the shared outcome stalled. I wanted a stated target, proof the target was met, and a measured result that still fell short. I didn’t find one that cleared all three bars. So I’m not going to tell you it’s proven. I’m telling you the distinction is real, and checking both sides costs you very little.
Check the task. Then check the result.
What needs to cross the boundary?
If the task closed and the result didn’t arrive, the next place to look is the seam where the work changed hands.
When work crosses a team boundary, the task can move without the context the receiver needs.
The sending team’s desk is covered in notes the receiving team never sees. Three of them matter more than the rest:
What was decided? The commitments, trade-offs and promises made before the handoff.
What dependencies remain? The things still owed by someone else before this work can finish.
Who can clarify or escalate? The person to call when the receiver hits a question the ticket doesn’t answer.
Those three questions are my illustration, not a validated checklist. I’m being careful about that because the strongest evidence on handoffs comes from somewhere very different from your office.
In a multicenter study across nine pediatric residency programs, Starmer and colleagues introduced a structured handoff program called I-PASS. It combined a standard handoff format with training, faculty coaching and observation. After implementation, the programs saw fewer medical errors and fewer preventable adverse events, and handoffs didn’t take longer.
That’s real evidence, and it comes with real limits. It’s clinical. It tested a whole bundle, so nobody can say which part did the work. The study wasn’t randomized. It does not tell you what a better handoff is worth in a software launch or a customer onboarding. Corporate effects are not established.
What transfers is the idea, not the effect size. A handoff is a transfer, and a transfer can lose the very thing the receiver needs most.
So here’s a small check you can run this week. Ask the receiving person what they got, in their own words, before you call the handoff done. It’s a check, not a cure. It does tell you what arrived.
Check what arrived, not just what was sent.
When a decision stalls, check who has authority
Sometimes nothing gets lost in transit. The work arrives intact, the context is all there, and it still sits. The next move is a decision, and nobody in the meeting can make it.
You know this meeting. Eight smart people, a real problem, a lively discussion. Everyone contributes. Everyone leaves agreeing it matters. Next week the same item is back on the agenda.
Participation isn’t the same as authority.
The graphic splits the people around a pending decision into three illustrative roles. Some contribute ideas and information. Some review, because a legitimate control requires it. Someone decides. When the decision stalls, the useful question is where it’s stuck between those three.
Ask three things before you change anything:
Who can make the decision? Not who cares most. Who is actually authorized.
Which reviews are required? Some are there for good reasons: security, legal, safety, money. Know which ones before you call them delays.
What is the authorized escalation route? When the decider is unclear or unavailable, there’s a sanctioned path upward. Find it and use it.
And keep the fourth question on the graphic in view: what else could explain the wait? The decision may be correctly reserved for someone senior. The data it needs may not exist yet. The decider may simply be out of capacity this month.
On evidence: Tubre and Collins pooled years of research on role ambiguity and job performance in a meta-analysis published in the Journal of Management. What they report is an association. It doesn’t show that unclear decision rights cause delays, and it doesn’t prove that naming one owner fixes them. Decision-delay effects are not established.
So don’t start by redrawing the process. Start by tracing the route the decision is supposed to take.
Check the decision route before changing the process.
From the book. In Chapter Six of Collaborate Better, I call one version of this stall the right conversation with the wrong people: a thoughtful discussion about improving how the work flows, where “the person with authority to approve changes never shows up.” The chapter is built on my consulting motto: the right people, the right conversation, the right time. A pending decision needs all three in the same place.
Structure isn’t automatically the villain
By now you might want to blame the org chart. Departments, approval gates, review boards: tear them down and the work will flow.
I’d hold off on that. Not every boundary is a problem.
The pillar in the middle of the graphic is one boundary. Read it from the left and you see what it may protect:
Expertise. Specialist teams give people room to go deep.
Independent review. A second set of eyes only works when it’s actually independent.
Risk controls. Security, compliance and safety checks guard against specific, known risks.
Read the same pillar from the right and you see what to examine: waiting, information loss and handoff gaps. Same boundary. Different questions. The goal isn’t to choose a side. It’s to ask both sets of questions before you touch anything.
Here’s why I’m wary of simple fixes. In Ontario, Canada, 101 hospitals introduced surgical safety checklists. Urbach and colleagues compared outcomes before and after. They found no statistically significant reduction in operative mortality or complications.
That doesn’t prove checklists are ineffective. It’s also a clinical finding, not a test of organizational hierarchy. I include it for one reason. Adopting a tool and making the work better are two different events. A boundary, a checklist or an approval step can look identical on paper and behave very differently in practice.
So before you remove anything, ask what it guards. Then look at the interface around it. Sometimes the control is fine and the handoff into it is the part that’s broken.
Check what a boundary protects before changing it. Then check whether the interface around it is working.
Operational effects are documented. The dollars are not.
You’ve seen the articles that put a price tag on bad collaboration. Billions lost. Hours wasted per employee per week. I went looking for a figure I could defend in front of a skeptical executive.
The evidence review behind this article didn’t find one that matched these claims. Unknown is not zero.
I ran five of this article’s claims through a financial review: handoff gaps, unclear authority, the role of structure and controls, operational consequences, and the coordination fixes. The left side of the graphic shows what the evidence does document, mostly in clinical settings: information loss, errors and quality outcomes, and safety and reliability outcomes.
The right side shows what it doesn’t. For all five claims, the financial stakes came back unknown. Not low. Not trivial. Unmeasured. The studies counted errors and adverse events. They didn’t cost them in a way that transfers to your business. Unknown cuts both ways: it doesn’t mean the cost is zero, and it doesn’t mean a loss must exist.
That matters if you’re the one walking into an executive review to argue for a change. A borrowed dollar figure is the easiest number in your deck to knock down. Your own operational evidence is much harder to argue with.
Before you put a number on a slide, ask the three questions at the bottom of the graphic:
What was observed? The waits, the repeat questions, the rework you can actually point to.
What was actually costed? Money someone measured, or a model whose observations and assumptions are out on the table. A figure borrowed by analogy doesn’t count.
What remains unmeasured? Say so out loud. It makes everything else you say more credible.
Document the operational effect. Verify the financial claim.
Some remedies have evidence. Others are not yet established.
The same discipline applies to fixes. Every framework, consultant and conference talk has a remedy for cross-team friction. Some of those remedies have been tested. Others haven’t been tested in settings like yours.
A plausible fix isn’t a proven fix.
I sorted ten categories of remedy by how much evidence shows they actually work in the settings where they were studied.
Moderate (3): structured handoff bundles, structured debriefing, and team-training bundles. Most of that evidence comes from healthcare and other high-reliability work.
Weak (3): closed-loop confirmation, records and traceability, and boundary-preserving coordination.
None established (4): readiness criteria, decision-rights interventions, synchronized dependency planning, and shared objectives or scorecards.
That last row stings a little for me. I’m an SPC- and RTE-certified enterprise agile coach. I teach and coach versions of some of those practices. I’m still putting them in the “none established” row, because that’s where the evidence I found puts them.
Read the label carefully, though. None means not established, not ineffective. The evidence I reviewed doesn’t show these remedies working for teams like yours. It doesn’t show them failing either. And across all ten categories, the direct effectiveness evidence for U.S. product, project and program work is weak.
That isn’t a reason to stop trying things. It’s a reason to try them like experiments, watch what happens, and stay honest about what you know. When someone pitches you a fix, including me, ask three questions.
Ask what was tested, where, and with what result.
Before you blame the people or blow up the org chart
So where does that leave you on Monday morning, with one stuck outcome and limited authority over the teams involved?
Not with a reorg. Not with a lecture about communication. With a better place to look.
Investigate one stalled outcome first.
This is the Stalled-Outcome Observation Guide: a practical observation guide for one stalled outcome. Try this with one outcome this week: pick something real from the last month and work through it.
Name the result. What was supposed to be delivered? Write the outcome, not the task list.
Trace the work. Where did roles or teams intersect? Mark every place the work changed hands.
Check decision authority. Who can decide or authorize the next step? Which reviews or controls are legitimately required?
Record what happened. What waiting, rework or information gaps, if any, did you actually observe? Write down what you saw, separately from what you think it means.
Then check other explanations. Capacity? Upstream quality? Requirements? Complexity? Sequencing? Legitimate controls? Any of these may explain the stall better than the boundary does.
Choose one next step. What can be checked or clarified within your authority? If the decision belongs to someone else, your next step is a clear question or an authorized escalation. It might also be gathering missing evidence, or concluding that no process change is warranted right now.
A few honest guardrails, because I’d rather you trust this than oversell it. This is a practical observation tool, and its effectiveness has not been validated. It won’t diagnose the root cause, score your team, or prove what a fix is worth. It also doesn’t give anyone permission to skip an approval, remove a specialist, or weaken a security, legal, safety, financial or compliance control. If you finish it and still aren’t sure what’s going on, that’s a legitimate result. You’ll be unsure with much better information.
Follow the work. Check the facts. Then choose one bounded next step.
The work was done. Now go find the outcome.
Let’s go back to that onboarding call. Every team marked its work complete, and the customer still had to repeat themselves. Nobody in that story needs to be the villain. We still don’t know what caused the stall. Maybe context didn’t travel. Maybe the goals changed. Maybe something else happened. What we do know is where to look first, and what else to rule out.
That’s the shift this whole series is about. When collaboration breaks, the reflex is to look at the people: who dropped the ball, who didn’t communicate, who needs coaching. Sometimes that’s right. But capable people can do their jobs well inside a system that still can’t deliver the result. Finishing your piece is not the same as delivering the result.
Go deeper with Collaborate Better
The Stalled-Outcome Observation Guide helps you find where the work stalled. Chapter Six of Collaborate Better, “Herding Cats, Breaking Silos, and Actually Getting Things Done,” picks up at the next question: once you know where to look, how do you get the right people into the right conversation at the right time to move it?
Inside the chapter:
The Right People, the Right Conversation, the Right Time, and what goes wrong when you get only one or two of the three
Psychological safety warning signs, including the “It’s fine” problem, and four ways to build it
Tuckman’s Form, Storm, Norm, Perform, and why every roster change sends a team back to Forming
The Tiger Team: how to build a small coalition of the willing to get stuck work moving
The pre-meeting: how the real work gets done before anyone walks into the room
If you’re accountable for an outcome you can’t fully control, start there.
Collaborate Better is available now in paperback and Kindle, with the hardcover coming soon.
Get your copy at CollaborateBetter.us.
Next Wednesday
Part 2 takes on a strange contradiction: Your Company Has a Communication Problem. So Why Are There So Many Meetings? We’ll look at the gap between activity and decisions, and you’ll get a tool for reclaiming one decision from the meeting treadmill. Chapter Six has a line for the worst case: the twenty-seven-person meeting “where nothing happens except the slow erosion of morale and hope.”
Your turn
Hit reply and tell me about a time the tasks were all marked done and the outcome still got stuck. What needed to cross the boundary? I read every response, and the best stories (shared with permission and anonymized) help shape the rest of this series.
P.S. If this landed for you, forward it to one person who owns an outcome they don’t fully control. It might save them a status meeting.
Sources
Starmer, A. J., et al. (2014). “Changes in Medical Errors after Implementation of a Handoff Program.” New England Journal of Medicine, 371(19), 1803 to 1812. doi:10.1056/NEJMsa1405556. Checked against AHRQ PSNet and WashU Source.
Urbach, D. R., et al. (2014). “Introduction of Surgical Safety Checklists in Ontario, Canada.” New England Journal of Medicine, 370(11), 1029 to 1038. doi:10.1056/NEJMsa1308261. Checked against AHRQ PSNet.
Tubre, T. C., & Collins, J. M. (2000). “Jackson and Schuler (1985) Revisited: A Meta-Analysis of the Relationships Between Role Ambiguity, Role Conflict, and Job Performance.” Journal of Management, 26(1), 155 to 169. doi:10.1177/014920630002600104. Citation confirmed via QIC-WD summary.
Previous:
The Demo Is Not the Decision
When an AI feature looks ready, someone still has to say what good enough means, and own it
More Content to Discover:
Half Your Team Is Using AI. You Don't Know Which Half.
Intro If you read the piece we published last week on Leadership in Change, you saw the structural diagnosis: mandate pressure, decision collapse, intake collapse. Three failures that sit underneath almost every AI pilot that goes sideways. That piece mapped the architecture. What it did not cover is what happens on the human side of the same problem, wh…
What if the biggest collaboration problem isn't that someone dropped the ball, but that nobody verified where it needed to go?
Five departments can report completed tasks while the shared outcome remains unverified. Before blaming anyone, check what crossed the boundaries, who had decision authority, and what else might explain the stall.
Here's what I'm curious about: Have you ever seen every team report “done” while the customer or project was still waiting? What turned out to be missing?