How to find the steps in your flow that shouldn't be there (no code required)

The steps that shouldn’t be in your flow aren’t found through formal audits: they’re found by sitting down with the person who runs the flow every day, a shared screen with the real system, and a recent case with some minor friction. For 45 to 60 minutes you ask them to walk through the flow step by step, narrating each action, and at every non-obvious step you ask one question: why does this step exist? The three most frequent answers — “because we’ve always done it that way”, “because a customer who isn’t a customer anymore asked for it”, “because the old system needed it” — signal the step is a candidate to eliminate. Three errors kill the exercise: interviewing the manager instead of the operator, doing it on an ideal case with no exceptions, and promising nothing will change. Eliminating flow steps isn’t a technical problem, it’s a permission problem.

That’s step 1 of the Zero Friction Method: eliminate. It’s by far the most underrated step, and the one that unlocks the most value relative to the work it requires.

It’s worth explaining why it works, how to do it, and what happens when you do it wrong.

Why it works

Operational flows in companies with fifteen or twenty years of history accumulate every decision that was ever made and never reversed. An important customer asked in 2018 for an extra field on the invoice. An external audit required a double validation in 2020 that made sense in that audit’s context. An old supplier had a system that needed a specific format and, even though that supplier isn’t a supplier anymore, the format is still there “just in case.”

Each of those decisions, taken on its own, was reasonable. The sum, seen fifteen years later, isn’t. But nobody has an incentive to remove them. The person who introduced them isn’t around. The person who runs them every day assumes they exist for a reason. The general manager doesn’t go down to that level of detail. The result is a flow whose perimeter nobody questions.

The honest audit conversation is what breaks the loop. When you ask, step by step, “why does this step exist?”, what shows up isn’t resistance. Three answers show up, on repeat:

“Because that’s how we’ve always done it.” The most common one. Means nobody alive in the organization actively defends the step.
“Because a customer used to ask for it, and they’re not a customer anymore.” Or a supplier, or an audit, or a system. The original cause is gone; the step isn’t.
“Because the old system needed it.” The integration with an ERP that got swapped six years ago, a validation that no longer applies, a field nobody consumes.

All three answers share a property: none defends the step from its present value. They defend its origin, not its usefulness. That’s the green light.

How to do it, concretely

The protocol is direct and reproducible. You need:

One team member who runs the flow daily. Not the manager who describes it in a steering committee meeting, the person who actually clicks.
A shared screen with the real system. Not a flow slide, not a Visio diagram. The system screen, live.
A real recent case. A real order, a real invoice, a real incident. Nothing made up.
One uninterrupted hour.

The session starts by asking this person to run the flow from the beginning, slowly, narrating each action. Every time a non-obvious step appears, you ask one question: “why does this step exist?”

You don’t interrupt the flow. You write down the answer and keep going. At the end of the session, what you have is a list of steps with their justifications, groupable into three categories:

Steps whose justification is present and robust. They serve something the organization values today. They stay.
Steps whose justification is historical. They made sense and don’t anymore. Candidates for elimination after a cross-check with the functional owner, five minutes per step, no more.
Steps whose justification is non-existent. Nobody knows why they’re there. Immediate elimination, no reasonable risk.

In sessions like this, categories 2 and 3 combined typically represent a meaningful portion of the flow, usually more than the team expected. That realization is what opens the real operational conversation, before talking about technology.

What happens when you do it wrong

Three frequent mistakes kill the exercise before it produces value.

The first mistake is interviewing the manager, not the operator. The department director describes the flow as they think it should work, not as it works. The steps invented in that description are different from the steps that show up on screen. The exercise serves strategic diagnostic, but not concrete elimination. The session has to be done with the person who executes.

The second mistake is doing it on an ideal case. “Let’s see how we process a normal order.” Normal orders don’t have exceptions, and exceptions are what generate half the inherited steps. The session is done on a recent real case that had some minor friction. That’s where the defensive steps show up, the redundant validation steps, the “just in case” steps that are most eliminable.

The third mistake is promising nothing will change. “This is just to understand, we won’t touch anything yet.” That promise turns the exercise into a polite interview where the operator justifies everything they do. The right promise is the opposite: “We’re going to remove every step that neither of us can defend, after reviewing it with the functional owner.” That changes the attitude.

Permission, not technique

Eliminating steps from a flow isn’t a technical problem. It’s a permission problem. Once the steps without present justification are identified, what’s missing isn’t code or tooling, it’s the organizational decision to remove them. That decision is always at director-of-operations level or equivalent, and almost always available: the director already suspected they were redundant, what was missing was the document that proved it.

The document delivered after the session isn’t a consulting report. It’s a table with three columns: step, justification gathered, recommendation. Three pages, plain language, no jargon. The director signs or doesn’t sign each removal. When they sign, it’s executed that same week. When they don’t, the reason is documented to revisit in six months.

When the flow weighs half, everything that comes after starts from a cleaner foundation. Step 2 standardization works on fewer cases. Step 4 automation covers fewer steps. And step 5 AI, when it arrives, runs on a process that makes sense, not one dragging fifteen years of decisions nobody defends.

When was the last time someone on your team, sitting next to whoever runs your most expensive flow, asked them step by step “why does this step exist?”

If your company wants to walk through this exercise on a concrete flow, the 2-week operations roadmap includes it as a session in the first week. We come out with the flow mapped and the list of removable steps signed by the functional owner.