A workflow describes a sequence: this happens, then this, then this. It's useful, and it's usually the first thing anyone draws when they want to improve an operation.
But a workflow is only part of the picture. The system includes everything that sequence needs in order to succeed: the people doing each step, the information they depend on, the technology connecting them, the timing that matters, who owns each transition, the exceptions, the feedback, and the consequences downstream.
Where the failures hide
Operational systems can look like they're working while failures happen between the steps. The process exists. The technology works. Each department believes its part is being handled. And yet information arrives late, ownership is unclear, or a record falls between two systems where no single application can see it.
None of that shows up on the workflow diagram, because the diagram only shows the boxes. The failures live in the arrows.
Optimizing a step can move the problem
Take a simple recruiting pipeline: find candidates, make contact, screen, schedule, hand off to a recruiter. Say outreach is slow, so we automate it and contact twice as many people. If screening could only handle a fixed number a day, nothing improves at the end of the pipeline. We've built a bigger queue in front of the screen.
Speed up screening next, and the constraint moves again, maybe to scheduling. Each change can be a good piece of engineering and still do nothing for the outcome, because the outcome is set by the system, not by any one step. There's a small version of this you can click through.
Questions I ask at every boundary
So before I change a step, I look at the boundaries around it:
- What happens upstream, and what does this step depend on?
- What happens downstream, and what does it hand off?
- What information crosses the boundary, and in what state?
- Who owns the transition?
- What can fail here, and how would that failure become visible?
The last question is the one most often skipped. A system that fails quietly is worse than one that fails loudly, because nobody knows to fix it.
The objective isn't to automate a task. It's to improve the system.
Sometimes that means automating a step. Sometimes it means giving someone better information at the right moment, making ownership explicit, or changing the order things happen in. You only know which once you've looked past the workflow to the system around it.