The Rule Was Reasonable. The Reasoning Did Not Survive.

A financial domain client brought me in to help the team navigate a transition to Scrum. The presenting problem was straightforward: code was piling up waiting for reviews, and the team did not believe the move to Scrum would deliver the acceleration they needed if they could not clear that bottleneck first.

I started digging into why certain developers were not reviewing and approving code. What I found was a ghost rule: a standing practice with no documentation and no living author.

When the code review practice had originally been established, certain developers on the team were not considered senior enough to approve. That was a reasonable call at the time. But years had passed. Promotions had occurred. The developers in question had grown into exactly the kind of engineers the rule had been designed to eventually include. Nobody had updated the rule because nobody had written it down. The reasoning had lived in the head of the person who designed the practice. That person was long gone. What remained was the restriction, without the condition that had justified it.

The fix was one conversation: formalize who qualifies to approve, and what it takes to qualify. The bottleneck cleared. The reasoning that had been invisible became structural.

What saddened me about that engagement was not the problem itself. It was the cost of it. This organization had brought in outside help because they could not get traction on a transition, because of bottlenecks they were convinced were structural, because of constraints they could not see past. They had everything they needed to solve this themselves. They just could not step back from the operating system they had organically built and evaluate it from the outside. All I did was name it and facilitate the team’s own correction.

But here is what the sadness does not fully capture.

This was a regulated financial environment. Code review sign-off is not a workflow preference in that context. It is a risk control. Auditors do not want to hear that the process is not documented. They want to see who reviews, how the review is conducted, and how sign-off authority is granted and revoked. This team was running that process entirely on tribal knowledge. If an auditor had walked in during the period when the original architect of the practice had left but the ghost rule was still in force, the answer to “show me your code review authorization policy” would have been silence.

The unwritten rule was not just a bottleneck. It was a compliance exposure that nobody on the team could see, because nobody had written down the reasoning that would have made it visible.

The conventional wisdom on documentation in engineering teams treats it as overhead: administrative work that competes with shipping, process theater that slows teams down. That instinct is not wrong about bad documentation. It is wrong about what documentation is for. The problem is not with documenting decisions. The problem is stopping there.

The what is a record. The why is a system.

Most teams that document at all capture decisions: we require sign-off from senior engineers, we deploy on Tuesdays, we escalate after two missed sprint commitments. A recorded decision can outlive its reasoning without anyone noticing. A documented reasoning cannot. The moment you write “this rule exists because X and should be revisited when Y” you have built a mechanism for the rule to update itself when the condition changes. Without the reasoning, the rule becomes a ghost. It still governs. Nobody can explain why.

That is what the Continuity layer of the LeadershipOS™ framework is designed to prevent: the evaporation of reasoning that turns reasonable rules into invisible constraints. When the reasoning lives in documentation, a future teammate can evaluate whether it still applies, challenge it when circumstances change, and inherit not just the practice but the judgment behind it. When the reasoning lives in one person, it leaves with that person and leaves the rule behind without its justification.

What looks like a workflow bottleneck is usually an undocumented reasoning gap wearing the clothing of a personnel problem. The developers who were not reviewing code were not the problem. The ghost rule governing who could review was not the problem. The absence of written reasoning that would have allowed someone to say “these conditions have changed, this rule needs updating” was the problem. And the only cost of solving it was a conversation that should have been a document years earlier.

Pick one standing practice in your team: a code review rule, a deployment gate, an escalation threshold, an approval requirement. Ask this: if the person who designed it left tomorrow, would their successor know why it exists, not just that it exists? If not, you have structural risk sitting in an individual. In a regulated environment, you are also carrying an audit exposure you may not know about.

The fix is fifteen minutes of documentation: not what the rule is, but why it was created, what condition it was designed to address, and under what circumstances it should be revisited.

The LeadershipOS™ Scorecard measures whether the Continuity layer of your operating system is structural or personal, including whether your decisions and their reasoning are documented where a future teammate could find them. Take it here: https://theleadershiposbook.com/scorecard

---

I write about structural leadership for technical leaders in high-stakes operating environments. If you want to see where your system is load-bearing on you personally, the LeadershipOS™ Scorecard maps it: https://theleadershiposbook.com/scorecard