Handoffs: Where the Work Quietly Dies

Work rarely dies inside a team. It dies in the gap between two of them. Sales finishes the proposal and marks the job done. Delivery is waiting for a scope it can actually resource. Nobody is idle, nobody is being obstructive, and the work sits still for three days. Multiply that by every handoff in the business and you get the complaint founders bring us most often: everything takes longer than it should, and nobody can point at who is slow.

The short answer: work stalls between teams because most handoffs have no named receiver, no definition of done and no agreed response time. The fix is rarely a reorganisation or a new tool. Name one person to receive each handoff, write down what a complete handoff contains, and set a response clock, usually one working day. In the illustrative case below, closing half the queue across four handoffs takes three working days out of a thirty day delivery cycle, which is ten per cent of the cycle recovered without hiring anyone.

Why does work keep stalling between our teams?

Because the work has left one owner and has not yet reached another, and nothing in your operating system is accountable for that interval.

A handoff is the moment work changes owner. It is the only point in a process where, by default, nobody is responsible. Inside a team there is a manager, a queue and a metric. Between teams there is an assumption.

Teams optimise what they are measured on, and they are measured inside their own boundary. Sales is measured on signed revenue, so the proposal going out is the finish line. Delivery is measured on margin and on dates, so its clock starts when the scope is workable. Both teams are behaving correctly. The gap between their two definitions of done is where the three days live.

The symptoms show up in the research as time lost rather than as handoff failures. Atlassian's State of Teams 2025, a survey of 12,000 knowledge workers and 200 executives, found that leaders and teams waste a quarter of their time simply searching for answers. Microsoft's Work Trend Index survey the same year, covering 31,000 knowledge workers across 31 markets, found that 48 per cent of employees describe their work as chaotic and fragmented. Neither study is about handoffs, and that is precisely the point. Unmanaged intervals are never reported as intervals. They are reported as chasing, searching and explaining again.

There is a second reason this stays invisible for years. A stalled handoff produces no error. Nothing breaks and no customer complains on day one. The work simply waits, and waiting appears on nobody's dashboard. By the time it surfaces it has been laundered into a missed date, so the conversation becomes an argument about the date rather than an examination of the queue that caused it. That is why founders who are certain their teams are capable are also certain the business is slower than it should be. Both things are true at once.

Where exactly does a handoff break?

In one of five places. We call them the five drop zones, and the fix is different in each, which is why a general push for better communication reliably fails.

The five drop zones are the five conditions a handoff needs in order to complete. A handoff that satisfies all five rarely stalls. A handoff missing one stalls in a characteristic and predictable way, which makes the model useful as a diagnostic rather than a label.

Drop zone one is no named receiver: the work is handed to a team rather than to a person. Two is no definition of done: the sender's idea of complete is not the receiver's idea of workable. Three is no clock: nothing states when the receiver must respond. Four is no return path: the receiver has no legitimate way to reject an incomplete handoff, so they either absorb the gap silently or sit on it. Five is no ledger: nobody counts the wait, so its cost never reaches a budget conversation.

Exhibit 1: The five drop zones, and what to do about each

Drop zone	What you see	Root cause	The fix
1. No named receiver	It was sent to the team, and nobody picks it up for days	Handoffs addressed to a group. Groups do not act, people do	Name one person per handoff, plus a named deputy
2. No definition of done	Work bounces back for missing information two or three times	The sender's complete and the receiver's workable are different documents	The receiving team writes the checklist of fields, files and decisions
3. No clock	Work waits until somebody chases it	No agreed response time, so urgency is set by whoever shouts	One working day to acknowledge and either accept or reject
4. No return path	The receiver silently fixes gaps, or parks the work and looks slow	Rejecting a handoff feels like criticising a colleague	Explicit rejection with the missing items named, treated as data
5. No ledger	Everyone agrees things are slow and nobody can say how slow	Nothing measures the interval between two owners	Median wait per handoff, one number, reviewed weekly

Drop zone four is the one founders miss most often, and it is the one that corrupts the data. When a receiving team has no legitimate way to say that something is not workable yet, the incomplete handoff does not come back. It gets absorbed, which hides the defect and quietly trains the sender to keep sending incomplete work, or it gets parked, which looks from the outside like the receiving team being slow. Either way the sender never learns. A return path is not bureaucracy. It is the only feedback loop a handoff has.

What is the waiting actually costing us?

Far more than the chasing. In the illustrative case below the chasing costs about USD 19,000 a year, while the queue consumes six working days of every project's cycle, and that is where the money is.

Here is the arithmetic, with the assumptions stated so you can substitute your own.

Assume a Singapore professional services firm with 70 staff and USD 12M of annual revenue, running a 12 per cent operating margin, so roughly USD 1.44M of operating profit. It starts eight projects a month, 96 a year. Each project crosses four internal handoffs: sales to delivery, delivery to resourcing, resourcing to finance for billing setup, and delivery to client success at go live. The median wait at each handoff, once measured, is one and a half working days. The average project cycle is thirty working days.

The queue. Four handoffs at one and a half days each is six working days of waiting per project. Against a thirty day cycle that is 20 per cent of the cycle spent in a queue. Across 96 projects that is 576 working days of elapsed delay a year.

