The Reason Behind the Rule

Handing Over the Compass, Part 4 of 4 in our Leadership Development series.

Part 3 ended on the right to be wrong, and on how quietly it gets taken back, with the authority handed over in the meeting and then withdrawn one explanation at a time. The fourth stage turns that question around. Where Part 3 asked whether a decision survives us staying in the room, this one asks whether the judgment behind the decision survives us leaving the building.

Will, skill, trust, now legacy. Each one is unusable without the one before it. By the time we reach the fourth stage, many of us have already started writing things down. The trouble is what gets written.

The case for writing it down

There's a serious discipline around capturing what a leader knows before that leader goes, and it runs through playbooks, documented processes, the onboarding deck, and standard operating procedures. Operations people build entire careers on this, and a good one can take a process that lives in a single person's head and have it running the same way across four sites by the end of a quarter. A written procedure moves a known answer to a new person at almost no cost, and it moves the same answer every time, which is exactly what you want when the answer is already known. Most of the organizations I walk into have too few of these, not too many. And when somebody leaves with a routine that lives only in their head, the cost turns up almost immediately.

The instinct also gets stronger at this stage than at any earlier one. A succession conversation opens up, or a buyer asks a diligence question nobody can answer without us in the room, and the natural response is to write it all down while there's still time.

None of that is wrong. It's incomplete in one specific way.

Every procedure rests on somebody anticipating the situation, which makes it an answer to a question already asked and written down for the next person who asks it. But the events that break an organization are the ones nobody saw coming, and no documentation reaches them, because procedures run on precedent and a real crisis is often unprecedented.

Two ways to write the same rule

The difference is easiest to see in the writing itself.

A procedure says, "Respond to customer complaints within 24 hours."

A principle says, "We treat a customer problem as information about where our system is failing. Closing the ticket isn't the goal. Understanding what broke, and whether it will break again for somebody else, is the goal."

A procedure says, "Get manager approval for any discount over 10%."

A principle says, "Protect the customer relationship and protect the margin. When those two pull against each other, ask whether this customer's lifetime value justifies the short-term cost. If it does, make the call. Escalate if you're genuinely unsure."

The first version of each pair tells somebody what to do in a situation we predicted, and it does that job well enough. The second tells them how we think, and that’s the only part that carries into situations we never predicted.

That difference stays invisible until conditions change, and then it surfaces immediately. A team that has only the rule will either follow it into ground it was never written for or drop it and improvise. Both get chosen for the same reason: nobody ever told them what the rule was meant to protect.

The drills were never the point

The military taught me this long before I had any language for it. Battle drills are the building blocks of infantry work. React to contact. Break contact. Clear a room. Breach an obstacle. You run them until they execute without deliberate thought, because under fire, hesitation costs more than a wrong call does.

Passing those drills down was part of my job as a sergeant, and teaching them took a few weeks. The part underneath them took years. When do you modify the standard approach? How do you read ground that doesn't match anything in the manual? What did we learn on the last deployment that changes the way we run this one here?

Doctrine gives you the floor, and experience tells you when to leave it. A soldier carrying nothing but the drill will execute it perfectly into a situation it was never built for, and he'll do it with total confidence, because nothing we gave him suggested there was a judgment to make.

Handing back the principle instead of the answer

Very little of this moves through a documentation project. It moves in ordinary working moments that don't look like teaching while they're happening, which is why so few of them get used.

The next time somebody brings us a decision we've already made a dozen times, that's the moment. Not next quarter, and not in a scheduled development conversation, but that exchange, on that afternoon. Our answer is faster, and we both know it. Hand back the reasoning anyway. Here's how I'd think about it. Here's what I'd weigh. Here's what would change my mind. Now you make the call.

Then let them make it, in public, at whatever quality it lands. The 80% version they reached themselves teaches more than the correct version we handed them, and it compounds in a way the correct one never does, because the reasoning stays with them and the answer doesn't. Do that often enough and people stop bringing us the question at all. They bring the answer and the thinking behind it, and our job in the conversation shrinks to confirming what they already worked out.

The same holds for whatever we do put in writing. Next to the rule, write the reason for the rule in plain language, including what we're worried about and what would make us decide differently. That second paragraph is the one still doing useful work in five years, when the rule itself has been overtaken, and nobody left in the building remembers why it was written.

What to check

• Can the people using our rules explain why those rules exist? Ask three of them separately and compare what comes back. If the reasoning comes out differently every time, or not at all, then what we handed over was the rule and nothing underneath it.
• When something happens that nothing covers, what do people do? Do they wait, guess, or reason from what they've been taught? Whatever they do tells us what we've actually transferred, not what we've filed.
• Who else on the team teaches? Not mentors. Teaches. If every piece of judgment in the building has to route through us, then the organization's capability is capped at our calendar, and being unusually good at mentoring does nothing to move that ceiling.

Very little of my own judgment came from a formal document. It came from people who corrected a call I'd got wrong and then told me what they'd been weighing that I hadn't, usually in about 40 seconds, usually without either of us treating it as teaching. None of that was recorded, and none of it could have been. It still transferred, because somebody said the quiet part in front of somebody junior enough to need it.

That's the whole mechanism, and it's available every week in conversations we're already having. The question is how many of those we've been closing with an answer.

Part 4 of 4.