Handovers

Idea one

The route itself may be the problem

Some handovers are obvious. An engineer completes a visit and passes the record for invoicing. Support receives a portal complaint and sends the technical details to Technology. Others are less visible. A manager mentions a concern in a meeting and assumes someone will act. An employee copies a colleague into an email without saying what response is required. A Finance analyst sees an urgent request in a shared mailbox but does not know whether they are expected to decide it, investigate it, or pass it to someone more senior.

In every case, the work crosses a boundary. Between functions, managers, shifts, systems, or between a person who has noticed a problem and a person who has the authority to change it. The more boundaries a piece of work crosses, the more chances it has to slow down, lose information, or lose its owner altogether.

Organizations usually try to improve work by looking at the people involved — was someone responsive enough, proactive enough, clear enough? Those questions may matter. But they can miss a more basic problem: the route itself may be poorly designed.

If five people must touch a request before anyone can act, the organization has created five opportunities for delay. If each needs different information and nobody has defined what should travel with the work, the request returns repeatedly for clarification. If a person is expected to act but lacks authority, the handover is not complete. It is simply the start of another escalation.

Mapping handovers means following the work as it actually travels, not as the process document says it should travel. Start with one real piece of work that happens often, frustrates customers, or crosses several teams — not an exceptional crisis, which may involve unusual circumstances.

And a map should not stop at the list of steps. At each handover: who sends the work? Who receives it? What information travels with it? What decision or action is expected next? What authority does the receiving person have? How quickly must they respond? How do they know it is urgent? Who remains accountable for the overall outcome while the work is elsewhere?

Idea two

The active work is not the problem

The map should include waiting, not only activity. Most process descriptions record what people do. They do not record how long work sits between actions.

A request may take ten minutes to prepare, five for the warehouse to confirm stock, and fifteen for an engineer to collect the part. Yet the customer may wait eight hours because the request sits in a Finance mailbox without a clear urgency marker or named decision-maker.

The active work is not the problem. The waiting is.

This is one reason people inside an organization can disagree so strongly about whether a process works. Each person sees their own contribution. Finance may say, correctly, that it decided within two hours of receiving all required information. Operations may say, correctly, that it had been waiting since the customer first called. The warehouse may say, correctly, that the part was ready all afternoon.

All three accounts can be true. The customer still experiences one long delay.

A handover map brings those separate experiences into one timeline. It shows the difference between elapsed time and working time — where the work was active, where it was waiting, and why.

And the map has to be drawn with the people who perform the work, not only the managers who designed it. A formal process may say Support logs a portal issue, Technology investigates, Product prioritises. Advisers will explain they also identify duplicate cases, send manual documents, update account managers, chase ticket updates, and decide whether another complaint is serious enough to escalate. Technology will explain the ticket lacks the error details needed to reproduce the fault. Product will explain it sees a list of technical requests but not the volume of customer contacts. None of these details may appear in the official process. Together, they are the real process.

Idea three

The reasons for waiting repeat

Sometimes the receiving team does not know that work has arrived. Shared inboxes, ticket queues, and meeting notes can conceal requests as effectively as a locked door.

Sometimes the request arrives without enough information, so the receiver must ask questions, wait for answers, and begin their review again. Sometimes there is no agreed service level — the sender believes it needs an answer today, the receiver believes it will be reviewed within the normal two-day cycle. Sometimes authority is missing: the person receiving the request understands the issue but cannot decide, so they pass it upward.

Sometimes priorities conflict. Support needs the portal defect fixed; Technology has a committed security upgrade; Product owns the priority. Each team can explain its own position, but unless someone has the authority to weigh customer harm, technical risk, capacity and commercial impact, the issue moves between teams without moving toward a decision.

And sometimes the handover is technically complete but psychologically abandoned. The sender says "I have raised the ticket" and assumes their responsibility has ended. The receiver says "it is in the queue" and assumes someone else will decide its importance. The customer keeps calling Support, which creates manual workarounds and has no route to change the underlying defect.

