Lesson 15: Why “Voluntary” Process Adoption Usually Means It Won’t Work
Making a process optional seems polite. It looks like a nod to personal freedom and team autonomy. In reality, it’s almost a guaranteed way to get spotty results, endless debate, and a slow unraveling of anything good you’ve built. Here’s why mandatory is better – and how a lightweight exception process actually keeps it fair.
There’s a mistake I see all the time when teams try to improve how they operate. Here’s the pattern: you design a new process, you test it carefully, and the pilot goes well. You’ve got evidence that it works. Right when you’re ready to roll it out, someone pipes up: “Let’s make it voluntary for now. Let people opt in, build momentum, avoid the pushback that comes with mandates.” It sounds wise – no one wants to be the manager who drops another rule on an already overloaded team. Voluntary feels respectful. It feels like partnership.
But that’s not what actually happens. Instead, you get inconsistency. Some teams stick to the new process, others don’t. Handoffs or steps that the process was supposed to fix keep failing – because not everyone’s using the fix. When stuff breaks, the debate shifts away from “Did we follow the process?” to “Does the process even work?” Now, skeptics have the opening they’re looking for. Progress fizzles, not because the process was useless, but because it never had a fair shot in the first place.
After weeks of careful work – mapping flows, investigating root causes, setting up pilots, defining signals – what really makes it stick is this: you make the process mandatory. Handle exceptions directly, instead of letting chaos call the shots.
The Principle: Governance Only Works When It’s Mandatory, Simple, and Fair
Let’s say you introduced a boundary checklist last week – tracked it against your key signals, saw a strong correlation, and proved it works. Now, what you need isn’t more evidence. You need a policy: clear, minimal, and enforced.
Mandatory doesn’t have to be rigid or a paper-pushing nightmare. It’s not about stripping away all flexibility. Instead, you make exceptions explicit and temporary, not silent and limitless. A simple rule: if you need to skip the new process, write one sentence explaining why, get a named person to approve, and set a short expiration. That’s not bureaucracy. It keeps flexibility above board, instead of letting workarounds quietly weaken your improvements.
Here’s the difference: when people follow a process 60% of the time, it’s almost always because it’s optional. When compliance jumps to 92%, odds are, someone made it required.
Real Example: From Spotty Voluntary Use to 92% Adherence in Two Cycles
Let’s look at what this difference looks like on the ground.
We rolled out a checklist. Pilot results were solid – strong link between using it and better outcomes. Plenty of evidence to go bigger. So, we tried voluntary adoption. Instantly, things got patchy. People weren’t opposed to the checklist, but each team did their own math about when to use it: “We’re slammed this week,” or “this is an edge case,” or “we’ll skip it just this once.” Ironically, the times they skipped it were often the ones where it mattered most.
So, we changed the rule: checklist required at every handoff – no exceptions, unless you use the formal process.
Here’s what that looked like:
- If you need to skip it: Submit a one-line explanation, name who approved it, and set an expiration within a week.
- After seven days, the exception auto-expires. If you need more time, submit again.
- Every week, we review exceptions. Did they have a good reason? Did skipping the process create problems? Were some exceptions clues that the process itself needed a tweak?
The weekly review was key. It kept people honest – knowing exceptions would be discussed meant nobody phoned it in. It also showed us where the checklist really needed improvement. Sometimes, recurring exceptions showed up because the process itself needed tweaking.
Here’s what happened:
- Checklist use shot up to 92% in two cycles – just because the expectation was clear.
- Exceptions were infrequent and, when they happened, actually justified.
- Reviewing exceptions led us to fix two small process gaps, so future exceptions became even rarer.
- Teams who were most skeptical stopped resisting after one cycle, not because we convinced them the rule was perfect, but because the exception process was lightweight and reality-based.
So, with the process itself unchanged, just by changing the rules, we turned inconsistency into real adoption in a matter of weeks.
How to Make Mandates Work (The Practical Playbook)
The policy is straightforward. The hard part is sticking to it.
The rule: Use the checklist for every handoff in the Flow. No exceptions by default. Make it official – set the start date, share it with everyone, and don’t be fuzzy about when it kicks in. Vague rollouts die on the vine.
If someone needs an exception for a specific handoff, they must provide:
- A one-line reason why they truly can’t follow the standard process.
- The name of an actual person – an approver – who signed off. Not “the team,” not group-think.
- An expiry date within seven days, after which the default rule is back on.
All exceptions go in a shared tracker. Don’t let it disappear into a ticket graveyard – transparency matters.
Every week (these fits into your normal team sync-up), review every exception:
- Was the reason legitimate, or does the process need adjusting?
- Did skipping the checklist cause headaches elsewhere?
- Are the same kinds of exceptions popping up, hinting at a real process problem?
The review matters as much as the rule itself. It keeps the exception process from becoming a loophole and turns it into a channel for feedback and improvement.
When it comes to enforcement: compliance is the default. You don’t need to ask permission to do things the right way – only if you want to skip. That shift boosts adoption. Voluntary rules never really get you there.
The Real Takeaway
Mandates usually sound harsh at first. In practice, the anxiety drops fast – because the clarity helps everyone. Most pushback comes from two places: either folks have been burned by heavy-handed, tone-deaf mandates in the past, or they worry that true exceptions won’t be allowed. A small, concrete tool and a fair exception path take care of both. The rule isn’t a headache to follow, and the exception path is honest about the weird edge cases.
In my experience, people test a mandate for about one cycle. If the policy is minimal and the exceptions are handled fairly, resistance fades. Not because people have a philosophical change of heart, but because clear rules make life easier. Now they know what’s expected – and how to make a legitimate exception. No more endless judgement calls. The policy handles it.
Make it required. Make exceptions simple, visible, and time-limited. Do the review. Stick with it for two cycles. The clarity will do what endless encouragement never could.
Take a hard look at the process changes in your team or company right now. How many are “strongly encouraged” instead of required? For each one, ask: what would happen if you flipped the default, made it mandatory, and made skipping it require approval and a clear expiry? Usually, the answer tells you exactly why your compliance is where it is.
Next lesson, I’ll break down how to Run a Short, Brutally Honest Retro. See you then.