Designed by Someone Who Doesn’t Do the Job Anymore

Somewhere in most organizations there’s a workflow that was designed by someone who was excellent at the underlying job, back when they were still doing it directly. That person has since moved into management, switched teams, or left the company entirely, and the workflow they built has continued running largely unchanged, followed diligently by people who never got to weigh in on it and who quietly know, from doing the job every day, that a few steps no longer make much sense. It persists anyway, because changing an established workflow feels riskier than following one that merely feels a little wrong.

Workflows Encode a Snapshot of How Work Used to Get Done

A workflow built by a skilled practitioner reflects real, hard-won expertise, but it also reflects the specific conditions of the job at the moment it was designed: the tools available then, the volume of work then, the edge cases that mattered most then. Work rarely stays that static. Tools change, volume shifts, the mix of cases a team actually handles evolves — and the workflow, unless someone actively revisits it, keeps encoding the original snapshot regardless of how much the underlying job has moved on since.

Why the People Doing the Job Now Rarely Change It

The people currently executing a workflow every day are usually in the best position to notice where it’s stopped fitting reality, and they’re usually the ones least empowered to actually change it. The workflow often belongs, at least informally, to whoever designed it or to whoever currently manages the function, and a frontline practitioner questioning a specific step risks looking like they don’t understand why it’s there, especially if the step’s original rationale isn’t documented anywhere for them to check against. It’s often easier to keep quietly working around an awkward step than to raise the question of whether it still belongs.

Signs a Workflow Has Outlived Its Designer’s Context

Signal	What it usually means
A step exists that nobody currently on the team can explain	It solved a problem specific to a past situation
Practitioners have developed informal workarounds for a specific step	The formal workflow no longer matches how the work actually gets done
New hires are told “just do it this way, don’t ask why”	The rationale was never documented and has since been lost
The workflow assumes a tool or volume the team no longer has	It’s calibrated for conditions that have since changed

Each of these signals is easy to miss individually, since workaround habits and unexplained steps tend to feel normal to people who’ve never known the workflow any other way.

Reopening a Workflow Without Disrespecting Its Origins

Revisiting a workflow that a well-regarded former practitioner built can feel like second-guessing someone who genuinely knew what they were doing, especially if that person is still around in some other capacity. The useful reframe is that a workflow built for one set of conditions being outdated under different conditions isn’t a criticism of the original design — it’s simply what happens to any workflow given enough time and change. Treating a review as normal maintenance, not as a verdict on the original designer’s competence, makes the conversation far easier to have honestly.

Asking the People Who Actually Run It Today

The most direct way to find where a workflow has drifted from current reality is asking the people executing it now, specifically and individually rather than in a group setting where deference to the original design might suppress honest answers: which step do you find yourself working around, and why? This single question, asked genuinely and followed up on, usually surfaces more actionable insight than a formal process review conducted by someone once removed from the daily execution of the work.

Rebuilding the Rationale Before Changing the Steps

Before changing a workflow step that seems outdated, it’s worth trying to reconstruct why it existed in the first place — sometimes through documentation, sometimes by asking the original designer directly if they’re reachable. Occasionally a step that looks obsolete turns out to guard against a rare but serious edge case that hasn’t occurred recently only because the step has been quietly preventing it. Removing a step without understanding its original purpose risks reintroducing a problem the original designer solved, even if the everyday friction of following it no longer feels justified.

Assigning Ongoing Ownership, Not Just a One-Time Fix

A workflow review that happens once, fixes the current drift, and then sits untouched for another several years just recreates the same problem on a longer timeline. The more durable fix is assigning explicit, ongoing ownership of the workflow to someone currently doing or closely overseeing the work — not necessarily the original designer — with a standing responsibility to periodically check whether it still matches reality. This turns workflow maintenance into a continuous, low-effort habit rather than an occasional, disruptive overhaul that only happens once enough frustration has accumulated to force it.

Treating the Original Design as a Foundation, Not a Monument

A workflow built by someone skilled deserves respect for the expertise it encoded, but respecting it shouldn’t mean treating it as permanently fixed regardless of how much the underlying job has changed since. The workflows that stay genuinely useful over time are the ones treated as living tools, actively maintained by whoever is closest to the current work, rather than monuments preserved out of deference to whoever happened to build them first.

When the Original Designer Is Still Around

An interesting variant of this problem occurs when the original designer hasn’t left the organization but has simply moved into a role removed from daily execution — a manager, a director, someone consulted occasionally but no longer doing the work firsthand. In this case, the designer often still feels strong ownership over the workflow and may resist changes more actively than if they’d left entirely, since the workflow remains associated with their reputation and expertise. Handling this well usually means involving them in the review as a valued source of historical context rather than as the final authority on whether a change should happen — their institutional knowledge is genuinely valuable for understanding why a step exists, even if their current distance from the daily work means they’re not best positioned to judge whether it’s still needed.

Building Rationale Into the Workflow From the Start

The easiest way to prevent this entire problem from recurring with the next workflow a team builds is capturing the reasoning behind each step at the time it’s designed, not just the step itself. A workflow document that includes a brief note on why each step exists — what problem it solves, what would happen without it — gives future practitioners something the current generation of outdated workflows almost never has: enough context to judge confidently whether a step still matters, rather than having to guess or leave it untouched purely out of caution. This small addition at design time saves considerably more effort later, when someone eventually has to reconstruct that same reasoning from scratch, often without the original designer available to ask.