The work has many participants and no owner.

Which is why the remedy depends on finding the real point of friction. If leaders believe the issue is warehouse responsiveness, they may introduce faster stock reporting or move the warehouse under Operations. Neither change addresses the actual delay. When the warehouse has confirmed stock and prepared the part and cannot release it, the warehouse is not a source of delay. It is holding a decision that belongs elsewhere.

Idea four

Owning a step, and owning the outcome

It is useful to distinguish between ownership of a step and ownership of an outcome. The warehouse supervisor owns confirming and releasing stock. The finance manager owns approving a defined credit exception. The service manager owns arranging the repair. But someone must own the outcome: restoring the customer's equipment while the commercial and financial consequences are handled properly.

That person does not need authority to perform every task personally. In fact, they should not. But they need enough authority, visibility and support to keep the work moving when it crosses boundaries.

Without it, the organization creates a relay race in which every runner can stop after passing the baton, even if the baton has been dropped.

Northstar may have clear step ownership throughout the urgent repair. Sales owns the relationship, Operations the technical assessment, the warehouse stock handling, Finance the credit decision, the engineer safe completion. But who notices if the whole journey stops?

If every participant assumes their responsibility ends when they pass the work onward, nobody is watching the outcome. The account executive believes Operations is dealing with it. The service manager believes Finance has the request. Finance believes it needs more information. The warehouse waits for a release instruction. The customer calls Support again, creating a separate ticket that does not connect to the original request.

The organization has many owners of pieces and no owner of progress.

This is worst when work becomes inconvenient. Everybody is willing to own the part that fits their role. Fewer people feel responsible for the uncertainty between roles — the missing information, the disputed priority, the unclear exception, the customer communication nobody has formally assigned. The result is orphaned work: active enough that people can say it is "in progress," but nobody is actively carrying it toward resolution.

Idea five

What a handover needs, and why it is not about attitude

A handover works when the receiving person knows that work has arrived, understands why it matters, has the information needed to act, possesses the authority required for the next decision, and knows who remains responsible for the wider outcome. Where one of those conditions is missing, work begins to stick.

That is where the real org chart becomes visible: not in the lines between boxes, but in the calls, queues, inboxes, meetings, approvals, and personal relationships through which one person tries to make another person's work continue.

And this can sound unfair to the people involved. A gap is not necessarily a place where someone has been careless, unhelpful, or incompetent. In fact, many gaps are created by capable people doing exactly what their own role asks of them. Finance protects cash. Operations protects service and safety. Sales protects the relationship. Technology protects system integrity. The warehouse releases stock accurately. The failure appears when those responsibilities do not join up around the outcome.

From inside, each part looks reasonable. From outside it, the company has failed to act. A problem that belongs entirely to one person is easier to see and correct. But a problem that sits between people is less visible, and each group sees the gap from its own side — which is why cross-functional problems so often become arguments about attitude. People say another team is "unresponsive," "bureaucratic," "not commercial," or "always creating last-minute emergencies." These labels may contain a fragment of truth, but they usually avoid the more useful question: what does the handover require, and what is missing when the work crosses this boundary?

Usually it is information. A stronger handover does not require every person to know everything. It requires the right information to travel with the work. The account executive need not become a technical expert — but they should know which facts Operations needs before it can begin. The service manager need not become a credit specialist — but she should know what Finance needs to assess an urgent exception. The gap closes when people can see enough of one another's reality to make a proportionate decision.

Often it is authority. A handover can look complete because the request reached the correct team, while the receiver still cannot take the next step. Each move upward may be formally correct. Each adds waiting. The remedy is not to hand the service manager every authority — that would weaken specialist control. It is to make the route to the necessary authority visible, fast enough, and reliable. The gap is not removed by telling her to "take ownership." It is removed when the organization defines what ownership enables her to do. Ownership without a route is simply responsibility for waiting.