Ask a leader why a piece of work took four months instead of six weeks and you will usually hear about capacity. Not enough people, too many competing priorities, a difficult quarter. It is a reasonable answer and it is almost always the wrong one.

If you actually map where the time went, a pattern emerges with unnerving consistency. The work itself — the analysis, the build, the decision, the drafting — took a fraction of the elapsed time. The rest was spent waiting. Waiting for a review. Waiting for a sign-off from someone who did not know they were the blocker. Waiting for a team to pick up something that had been sitting in their queue, correctly formatted and entirely invisible.

Orchestration is the discipline of coordinating people, relationships and tasks to produce results. And the single highest-return place to apply it is not inside your team, where you have visibility and authority. It is in the handovers, where you have neither.

1. Recognise That Nobody Owns the Gap

Every team in your organisation has an owner. Every gap between two teams has none. This is not a failure of any individual leader — it is a structural consequence of how organisations are drawn. Accountability is assigned to boxes on a chart, and the delays live in the white space between them.

The practical effect is that queue time is invisible to everyone who could fix it. Your team measures the two days it took to do the work. The receiving team measures the day it took them to do theirs. Neither measures the eleven days the item sat between the two, because it was in nobody’s reporting line while it waited.

This is why capacity is such a persistent misdiagnosis. Adding people to either team reduces the working time and leaves the waiting time entirely untouched. You spend money and the delivery date barely moves, which then reinforces the belief that you need even more people.

Practical step: Take one piece of work that recently took longer than expected. Reconstruct its timeline honestly — not who did what, but where it sat and for how long. Most leaders doing this exercise for the first time find that sixty to eighty per cent of elapsed time was queue time. That number is your real problem.

2. Make the Queue Visible Before You Try to Fix It

You cannot manage what nobody can see, and cross-team queues are almost always invisible by default. An item sitting in someone’s inbox awaiting review does not appear on any dashboard. It has no status, no age and no owner. It simply exists in a state of quiet suspension until somebody chases.

Chasing, incidentally, is the informal system most organisations run on. The work that moves is the work whose owner is most persistent, most senior, or most willing to be irritating. That is a system, but it is a system that rewards volume of noise rather than importance of outcome, and it exhausts your best people.

The alternative is a shared, visible record of what is waiting on whom. It does not need to be sophisticated. A single list, reviewed by both teams at the same fixed moment each week, will surface more delay than any amount of process redesign. What matters is that an item’s age becomes something other people can see.

Practical step: Create one shared list of everything currently sitting between your team and the team you depend on most. Include the date each item entered the queue. Bring it to a standing fifteen-minute weekly conversation with your counterpart. Do nothing else for a month and watch how much moves simply because it is now observable.

3. Fix the Quality of What You Hand Over

Not all delay is the receiving team’s fault. A significant proportion of cross-team friction is caused by handovers that arrive incomplete, ambiguous, or requiring the recipient to reconstruct context that the sender already had.

When someone receives a request they cannot immediately act on, they rarely reject it. They set it aside. It becomes the thing they will get to when they have the mental space to work out what is actually being asked. In a busy week, that space never arrives, and your urgent request becomes a piece of low-grade background guilt in somebody else’s inbox.

The fix is unglamorous: agree explicitly what a complete handover contains. What decision is being asked for. By when, and what happens if it slips. What the sender has already ruled out. What the recipient does not need to worry about. Five lines of clarity at the point of handover routinely saves several days of drift.

Practical step: Ask the team you hand work to most often a single question: “What do you most often have to come back to us for?” Whatever they say, build it into a short standard format for every handover. Do the same in reverse for the team that hands work to you.

4. Reduce the Number of Handovers, Not Just Their Speed

There is a limit to how fast you can make a handover. There is no limit to how many you can remove. Once you have made queues visible, the more ambitious question is why so many exist in the first place.

Every handover is a point at which context is lost, a decision is deferred and a queue can form. A process with seven handovers has seven opportunities to stall, and each one compounds. Reducing that to four does more for your delivery speed than making all seven marginally more efficient.

Two moves usually deliver the most. The first is delegating decision rights downward so that approvals do not need to travel upward and back — most sign-offs exist because of an incident several years ago that nobody has revisited. The second is embedding a person from the dependent function into the work directly, so that the handover becomes a conversation rather than a transfer.

Both are harder than adding a dashboard, which is precisely why they are rarely done and why they work.

Practical step: List every approval required for a typical piece of work in your area. For each one, ask what would actually go wrong if it were removed or delegated a level down. Take the two where the honest answer is “very little” and change them.

5. Build the Relationship Before You Need It

The most reliable predictor of how quickly one team responds to another is not process. It is whether the two people involved have a working relationship that predates the request. Requests from strangers get queued. Requests from colleagues get done.

This is not a lament about organisational politics. It is a straightforward description of how attention is allocated under pressure. When everything is urgent, people prioritise the requests where they can picture the person waiting and anticipate the conversation that follows. Anonymity is the enemy of speed.

Which means relationship-building across functional boundaries is not a soft nicety to be done when things calm down. It is infrastructure. The thirty minutes you spend with your counterpart in a quiet month buys you weeks of responsiveness in a difficult one — and, just as importantly, it buys you early warning when something is going wrong at their end.

The leaders who deliver consistently across organisational boundaries are almost never the ones with the best processes. They are the ones who are owed favours and who reliably repay them.

Practical step: Identify the three teams your results most depend on. For each, book a recurring monthly thirty-minute conversation with your counterpart that has no agenda item other than “what is coming, and what is getting in the way”. Protect it when you get busy. That is exactly when it earns its keep.

If cross-team friction is quietly costing your organisation months, this is solvable — and it is largely a leadership behaviour problem rather than a process one. Our advisory and training work helps leaders build the coordination, relationships and decision-making habits that make delivery predictable. Get in touch to discuss your situation, or explore our services.

Related Reading

• Decision Velocity: How to Help Your Team Make Faster Decisions
• The Hidden Cost of Poor Team Dynamics — and How to Fix It
• How to Build Genuine Trust in a Remote or Hybrid Team

Frequently Asked Questions

How do I fix handovers with a team I have no authority over?

You almost never need authority — you need visibility and reciprocity. Making the queue observable to both sides changes behaviour without anyone having to instruct anyone. Beyond that, the most effective lever is going first: improve the quality of what you hand to them before asking anything of what they hand to you. Teams reciprocate improvements far more readily than they comply with demands from outside their reporting line.

Is this just a case for more project management?

No, and adding project management to a broken handover often makes things slower rather than faster, because it inserts another node into the chain. Coordination roles are valuable when they hold context that would otherwise be lost. They are counterproductive when they exist mainly to chase on behalf of people who could have spoken directly. The test is whether the role removes a handover or adds one.

What if the delay is genuinely caused by the other team being overloaded?

Then visibility is still the right first move, because it turns a private capacity problem into a shared prioritisation conversation — and prioritisation is a decision someone can actually make. Overloaded teams are rarely helped by being chased; they are helped by being told, credibly, which three of your eleven requests genuinely matter this month. Being the leader who does that reliably will get your work moved to the front of the queue more often than escalation ever will.