We've Always Done It This Way
Tradition carries vital experience forward. But when routine becomes its own justification, organizations stop learning and start executing legacy code.
There is a single phrase in modern professional life that has always raised an immediate red flag for me: "We've always done it this way."
At first glance, it sounds harmless — maybe even reassuring. Experience matters. Workflows exist for a reason. Not every new tool or alternative methodology deserves to replace a battle-tested operational stack. But there is a significant structural difference between having a reasoned process and simply repeating a habit, and that difference is what the phrase almost never tells you.
Whenever I ask why a system or workflow is configured a certain way, I'm not trying to be difficult or criticize the engineers and teams who laid the foundation before me. I want to understand the underlying architecture. If there is a solid technical or operational reason for the design, that reason is worth learning. And if there isn't — that is worth discovering.
The Three Answers
The best leaders and engineers I've worked with never feel threatened by that diagnostic question. They welcome it. And when you ask why, the response almost always falls into one of three categories, each of which tells you something specific about the organization you're standing in.
The first is the experienced answer: "We tried another approach last year and it caused critical integration issues down the pipeline." This is the response worth its weight. It means the process has been tested, the failure points are understood, and the people running the system have actually thought about it. Now the constraints are visible and the design makes sense.
The second is the transparent answer: "Honestly, I don't know." This one earns immediate respect, because it signals a willingness to audit the process together rather than defend it reflexively. An organization where people can say "I don't know" out loud is an organization still capable of learning.
The third is the defensive answer: "Because that's just how we do it here." This is the red flag — not because the process is necessarily broken, but because no one on the team can explain why it was built in the first place. At some point the original intent disappeared, leaving behind nothing but an unexamined routine running on institutional momentum.
When Curiosity Becomes Inconvenient
Before treating every "we've always done it this way" as a failure, it's worth being honest about when leaving a process alone is actually the right call.
Some workflows exist because the organizational memory that produced them has retired, the documentation was never written, and the only evidence that the process is correct is that it hasn't failed yet. Auditing it requires reconstructing decisions that were made under constraints no one currently remembers, and the cost of getting that reconstruction wrong can be higher than the cost of leaving the process intact. There is also a real organizational tax on constant process questioning — teams that relitigate every established workflow every time someone new arrives can be just as dysfunctional as teams that never question anything. The instinct to understand why something works the way it does is healthy. Treating every inherited system as a problem to be solved before you've learned what problem it was solving is a different thing entirely.
The diagnostic question worth asking isn't "why are we doing it this way?" in isolation. It's "does this process still solve the problem it was designed for?" If the answer is yes — if the design is grounded in safety, efficiency, data security, or user experience that has been tested and holds up — it is a process worth defending, even if the institutional memory behind it is thin. If the answer is "we're not sure what problem it was solving" or "the problem it was solving no longer exists," then the process deserves a second look regardless of how long it has been running.
Organizations don't stop innovating because they run out of creative ideas. They stop innovating when curiosity quietly becomes an administrative inconvenience — when asking diagnostic questions is interpreted as insubordination, and employees learn it is far safer to follow a checklist than to understand the system beneath it. That is the moment technical and operational debt begins to compound. Improvement stalls not because people stop thinking, but because the environment stops rewarding them for it.
Good leaders recognize that an employee who understands why a system exists can optimize it, teach it, adapt it, and recognize the moment it no longer fits the problem at hand. An employee who only knows what button to press can only repeat the loop until it breaks. That distinction extends well beyond software and corporate workflows — it applies to schools, local governments, communities, and families. The scale changes. The principle holds.
Wisdom can explain itself. Habit cannot.
Some of the greatest breakthroughs in any field didn't start with a brand-new invention. They began with someone asking the question everyone else had stopped asking: why are we doing it this way, what problem was this originally solving, and is there a cleaner path forward? Questions like those don't disrupt an organization. They protect it.
Because the moment a system can no longer explain why it operates the way it does, it has already begun to forget where it is going.