A process nobody decided on is a step your team repeats only because one person did it that way once, and the habit outlived the reason, so now it runs on memory instead of a choice anyone would defend today. Writing it down never made it a decision. It just made the accident official.
- A process nobody decided on survives because repetition feels like a reason, even when no one chose it.
- Documentation records what you do, not why, so a written step can carry an undecided origin forward unchanged.
- The work comes back to you because the judgment behind a step never fit on the page.
- You find the undecided step by asking who started it and watching the room go quiet.
- A step that no one can defend is not automatically wrong, but it is always worth questioning.
What is a process nobody decided on?
A process nobody decided on is a recurring step your team performs purely out of habit, one that started when a single person did it a certain way once and everyone copied it, so the practice now continues without any deliberate choice behind it or anyone who remembers the reason. It hides in plain sight because it works well enough. The output shows up. Nothing breaks. So nobody stops to ask whether the step earns its place or just occupies it.
Here is the part that stings. You probably have one of these running right now, and you are reading it as proof that your operation is clean. That confidence is exactly the camouflage. The step feels load-bearing because you have leaned on it so long. Leaning on something is not the same as choosing it, right?
A step that survives on repetition alone is a decision no one ever made, repeated until it looked like one.
Why does writing it down fail to get it off your plate?
Writing a process down captures the visible actions but not the judgment underneath them, so the documentation hands someone the sequence without the thinking, which means the first unusual case bounces straight back to you because the page never held the part of the job that actually mattered. You wrote the what. The why stayed in your head.
This is the gap researchers call tacit knowledge, the understanding you carry but cannot fully put into words. The philosopher Michael Polanyi framed it as the simple fact that we can know more than we can tell. You can describe every click. You cannot describe the small call you make when the click does not fit the situation. That small call is the real job, and it does not transfer by writing the preliminary stuff down and asking someone to follow it.
So the documentation exists. The work still finds you. Those two things were never the same accomplishment, even though we treat them like one. The anchor moment I keep returning to is handing someone the whole setup, walking them through it, and then having to ask: did she do it? Not did she follow the page. Did the actual thing happen. The page could be perfect and the answer could still be no.
How do you tell a chosen step from an inherited one?
You tell a chosen step from an inherited one by asking who decided it and why, because a chosen step has an owner and a reason you can state out loud, while an inherited step produces a shrug, a guess, or a name of someone who left two years ago and took the context with them. The shrug is your signal.
Most of the operational chaos I see is not loud. It is quiet repetition that nobody questions because questioning it feels rude to whoever set it up. Here is a way to sort what you are looking at.
| Signal | Chosen step | Inherited step |
|---|---|---|
| Owner | Someone names themselves | Nobody, or a person long gone |
| Reason | Stated in one sentence | “That’s just how we do it” |
| Last reviewed | Within memory | Never, or nobody knows |
| What breaks without it | Something specific | Unclear, possibly nothing |
Run a real step through that table. If three of the four columns land in the right-hand side, you have found one. The point is not to rip it out on sight. The point is to know you are standing in front of something no one actually decided.
Why keeping the undecided step might still be right
An undecided step can still be the correct step, because the original reason may have been sound even though the person who held it is gone, and tearing out a practice before you understand why it exists tends to remove a protection you did not know you had. Finding it is not the same as condemning it.
This is the idea behind Chesterton’s Fence. You come across a fence in a field with no obvious purpose. The careless move is to remove it because it looks pointless. The wiser move is to find out why someone built it before you touch it. Your undecided step is that fence. You are allowed to question it. You are not allowed to assume it is dumb just because the reason walked out the door.
Finding the step nobody decided on is the whole job. Deciding what to do about it is the next one.
Where these steps actually hide
The undecided step is rarely the big one. It is the small ritual wrapped around the big one. The extra approval. The file named a certain way. The report that gets sent to someone who stopped reading it a year ago. The order you do things in that nobody chose but everybody honors.
There is a whole field studying this. Organizational routines persist as inertia, not as ongoing decision, and the pattern people imagine a routine follows often drifts from what they actually do day to day. If you want the formal version, the research on organizational routines as a unit of analysis separates the pattern in your head from the actions in the room. The gap between those two is where your undecided step lives. You can also read the shorter overview of Chesterton’s Fence if you want the full logic before you go pulling anything.
So here is the direct question, and I am going to resist handing you one of mine to copy. Which of your processes exists only because somebody did it that way once? Not which one is broken. Which one runs on habit with no name attached. Go find it. Yada yada yada about cleaning up your operations later. First, just locate the one step nobody ever actually decided on.
What surprises people is how fast the room goes silent when I ask who started a step. I will be walking a team through their own documented workflow, everything neat, everything written, and I stop on one line and ask why it is there. The pattern that shows up almost every time is a pause, then three people looking at each other, then a name of someone who left. The page made the step look decided. The silence tells the truth.
Frequently asked questions
How do I find a process nobody decided on?
Walk your own workflow and stop on each step to ask who started it and why. The one that produces a shrug, a guess, or the name of someone who left is your answer. A step with a clear owner and a stated reason is chosen. A step that only has habit behind it is the one you are looking for.
Why does the work come back to me even after I document it?
Because documentation captures the actions but not the judgment behind them. The page tells someone what to do in the normal case. The first unusual case has no page, so it bounces back to the only person who carries the reasoning, which is you. Writing it down was never the same job as getting out of it.
Is a step that nobody remembers starting always wrong?
No. A step with a forgotten origin can still be correct and even protective. The original reason may have been sound even though the person who held it is gone. Find out why it exists before you remove it. Questioning a step is smart. Assuming it is pointless because nobody remembers is not.
What is the difference between a routine and a decision?
A decision has an owner, a reason, and a moment it was made. A routine is a pattern that repeats on its own momentum, often drifting from whatever anyone originally intended. Routines persist as habit, not as ongoing choice, which is exactly why so many undecided steps survive untouched for years.
Why can’t I just write better documentation to fix this?
Better documentation helps with the actions, not the judgment. The part that keeps pulling work back to you is the thinking you do when a case does not fit the page, and that thinking resists being written down. You can improve the page forever and still own the exceptions, because the exceptions were never on the page.
How do I know if a step is load-bearing or just old?
Ask what specifically breaks if you remove it. A load-bearing step has a concrete answer. An old step produces vagueness, or the discovery that nothing breaks at all. If you cannot name what fails without it, you are looking at habit wearing the costume of necessity.
You do not need a project for this. You need one honest pass through your own workflow and the willingness to stop on a step and ask who started it. The silence will tell you where to look. Keep it for now if the reason turns out to be sound. Question it for real if the only reason is that someone did it that way once.
Then do one thing. Name the step in the comments. Bonus points if nobody remembers who started it. I want to see how many of us are honoring a decision that no human actually made. If you want more of these questions and the people working through them, that is what the community is for.
… and see more of my posts in your Google results.