The Problem With "We've Always Done It This Way"
Six words. Eleven syllables. An entire organizational immune system contained in a single sentence. "We've always done it this way" is the phrase that has protected more outdated processes, more inefficient workflows, more security risks, and more wasted labor hours from examination than any policy or governance framework ever written, because it does not arrive as a defense. It arrives as a fact, delivered with the quiet confidence of something that has simply never been questioned, and the thing about facts is that questioning them requires a certain kind of organizational courage that not everyone has developed or been given permission to exercise.
The processes that have been in place the longest are not necessarily the ones that are working best. They are the ones that were implemented by someone with enough organizational capital to implement them, during a period when they represented a reasonable solution to a problem that may or may not still exist in the same form. The manual monthly reconciliation process that made sense when the organization had one system of record makes considerably less sense when there are seven systems and an integration layer that could automate the comparison in real time. The approval chain that was designed for a team of twenty has been applied unchanged to a team of two hundred, with predictably different results. The security policy that was written for an on-premises environment has been extended to cover a cloud-first environment through a series of addenda that collectively resemble a palimpsest rather than a coherent framework.
The challenge of process improvement in established organizations is not identifying which processes should change. A moderately attentive IT professional can generate that list on a slow afternoon. The challenge is creating the organizational conditions in which the question "why do we do it this way" is treated as a legitimate inquiry rather than a veiled criticism of whoever implemented the process in the first place. Organizations where that question is safe to ask have a significant advantage in operational agility over organizations where it triggers defensiveness, because the organizations where it is safe to ask are the ones that actually answer it. And answering it, honestly, sometimes reveals that there was never a particularly good reason and the process persists entirely on institutional inertia.
The most effective process improvement initiatives are not the ones that arrive as top-down mandates to modernize everything simultaneously. They are the ones that start with a specific, concrete, measurable inefficiency and follow the thread from there. The seventeen-step offboarding process is a target. The manual data entry that takes three hours every Monday is a target. The approval workflow that routes through six people for decisions that three of them have no context for is a target. Each one of these has a history, and the history is worth understanding before changing the process, because sometimes "we've always done it this way" contains a genuine reason that is not immediately visible. The security step that looks redundant is compensating for a gap in a system that nobody documented. The manual check that looks like busywork is catching an error that the automated system misses. Understand before you automate. Automate after you understand.
The goal is not to eliminate organizational memory or dismiss the value of established practice. It is to distinguish between processes that persist because they are genuinely working and processes that persist because nobody has ever had the focused attention, the permission, or the tools to examine them. The former deserve respect. The latter deserve a process map and a very honest conversation. Both deserve the question.
