The Cost of “We’ve Always Done It This Way”

How to understand long-standing processes, protect what matters, and make room for better ways of working.

Some of the most expensive words in business aren't found on an invoice.

They're often much simpler: “We've always done it this way.”

Sometimes those words describe a process that still works beautifully. Sometimes they describe a process that once made perfect sense but has been carrying old assumptions, workarounds, and manual effort forward for years.

The phrase itself isn't the problem. The problem is when familiarity becomes the reason a process no longer gets examined.

‘We've always done it this way’ isn't a reason to keep a process. But it isn't a reason to discard one, either. It's a reason to understand it.

When workarounds become the way we work

Most inefficient processes didn't begin as inefficient processes.

They began as solutions.

A report was created because someone needed information. A spreadsheet filled a gap between two systems. A manual approval was added after an error. A person began checking a field because the system couldn't. A workaround kept the business moving while something else was being fixed.

At the time, those choices may have been exactly right.

Then the organization changed. The workaround stayed.

New systems arrived. Volume increased. Departments grew. Responsibilities shifted. Regulations changed. Customers expected something different. But the process continued, often because it was familiar, reliable, and already embedded in the way people worked.

A process can outlive the problem it was designed to solve.

That doesn't make the original process wrong. It simply means processes need to evolve along with the organizations they support.

The process may still work

There is an important distinction between a process that is broken and a process that could work better.

A long-standing process may still produce accurate results. Customers may still be served. Payroll may still be correct. Reports may still arrive on time. The organization may have talented people who know exactly how to make everything work.

That success can make the process harder to question.

If the result is right, why change it?

Sometimes the answer is that we shouldn't. Efficiency isn't automatically improvement. A new method that introduces risk, reduces accuracy, creates problems downstream, or removes judgment the organization genuinely needs is not better simply because it is newer.

But there is another question worth asking: How much effort does it take to produce that right result?

The process wasn't broken. The question was whether the organization still needed to work that hard to make it work.

When a process depends on extraordinary effort

In one large organization, a payroll employee had managed the payroll process for more than a decade. She had learned it from the person who held the role before her, who had performed the work for more than twenty years.

The process worked. People were paid accurately, deadlines were met, and the employee knew every detail of the work.

It was also highly manual.

Printed reports were reviewed line by line. Different colored highlighters were used to identify different types of payroll activity. A series of specific manual review and verification steps had been developed and refined over many years.

As the organization grew, so did the amount of work required to maintain the process. The person responsible for it worked increasing hours and found it difficult to step away during payroll cycles.

People can hide process problems by working harder.

From the outside, the process still appeared successful because the result remained successful. The growing cost was being absorbed by the person doing the work.

Eventually, another experienced person learned the process so payroll could continue while the employee was away. In doing so, several manual steps were identified that the existing system could perform automatically.

The automation was intentionally designed to preserve the existing result. Even the familiar color coding remained: the system used payroll codes it already knew to apply the appropriate visual distinctions automatically.

The final report looked almost the same.

The effort required to produce it didn't.

That one change eliminated roughly an hour of manual work each payroll cycle, and other automations removed additional hours while preserving the same intended outcomes and controls.

When the employee returned, she strongly preferred the familiar manual process and asked for the automation to be removed.

It would be easy to frame that response simply as resistance to change. But that misses something important.

For more than a decade, the employee had been personally responsible for making sure people were paid correctly. The process she knew had worked. Its steps were familiar. Its controls were trusted. A different method—even one designed to produce nearly the same result—did not yet carry that same history of trust.

Sometimes the people most burdened by a process are also the people most protective of it.

That isn't criticism. It's something organizations need to understand when improving long-standing processes.

Separate the business need from the method

Stories like this are why process improvement should not begin with the assumption that old methods are foolish—or that new methods are automatically better.

The better starting point is to separate what the business needs from how the work has traditionally been performed.

What must be accurate? What must happen by a certain time? What controls must exist? What information must be produced? Who uses it? What exceptions require human judgment? What risk is a particular review intended to prevent?

Once those requirements are understood, the organization can ask a different question:

