Why "it's always been done this way" survives automation

Businesses automate processes expecting the automation to also settle the question of why the process works the way it does. It doesn't. Automation captures the steps faithfully — often more faithfully than the manual version, which had drifted over time — but it inherits the steps without inheriting the reasoning behind them.

Automation is a very good copier and a poor historian

When a manual process becomes a workflow in the system, what gets encoded is the sequence: this approval happens before that one, this field triggers that notification, this threshold routes to a different approver. The system will now execute that sequence exactly, every time, without fail.

What doesn't get encoded is why the sequence is that sequence. Why does this approval happen before that one? Because two years ago, skipping it once caused a costly mistake, and someone added the step afterward. That story doesn't automate. Only its consequence does.

Why this creates a strange kind of rigidity

Before automation, a slightly wrong or outdated step could be quietly worked around by whoever was doing it manually — a small human correction nobody wrote down. After automation, the system executes the step exactly as configured, correctly or not, and there's no longer a human in the loop to notice it's slightly off.

This means automation can accidentally freeze an outdated practice in place, executing it with new reliability precisely because reliability was the point of automating it in the first place. The step that used to be quietly adjusted by an experienced staff member now runs unmodified, forever, until someone deliberately goes back and questions it — which requires knowing there's something to question, which requires the reasoning that didn't survive the migration.

Where this shows up

A workflow step nobody can justify, but nobody wants to remove. It runs, it's automatic, it costs nothing visible to keep. Removing it requires confidence that it's actually unnecessary, and that confidence requires the original reasoning, which is exactly what's missing.

Migrating to new software inherits old logic uncritically. Moving from one system to another is often treated as a technical exercise — replicate the workflows, keep the business running. It's rarely treated as an opportunity to ask which of those workflows still make sense, because asking requires reasoning that usually wasn't carried across either.

New hires learn the automated process and never learn the "why." They're trained on what the system does, not on the history that produced it — see why a new hire's first three months are spent asking why. The workflow becomes something to operate rather than something to understand.

The moment worth using deliberately

Any time a process is being automated for the first time, or migrated between systems, is a rare, natural opportunity to capture the reasoning — because at that exact moment, someone has to sit down and articulate every step anyway, in order to configure it. That articulation is normally thrown away the moment the workflow goes live. It doesn't have to be.

Write down the "why" for each step while you're already writing down the "what," during configuration. The marginal cost is small — you're already in the process, already talking to the people who know it — and the alternative is trying to reconstruct that reasoning years later, from people who may no longer be around.

Treat migration as a review, not just a copy. Before carrying a workflow into a new system unchanged, ask whether anyone can currently explain each step. A step nobody can justify is worth questioning before it gets automated permanently, not after.

Build in a scheduled review of automated workflows, the same way you would for manual ones. Automation doesn't remove the need to periodically ask whether a process still makes sense — it just removes the natural human friction that used to prompt that question on its own.

Common questions

Does automating a process capture the reasoning behind it?

No. Automation captures the sequence of steps faithfully, but the reasoning for why each step exists is a separate thing that doesn't automatically transfer. Only someone deliberately writing it down at the time of configuration preserves it.

Why can automation make an outdated practice harder to fix, not easier?

Before automation, an experienced person doing a process manually could quietly work around a step that no longer made sense. After automation, the system executes that step exactly as configured, with new reliability, and there's no human in the loop to notice or adjust it — freezing the outdated practice in place.

When is the best moment to capture the reasoning behind a workflow?

At the point of configuring or migrating it, since that's when someone already has to articulate every step in order to build it. Writing down why alongside what, at that moment, costs very little compared to trying to reconstruct the reasoning years later from people who may have moved on.

Should automated workflows be reviewed periodically?

Yes, in the same way manual processes should be. Automation removes the natural friction that used to prompt someone to question an outdated step, so a scheduled review has to replace that friction deliberately, or outdated logic simply runs unquestioned indefinitely.

Related: why a new hire's first three months are spent asking why · configuration without a reason attached · what a system of record cannot do