What \"It Depends\" Really Means
Watch someone describe their own work and count how many times they say "it depends."
It's the most informative thing that happens in a discovery session, and almost nobody follows it up.
"How do you decide which supplier to use?" It depends. "When do you chase an unpaid invoice?" It depends on the client. "How long does onboarding take?" Depends how organised they are.
Each one marks a decision that exists, gets made correctly, dozens of times a month — and has never been written down.
Why it matters more than it sounds
An undocumented decision is not a small gap. It's the thing that makes the whole process non-transferable.
You can write down every step of a process in perfect detail. If step four contains a judgement nobody has articulated, the procedure is unusable by anyone except the person who already knows.
That's why documentation efforts so often produce procedures nobody follows. The steps got written. The decisions didn't.
And it's why automation projects fail on processes that looked simple. A machine cannot do "it depends." It will pick one branch every time, and the cases that should have gone the other way will go wrong quietly.
The three kinds
Not all of them are the same, and the response differs.
1 · The rule that was never stated
Most of them. There is a rule. It's consistent. Nobody has ever said it out loud.
"When do you ask for a deposit?" "It depends on the job." "What makes you ask for one?" "If it's over a couple of thousand, or if I haven't worked with them before."
That's a rule. It took one follow-up question. It can go in a procedure, it can go in a form, and now someone else can apply it.
These are the win. Most "it depends" answers are one question away from being a written rule, and nobody asks the question.
2 · The rule with a missing threshold
Half-articulated. The variable is known, the cut-off isn't.
"It depends how busy we are."
Busy how? At what point does the answer change? There's a number in there, and the person applies it consistently without having named it.
Getting it requires walking through cases. "Last Tuesday — would you have done it then? What about the week before?" Three or four examples usually produce the threshold.
3 · Genuine judgement
A real minority. The decision depends on context too varied to reduce — reading a client's tone, weighing a relationship, pattern-matching on years of experience.
These exist and shouldn't be forced into rules. Pretending a judgement call is a rule produces a procedure that's wrong in exactly the cases that matter.
The right response is to name it: this step requires judgement, here's who makes it, here's what information they need. That's a complete answer, and it tells you something important — this step can't be delegated or automated yet, and you should design around that rather than ignore it.
How to tell them apart
Ask for three real cases where the answer was different.
If the person can explain each one and the explanations share a structure — you have a rule.
If they can explain each one but the explanations are all different — you probably have a threshold, and you need more cases.
If they say "you just get a feel for it" and can't explain further, you may have genuine judgement. Probe once more, then accept it.
Why it stays undocumented
Not laziness. Three structural reasons.
It doesn't feel like a decision. When you've made the same call four hundred times, it stops registering as a choice. It feels like noticing, not deciding.
Nobody asks. The person who knows isn't going to volunteer a rule they don't know they're applying. It takes someone outside the work to notice the gap.
Articulating it is harder than doing it. Converting an intuition into a stated condition is genuine cognitive work. It's easier to keep making the call.
That last one is why this doesn't get fixed from the inside.
What it costs
You can't delegate. Hand the process over and the new person gets the steps but not the judgement. They either ask constantly or get it wrong.
You can't automate. The build will encode one branch. The other cases fail, usually silently.
It leaves with the person. When they go, the rule goes. It gets reconstructed, badly, over months.
It's inconsistent and nobody can tell. Undocumented rules drift. Two people applying "their" version of the same decision produce different outcomes, and there's no reference point to detect it.
What to do about it
Listen for it. In your own business, when someone describes their work. It's a flag, and it's easy to miss because it sounds like a normal thing to say.
Follow it up, once. "What makes you choose one or the other?" One question resolves the majority of them.
Write the answer in their words. Not your tidied-up version. Theirs — it's more accurate and they'll recognise it.
Mark the real judgement calls explicitly. DECISION: [name] in the procedure. That's a complete, honest answer, and it's more useful than a fabricated rule.
The thing worth noticing
A business runs on far more decisions than anyone has counted, and almost none of them are written down.
That's not a failure. It's how small businesses work, and the judgement is usually good.
But it's the reason the owner can't take a holiday, the reason hiring makes things harder before it makes them easier, and the reason the automation project that looked straightforward took four months.
Every "it depends" is a piece of the business that currently can't leave someone's head.
Most of them are one question away from being written down.
"It depends" is almost always a rule that nobody asked about. Ask.
Want someone to ask the questions nobody's asking?
A free systems audit finds the decisions your business runs on and hasn't written down.