Deference

A new leader was meeting with department heads.  “Why does this part of the process work this way?” A straightforward question, not a challenge, nor a reorganization threat.  This was just a genuine question from someone encountering the workflow for the first time, trying to understand the logic behind a step that was creating visible bottlenecks and showing up consistently in customer complaints.

The people across the table had been running the process for years. They knew every part of it, every workaround, every place where things slowed down and why. They had never been asked, at least not directly, why the process had been built to flow the way it did.

“[Name] developed this process…”.  Instead of starting with the function, the explanation started with a person.  The process had been designed by someone who knew the operation deeply, had credibility across the organization, and had built a lot of things that worked. That history mattered enough over time that the process itself had inherited credibility by association. When things slowed down or customers flagged issues, the team’s response was generally to absorb the friction rather than examine the design. Questioning the design felt like questioning the person who created it, and that wasn't a conversation anyone wanted to start.

The explanations continued. The new leader listened, asked a couple of follow up questions, and then said “Tell me the original reasoning behind the specific step causing the bottleneck.”

Silence, followed by an admission, “We’re not sure”. The reasoning wasn't something that had been written down. It had lived with the person who designed the process, it made sense within the operating context at the time, and it left when they did. What remained was the process structure itself, and the institutional understanding that it existed because someone capable had built it. That had been enough to keep it in place, absorb the workarounds it required, and justify it to anyone who asked.

This is how organizational memory fails in practice. Not in a single moment of loss, but gradually, as the reasoning behind decisions detaches from the decisions themselves. The process stays, but the rationale doesn't. What fills the gap isn't documentation or institutional knowledge.  It's deference. Deference to a reputation, to a tenure, to the weight of that person’s history in the organization. It functions well enough, right up until someone arrives who doesn't share that history and asks why.

The customer complaints didn't start when the original designer left. They had been accumulating quietly for some time, absorbed into the category of "how things work here" rather than examined as evidence that something in the design wasn't working correctly. The new leader's question didn't create the problem, but it made continuing to avoid the answer considerably harder.

Most organizations have at least one version of this. A process, a structure, a decision that gets explained by invoking the person who made it rather than the reasoning behind it. The name does the work the rationale should be doing. It's a reasonable shorthand until the name no longer carries enough weight in the room to justify the answer.

The dual exposure here is worth contemplating. For the person doing the explaining: when was the last time you were asked why something works the way it does, and realized the answer you had was a name rather than a reason? For the organization: how many processes are currently running on deference, and what happens when someone arrives who doesn't share it?