If we were building this process today to meet those requirements, how would we build it?

Perhaps the answer is nearly the same as the current process. Good processes deserve to be protected.

Perhaps the business still needs the control but no longer needs the manual method used to perform it. A date stamp may represent an audit trail. A manual mark may represent validation. A spreadsheet may be compensating for information that another system already knows.

Preserve the purpose. Reconsider the method.

The goal isn't to eliminate steps simply because they are manual. The goal is to understand what each step accomplishes and determine whether the organization still needs to accomplish it in the same way.

Ask the people doing the work—but ask a different question

One of the best sources of process knowledge is usually the people closest to the work.

They know where exceptions occur. They know which steps take longer than they should. They know which reports are actually used, where information goes missing, and what happens when something goes wrong.

But there are times when familiarity with a process makes it difficult to imagine the work without it.

The people closest to the work often understand the business need better than anyone. Familiarity can also make it difficult to imagine a different way to meet it.

In those situations, asking, “How would you change this process?” may not reveal very much. The answer may naturally stay within the boundaries of the process as it already exists.

Instead, ask what the business needs the process to accomplish.

What are you checking for here? What could go wrong if this step disappeared? Why do you need this information? Who needs the result? What happens next? Which situations require your judgment? What do you wish you had more time to focus on?

Those questions preserve the expertise of the people doing the work without assuming that every inherited step must remain part of the solution.

Then fresh perspective can be added—not as criticism, but as curiosity.

Familiarity has value

Organizations should not underestimate the value of familiarity.

A process someone has used successfully for years carries trust. People know what to expect. They know where problems tend to appear. They know how to recover when something unusual happens.

A new process may be faster and still feel riskier because it has not yet earned that trust.

Familiarity has value. But familiarity and necessity are not the same thing.

Good process improvement respects that distinction. It does not dismiss experience. It uses experience to understand what matters, then determines whether there is a better way to protect it.

Respecting the people who built and maintained a process doesn't require preserving every step of the process forever.

Look at the process with fresh eyes

Fresh eyes are valuable precisely because they do not carry every assumption embedded in the current process.

Someone new may ask why a report is printed when the information already exists electronically. Why the same data is entered twice. Why three approvals are required. Why one department recreates information another department already has. Why a person spends hours applying a rule the system could apply consistently in seconds.

Those questions are not accusations.

They are opportunities to understand how the process evolved—and whether every part of it still serves the organization today.

Not as criticism. As curiosity.

Sometimes the answer will reveal a control that absolutely needs to remain. Sometimes it will uncover a workaround nobody realized was still there. Sometimes it will expose a business rule that belongs in the system. Sometimes it will reveal that a process is already quite good.

The objective isn't change. The objective is better.

Keep what works; question what doesn’t

Process improvement does not require tearing everything apart.

In fact, some of the best improvements are remarkably practical: automate a repetitive step, capture information earlier, eliminate duplicate entry, simplify an approval, connect two systems, clarify ownership, remove a report nobody uses, or document a rule that currently lives in one person's head.

The important thing is to distinguish between what is essential and what is simply inherited.

Some practices are old because they are good.

Others are old because nobody has had the time, authority, perspective, or reason to question them.

Don't confuse preserving an outcome with preserving every step that historically produced it.

Think about a process in your organization that has existed for years. Perhaps it works. Perhaps everyone knows it. Perhaps one or two people are exceptionally good at keeping it running.

Then ask:

Does this process work because it is well designed—or because someone is working extraordinarily hard to make it work?

What problem was the process originally designed to solve? Does that problem still exist? What must be protected? Which controls still matter? Which steps exist because of an old system, an old organizational structure, or a workaround that became permanent? Where is human judgment valuable? Where could the system reliably do more?

And finally:

If we understood everything this process needs to accomplish but weren't constrained by how it has always been done, how would we build it today?

Sometimes the answer will be: almost exactly this way.

Sometimes it won't.

Either answer is useful—because the organization is making a conscious choice rather than allowing familiarity to make the choice for it.

The goal isn't to replace an old process with a new one. It's to make sure the process we use today still solves the problem the organization has today.