The hand-off is often the operating problem

I map how work crosses those boundaries and ask who owns the outcome when priorities conflict.

A clearer hand-off requires more than a process diagram. Teams need shared definitions, timely information and a practical escalation path. The operating review should reveal whether those arrangements work under real demand, including the exceptions that expose hidden constraints.

Hand-off problems survive because they belong to nobody. Each function can describe its own process accurately and demonstrate that it meets its own standards. The delay sits in the space between them, in a queue that no dashboard measures or a piece of information that one team assumes another already holds. Leaders who review performance function by function will see a series of green indicators while customers wait. The problem only becomes visible when someone follows a single piece of work from request to completion and records what actually happens to it.

That is the practice I rely on most. With the teams involved, I trace a handful of real cases through the workflow, noting every point at which work waits, is checked again or returns for clarification. We record who was waiting for what, and why. I then ask each team what it needs from the one before it and what it believes the next team needs from it. The answers rarely match, and the mismatch is usually where the most valuable improvement lies, because it shows where each side has been working from a private assumption.

Consider a business in which customer orders pass from sales to a credit check and then to fulfilment. Each team meets its turnaround target, yet customers complain about slow delivery. Tracing a sample of orders shows that sales often submits incomplete information, credit holds the order without telling anyone, and fulfilment learns of the problem only when the customer calls. A shared definition of a complete order, a simple notification when an order is held and a named person to resolve exceptions may remove more delay than any single team's efficiency programme.

One counter-argument is that the answer is a single end-to-end owner with authority over every function involved. In some cases that is right. More often, the functions need to remain distinct because they hold different expertise or controls, and reorganising around every customer journey would simply create new boundaries elsewhere. I prefer to keep functional structures where they serve a purpose and to design the interfaces between them with the same care we give to the work inside them, including agreed service levels and a route to escalate when those levels are missed.

This asks the leadership team to review operations in a way that cuts across their own reporting lines. Executives must be willing to hear that their function's performance creates difficulty elsewhere, and to change a local measure for the sake of the whole. The operating review needs time for end-to-end cases rather than only functional summaries. For the board, the useful question is whether management can describe how work flows across the organisation and where it most often stalls, not merely whether each part reports acceptable results.

When hand-offs are designed rather than inherited, the organisation becomes calmer. Teams spend less time chasing information and more time solving problems that genuinely need them. I measure operating design by how rarely senior leaders have to intervene to make ordinary work flow.