The chase. 96 projects times four handoffs is 384 handoffs a year. Allow one hour of chasing, explaining again and status asking per stalled handoff, split across sender and receiver, and that is 384 hours, or 48 person days. At a fully loaded USD 400 a day, USD 19,200.

The throughput. If measuring and closing the drop zones halves the queue, three working days come off each project cycle, which is 10 per cent. On a delivery team that is genuinely at capacity, 10 per cent shorter cycles is room for roughly nine more project starts a year. At an average project value of USD 125,000 that is USD 1.1M of additional revenue capacity, which at the same 12 per cent margin is about USD 135,000 of operating profit.

Illustrative, using the assumptions stated above. The throughput step is a model rather than a measurement: it assumes the delivery team is at capacity and that demand exists to fill the freed slots. If either is untrue, that number collapses, which is exactly why you measure before you model. The chase is a rounding error against operating profit. The queue is a fifth of your delivery cycle, and halving it is worth more than any efficiency programme aimed at the teams themselves, because the teams were never the problem.

Why do more meetings, a new tool or a reorganisation not fix it?

Because all three treat the handoff as a communication problem when it is an ownership problem. None of them names a receiver, defines done, or starts a clock.

The standing meeting is the usual first response. It converts a one day wait into a weekly wait with a witness. Work that stalls on a Tuesday is now discussed on Thursday, which is slower, and the meeting takes an hour from everyone who attends. Coordination of this kind compounds. Harvard Business Review's Collaborative Overload, by Rob Cross, Reb Rebele and Adam Grant in the January to February 2016 issue, reported that time spent by managers and employees in collaborative activities had ballooned by 50 per cent or more over the preceding two decades. Adding coordination surface is not the same as adding accountability.

The new tool is the second response. A tool makes a handoff visible, which is genuinely useful, but visibility is not ownership. A ticket sitting in a shared queue with no named receiver and no response time is the same stalled handoff with better reporting around it. Asana's Anatomy of Work Index 2021, a survey of more than 13,000 knowledge workers, found that over 60 per cent of the working day went on what it called work about work, the coordination and status layer rather than the work itself, and that 26 per cent of deadlines were missed. Those organisations were not short of tools.

The reorganisation is the third response and the most expensive. Merging two teams removes one handoff and creates two new internal ones, usually without naming a receiver for either. If the underlying handoff discipline is absent, the new structure grows the same queues in different places. This is the mechanism behind process debt: a workaround that works becomes permanent, and the next reorganisation gets built on top of it.

The alternative is smaller and considerably duller. A handoff is fixed by writing three things down and then holding people to them: who receives it, what complete means, and how long they have. That is a change to the operating cadence rather than to the structure.

What should we do on Monday?

Measure before you change anything. Pick the three busiest handoffs, log the wait at each for two weeks, and fix only after that.

Week one. List every handoff in the two processes that matter most to revenue. Most SMEs find between eight and fifteen. For each one, write down the sending team, the receiving team, and whether a specific named person receives it. Wherever no person is named you have found drop zone one.

Then start a crude log on the three busiest: the date and time the sender considers it sent, and the date and time the receiver starts work. A shared spreadsheet is sufficient. Resist the urge to improve anything while you are measuring, or you will never know what the fix was worth.

Week two. Keep logging, and write the definition of done for each of the three handoffs: the specific fields, files and decisions a complete handoff contains. Have the receiving team write it, not the sender. The sender's version describes what they have, the receiver's version describes what they need, and the gap between those two documents is drop zone two.

Week three. Set the clock and build the return path. One working day to acknowledge and either accept or reject is a reasonable default for most internal handoffs. Make rejection explicit and cheap: a rejected handoff goes back with the missing items named, and it is treated as information rather than as a complaint about a colleague. Then publish the ledger, which is one number per handoff, the median wait, reviewed weekly in a meeting you already hold.

That is the entire intervention, and it is deliberately unambitious. It works because a queue nobody counts always grows, and a queue somebody reports weekly almost always shrinks before anyone has formally changed a process. Naming the receiver is also what makes a date mean something, which is the same discipline that decides who owns the date on a project. If you cannot name, from memory, who receives the handoff between your sales team and your delivery team, you have your first week of work.

Frequently asked questions

How long does it take to fix a broken handoff?

Three weeks to measure it and set the rules, using the sequence above. The median wait usually starts moving in the first month, because reporting a number weekly changes behaviour before any process is formally redesigned. The slow part is not the change, it is holding the response time once everyone is busy again.

Do we need new software for this?

No. A shared spreadsheet logging send time and start time at three handoffs is enough to find the problem, and the definition of done can live in whatever tool you already use. Decide about software later, once you know which handoff is actually costing you money.

Who should own handoffs between teams, if no single team does?

One named person on the receiving side owns each individual handoff, and one operator owns the set of them. In most SMEs that is the COO, or whoever runs operations. If that seat is empty, this is the kind of work a fractional operator can hold for one or two days a week.

If work keeps stalling between your teams, the fix is measurable and it does not start with a reorganisation. Our operators measure the queue, name the receivers and hold the response times from inside the business, rather than writing you a report about it.

Rem.Up places senior independent operators as Fractional COOs and Fractional Project Managers in founder-led SMEs across APAC and Australia.

A matched Fractional COO starts from US$8,000 a month, month to month, with 10 working days' notice.

Book a free 30 minute call

Innovate. Optimize. Grow.