How to Build Processes That Actually Stick
You’ve seen it happen. Someone designs a beautiful new workflow. There’s a kickoff meeting. A training session. Maybe even a Confluence page with screenshots and a flowchart. Two weeks later, everyone’s back to doing things the old way.
New processes fail all the time. Not because they’re bad ideas, but because the way they’re introduced practically guarantees rejection. The process itself might be sound. The implementation is where everything falls apart.
Why Processes Die
The most common reason a process doesn’t stick is that it was designed by someone who doesn’t do the work. A manager or consultant maps out an ideal workflow based on how things should work in theory. The people who actually execute the work every day look at it, see the gaps, and quietly revert to what they know.
This isn’t resistance to change. It’s pragmatism. If the new process adds steps, creates friction, or doesn’t account for the messy reality of daily operations, people will route around it. They always do.
McKinsey’s research on organisational change consistently finds that transformation efforts fail about 70% of the time. And the top reasons are always human, not technical: lack of engagement, insufficient support, and processes that don’t reflect reality.
Start With the People Who Do the Work
The single most effective thing you can do when designing a process is involve the people who’ll use it. Not as an afterthought — as the starting point.
Sit with them. Watch how they work today. Ask what frustrates them. Understand the workarounds they’ve already built. Nine times out of ten, they’ve already figured out a better way to do parts of their job. Your process should capture that knowledge, not ignore it.
When people help design a process, they own it. When it’s handed to them from above, they tolerate it — briefly — before abandoning it.
Make It Simpler Than What It Replaces
This is the rule that gets broken most often. New processes tend to be more complex than what they replace, because they’re designed to handle every edge case, satisfy every stakeholder, and generate every report that leadership might someday want.
The result is a workflow with fifteen steps when seven would do. People don’t follow complex processes. They follow simple ones.
Strip it back. What’s the minimum viable process? What are the three or four steps that actually matter? Start there. You can add complexity later if — and only if — it’s genuinely needed.
A mate of mine runs operations at a mid-sized firm, and he told me the best advice he ever got was from a consultancy we rate: “If you can’t explain the process in under two minutes, it’s too complicated.” That stuck with me.
Document It Where People Actually Look
A process document buried in a SharePoint folder that nobody visits is effectively a process that doesn’t exist. Documentation needs to live where the work happens.
If your team lives in Slack, put the process summary in a pinned message. If they use a project management tool, embed it as a template. If it’s a warehouse workflow, print it and stick it on the wall.
The format matters too. Nobody reads a ten-page process document. A one-page checklist? That gets used. A short video walkthrough? Even better.
Build in Feedback Loops
Here’s what separates processes that stick from ones that don’t: iteration. The first version of any process is a guess. An educated one, hopefully, but still a guess.
Build in a mechanism for people to flag what isn’t working. A Slack channel, a regular five-minute check-in, a simple form — whatever fits your culture. Then actually respond to the feedback. Adjust the process. Let people see that their input changes things.
If you roll out a process and never revisit it, you’re telling people their experience doesn’t matter. They’ll respond accordingly.
Remove the Old Way
This one gets overlooked constantly. You introduce a new process but leave the old tools, templates, and pathways in place. People default to what’s familiar, especially under pressure.
If you’ve replaced a manual approval form with a digital workflow, remove the old form. If you’ve moved from email-based requests to a ticketing system, stop responding to email requests. Be clear and consistent. The new way is the only way.
It feels abrupt. But ambiguity is the enemy of adoption.
Measure Something That Matters
“Is the process being followed?” is the wrong first question. “Is the outcome improving?” is the right one.
If you introduced a new customer onboarding process, measure time-to-activation or customer satisfaction — not whether every checkbox got ticked. Processes exist to produce outcomes. If the outcome is better, the process is working. If it’s not, the process needs changing — even if everyone’s following it perfectly.
The Long Game
Processes that stick are built with people, not for them. They’re simpler than what came before. They’re documented where people actually look. They evolve based on feedback. And the old ways are deliberately retired.
None of this is complicated. But it does require patience, humility, and a genuine willingness to listen. Which, if we’re honest, is where most organisations fall short.
Build the process with the team, not in spite of them. That’s the whole secret.