Where Work Goes to Die: Reading Handoffs in a Swimlane Map (Good vs. Bad)
Most process problems aren't inside the boxes — they're between them, at the handoffs where work crosses from one team to another. A swimlane diagram (a cross-functional process map) is the Lean Six Sigma tool built for exactly this: it lays out the steps horizontally and assigns each one to a lane owned by a role, department, or system. Every time an arrow crosses a lane boundary, you're looking at a handoff — and handoffs are where time, accountability, and information leak out. With teams scattered across home and office through the disruptions of the last two years, those handoffs got longer and quieter, which is precisely why mapping them earns its keep.
But a swimlane map only helps if you build it to reveal the truth. Drawn carelessly, it becomes decoration. Here is what separates a diagram that drives improvement from one that just looks busy.
What a good swimlane map looks like
Lanes are roles or systems, not vague departments — "Estimator," "Permitting Clerk," "ERP system," so each handoff has a name attached, not a building.
It maps the process as it actually runs, captured by walking through it with the people who do the work — not the tidy version in the procedure binder.
Every lane crossing is treated as a risk point and labelled: what gets handed over, in what form, and what the receiver waits for.
Delays and queues are marked between steps, so the wait time hiding in the gaps is visible, not just the work time inside the boxes.
Decision points show what happens on the 'no' path, because rework loops usually start at a branch nobody mapped.
It fits on one page or one screen at the right altitude — detailed enough to find the leak, simple enough that a stakeholder can follow it on a call.
What a bad swimlane map looks like
Lanes are named after big departments ("Operations," "Finance"), so handoffs blur and no individual role owns the gap.
It documents the official process nobody actually follows, so the real bottleneck never appears on the page.
Arrows cross lanes constantly with no note on what's exchanged — you can see that a handoff happens but not why it stalls.
Wait time is invisible: every box is a task, none is a queue, so a five-day approval delay looks identical to a five-minute one.
Happy-path only — the 'rejected,' 'incomplete,' and 'sent back' routes are missing, which are exactly where the waste lives.
It's so dense it can only be read zoomed in, so nobody but the author can use it to make a decision.
Reading the map once you have it
Count the lane crossings. Each crossing is a chance for delay or dropped information. A step that bounces across four lanes before completing is a redesign candidate before you change anything else.
Find the longest quiet gap. Look for handoffs where work sits in someone's inbox. That dwell time is usually a larger prize than speeding up any single task.
Trace the rework loops. Follow every 'no' and 'returned' path. If work routinely loops back two lanes, the upstream step is handing over something incomplete — fix the source, not the symptom.
The diagram itself changes nothing; it just makes the handoffs impossible to ignore. Used honestly, a swimlane map turns a fuzzy complaint — "this process takes forever" — into a specific, fixable picture of where, between which two people, the work goes to die.
When you need to see where work actually stalls across teams and turn that picture into a better-designed process, XNM's strategic advisory can map it with the people who do the work and help you fix the handoffs that matter most.