What Does A Right-Sized Process Look Like?
When people skip your process, it's rarely about discipline. It's about weight. Every process accumulates steps that stopped earning their place. Here's a framework for telling what belongs.
Essay 1 ended with a question: If the process is the real problem, how does anyone design a better one?
Prashant Bhargava
Before we get there, let us look at what happens when a process is not working. Since I have designed quite a few processes myself, one symptom I repeatedly see is that people try to work around the process or will skip the steps. As a process owner, the natural instinct is to reach for more enforcement — tighter reminders, advocacy, mandatory training, stricter enforcement and deadlines.
The process stays roughly the same. And the problem stays exactly the same.
Skipped Steps Are Evidence, Not Defiance
Every process carries with it two costs.
- Work cost: The effort it takes to do the actual task the process is built around.
- Adoption cost: The effort it takes to learn, navigate, and relearn the process itself before the work even begins.
Most process owners spend their energy optimizing the work cost. The adoption cost never appears in any report, any retrospective, or any training session.
When this adoption cost exceeds the capacity of the person responsible for carrying the process, they work around it. And instead of treating this as a signal that the process is failing, most owners double down on highlighting the importance of following the process, investing in detailed training rather than identifying what makes the adoption so costly in the first place.
The lower the adoption cost, the better the adoption.
It is basic arithmetic.
The absence of complaint is not a green light. It might just mean people have stopped flagging it.
How Processes Drift Away From The Right Size
Most heavy processes did not start that way. Nobody decides to build something that people wouldn't use. They build something reasonable, and then weight accumulates on top of it — one step at a time, each addition individually justified. What gets missed is revisiting the process to see what still belongs.
This is process debt, and it works exactly like technical debt. A codebase does not become unmaintainable in a single commit. It happens through small compromises that each make sense in the moment. A workaround here, a patch there. Nobody cleans it up because the system still runs. By the time the debt is visible, it has compounded into something that touches everything.
Processes accumulate the same way. Take a new employee onboarding checklist. On day one it has twelve items. Six months later someone adds a compliance training. A year later a new tool requires a walkthrough. Two years later there is an IT policy to acknowledge, a calendar to configure, a Slack channel directory that nobody maintains but everyone is asked to review. The checklist is now forty-three items. Each addition made sense when it was proposed. Nobody looked at the total.
The person arriving for their first day does not see twelve reasonable steps. They see forty-three, all due in the first week.
Weight accumulates without anyone deciding to add it. That is exactly why it can be removed the same way: one step at a time, with the right questions.
Not All Weight Is Wrong
Some processes do need to be exactly as heavy as they are.
A surgical checklist runs to dozens of steps for a reason. A nuclear plant shutdown procedure needs to be specific and followed to a T. A pharmaceutical manufacturing protocol documents every gram, every temperature, every timestamp, and it should. In these contexts, rigidity is not a design failure. Instead, failing to be rigid can lead to devastating outcomes.
The question is not how much weight your process carries, rather whether the weight it carries is right-sized.
To quantify this, I drew a Rigidity vs Formality quadrant. This matrix compares how rigidly a process must be followed against how formally it is documented. Plot any process against these two dimensions and you get four categories.
- Formal and rigid — appropriate for high-stakes, low-tolerance-for-error work: medical, legal, safety-critical.
- Formal and flexible — where most processes should live. Documented enough to understand the why, flexible enough to adapt to context.
- Informal and flexible — fine for low-stakes, high-frequency tasks where the team has deep shared context.
- Informal and rigid — the danger zone. Rigidly enforced but undocumented. Nobody knows why it works this way. The knowledge lives inside one person's head.
Ask this about the process you are auditing:
Given the stakes of the work it serves and the people carrying it, which quadrant should it belong in?
If your process belongs in formal and flexible but has drifted into formal and rigid, you have found the problem before examining a single step.
How To Tell If Each Step Is Earning Its Place
The grid above tells you whether the process as a whole is in the right quadrant. That is the process-level question. The step-level question is different: inside that process, is each individual step still doing useful work?
These are questions worth asking about every step:
- What failure does this step prevent? If you cannot name a specific, real failure mode, the step may be important in your imagination but not in practice.
- What are the stakes if it is skipped? This tells you which quadrant on the grid the process belongs in. High stakes, irreversible consequences — formal and rigid. Medium stakes, recoverable errors — formal and flexible.
- Who actually uses this step? If it only applies to a specific subset of people, it may not belong in the main process at all. It belongs in a separate one built for that audience.
- What does this step assume the person already knows? If it relies on context that is undocumented, implied, or only apparent to someone who has done it many times, that is where the biggest uncertainty is for someone just stepping in. The fix is not always removal, sometimes it is documentation. Make the assumption visible and the cost drops.
- How much effort does this step take to complete? A step can be justified by the failure it prevents and still be more effortful than it needs to be. High effort with low stakes is the clearest signal for redesign.
Run these questions across every step. A step that cannot answer all five is a candidate for removal or redesign.
Before you finish the audit, one thing is worth accounting for. The people carrying your process may not always tell you when it is not working.
Raising a problem with a process costs social capital, invites defensive responses, and rarely leads anywhere visible. So people stop raising it.
They find workarounds, absorb the cost privately, and say nothing.
If you want to know whether your process is right-sized, you have to create a condition where people can tell you it is not — without paying a cost for doing so. That means asking directly, listening without defending, and making changes visible. While creating psychological safety is essential, in the long run, what you really need are co-owners.
The Anatomy Of A Right-Sized Process
A right-sized process is formally defined and as rigidly implemented as the stakes demand.
Formally defined means:
- The documentation exists and is current. Not a forty-page manual, but a clear record of what each step is, why it exists, and what failure it prevents
- Someone touching the process for the first time in six months can look it up and carry it without needing to ask anyone.
- Someone joining the team can onboard without institutional knowledge being locked inside a colleague's head.
As rigidly implemented as the stakes demand means:
- Where a mistake is irreversible, every step is followed exactly.
- Where a mistake is recoverable, the person carrying it has room to exercise judgment.
- The process serves the work. The work does not serve the process.
Getting there and staying there requires work at both levels:
- At the process level — the grid test: Is this process in the right quadrant for its stakes and audience?
- At the step level — the audit: are the individual steps still earning their place?
Ideally the process audit runs on a schedule, not in response to a crisis. The same five questions from the diagnostic section, asked of every step, at least once a year. Not to make the process lighter for the sake of it, but to make sure every step is still earning its place.
This is the process designer's version of paying down technical debt. Not a one-time cleanup, but an ongoing practice.
Would You Follow Your Own Process?
Ask yourself one question today:
Would you follow your own process, under the same conditions as the people currently carrying it?
Not with your context. Not with your knowledge of which steps actually matter and which are legacy. Not with a quiet afternoon and no competing deadlines. But under the conditions of the person who touches it twice a year, under a deadline, already preoccupied.
If the answer is not a confident yes, the weight is not right yet.
Either the hammer needs changing, or you have been swinging it at nails that did not need it.
Further Reading & Links
- The concept of technical debt was introduced by Ward Cunningham at the 1992 OOPSLA conference to describe the accumulated cost of shortcuts in software architecture. The parallel to process design is direct: both accumulate through individually rational decisions made without accounting for the long-term total.
- https://www.hbs.edu/faculty/Pages/item.aspx?num=54851
Amy Edmondson's research on psychological safety, summarised in The Fearless Organization, established that teams with low psychological safety suppress problems rather than surface them.