Staple Yourself to the Work

Staple Yourself to the Work: A Practical Method for Process Improvement

Most process improvement initiatives produce one thing with great reliability: a better-looking diagram of a process that still doesn't work.

The map gets drawn. The consultants leave. The work continues to stall in the same places it always did, for reasons that the map never captured.

The problem is almost always the same: the people designing the improvement weren't close enough to the work. They mapped what the process was supposed to look like, not what it actually does.

There is a better starting point. I call it stapling yourself to the work.

Why this language, and where it came from

I first encountered this idea in Dave Gray and Sunni Brown's book Gamestorming — the underlying concept of following a work item through a system to find where it slows, stalls, or breaks. The industry terms for variations of this are value stream mapping, process mapping, swim lane analysis. They are useful. They are also, in my experience, immediately off-putting to anyone who didn't choose to become a process specialist.

Language shapes engagement. And engagement is what makes the improvement actually happen.

When I stopped saying "value stream mapping" and started asking teams to imagine stapling themselves to a piece of work and following it through the building, something changed. People leaned in. The image was vivid. The activity became something they could picture — and therefore something they wanted to try.

Good systems work begins with good sense-making. The language you choose determines whether people bring their knowledge into the room or leave it at the door.

Why this is a leadership responsibility, not a specialist one

Improving how work moves through a system is not a side activity for a process team.

It is one of the central responsibilities of management.

Processes shape experience. They determine whether work feels purposeful or exhausting, whether customers feel looked after or ignored, whether good people stay or leave. A team can have the right talent, the right intentions, and a genuinely valuable product — and still deliver poorly, because the system they're working within creates friction at every step.

If leaders are not improving the system, they are implicitly endorsing it. And the only way to improve a system is to understand how work actually moves through it — not in theory, not on a process diagram, but in reality.

How to do it: the method in full

Get the right people in the room

The best source of truth is not a document.

It is the people who do the work every day. They know exactly where it sticks, loops back, waits, and breaks. They have usually known for some time. What they often lack is a structured opportunity to say it.

Bring them together — everyone who touches the work item you're following. Give them notice beforehand. Ask them to come with data, observations, and honest accounts of what they actually do. Not what the process document says they do. What they actually do.

This session is not about blame. It is about seeing clearly. Hold that distinction carefully, and say it out loud at the start.

Involve managers too — they own the system and will need to sponsor whatever changes follow. If they're not in the room, the improvement gets orphaned the moment the session ends.

Prepare the space properly

You need room to think visually.

A large wall, plenty of index cards and Post-its, sticky tack, and time. For remote teams, a shared digital board works — Miro, FigJam, whatever the team already knows.

Book at least 90 minutes for the first session, ideally more. Rushed mapping produces shallow insight. In practice you will likely run several sessions — the first one almost always surfaces a gap, a missing person, or a piece of the system nobody in the room fully understands. That is useful information. Build in room for it.

Choose a real piece of work and follow it

Pick a genuine work item — a customer onboarding case, a new hire, a software release, a sales proposal, a support ticket. Something real, not a theoretical average.

Then staple yourself to it. Trace its journey from the moment it enters the system to the moment it leaves. Every step. Every handoff. Every approval. Every wait.

Capture what actually happens: how long each step takes, where the work sits idle, where it gets sent back, where it duplicates effort, where a single person becomes a bottleneck because knowledge lives only in their head.

Map it left to right. Do not map what you believe the process should look like, or what you'd like it to look like. Map what it does look like — no matter how complicated, how surprising, or how uncomfortable that is.

This is where illusions fall away.

Make the whole system visible at once

Lay the full process out so everyone can see it simultaneously.

Something happens when people see their system end-to-end for the first time. Complexity that felt normal becomes obviously excessive. Delays that seemed unavoidable turn out to be structural choices nobody ever questioned. Handoffs that everyone assumed were clean turn out to involve significant rework.

Visibility creates shared understanding. And shared understanding is the only reliable foundation for lasting improvement.

This visualisation is also a powerful lever with senior leaders who may have no idea what it actually takes to deliver a good outcome for a customer. A wall covered in index cards is harder to dismiss than a status report.

Study the system, not the people

Spend time with what you have mapped before jumping to solutions.

Look for patterns: where does work stall? Where does it bounce between teams without progressing? Where is knowledge concentrated in a single person? Where are there duplicate steps, unnecessary approvals, or rework that keeps reappearing in the same place?

Look for what is working too — there will be parts of the process that flow well, and understanding why is just as instructive as understanding why things stall.

Do not look for culprits. Systems create behaviour far more reliably than personality ever will. The person who is a bottleneck is usually a symptom, not a cause.

Design what better looks like

Once you have a clear picture of the current state, ask a different question:

What would great look like? Not perfect — better. What would make this process feel straightforward for the customer? What would make it feel less exhausting for the team?

In the original approach this is sometimes called drawing Utopia — a deliberate act of imagination about the future state, placed next to the current state map so the gap between the two becomes visible and actionable.

That gap is your agenda.

Change deliberately, not dramatically

Translate the gap into action — but carefully.

Small improvements, tested methodically, compound into significant change. Grand redesigns imposed suddenly tend to create confusion about what worked and what didn't, and often meet resistance precisely because they ask people to change too much at once.

Smooth is fast. Effectiveness before efficiency. Get the process working well first — then optimise.

A word on this distinction: it can be tempting to make a broken process more efficient before establishing whether it is working effectively. Optimising a process that is doing the wrong thing more quickly is not improvement. Study the effectiveness of what the process produces before you reach for efficiency.

Document the sessions. Communicate the summary back to everyone involved and ask them to review it. Manage the change with the same care you'd give to any significant piece of work — because it is.

What this really teaches

Stapling yourself to the work does something that goes beyond any individual process improvement.

It changes how you see organisations.

You stop managing abstractions — the plan, the report, the metric — and start managing reality: the actual experience of work as it moves through the system you are responsible for.

When leaders understand how work truly becomes value, and where that journey goes wrong, better decisions follow naturally. Not because they have more data. Because they have more understanding.

That is the quiet craft of good management.

Not control. Understanding.