Process Engineering: rethinking the work, not just speeding it up

Automating versus redesigning

Automating a process makes the current shape faster. Reimagining it asks whether that shape should still exist.

The second usually turns up more, because processes accumulate steps that compensate for constraints which have since gone away.

A review stage that exists because one person could only read so many documents a week. A summary that exists because the people who needed it could not get at the source. A handover that exists because two systems never spoke to each other. A weekly report that exists because there was no other way to know.

Take the constraint away and the step has no reason to be there. It often stays anyway, because it has become how the work is done, and removing something means someone taking responsibility for the removal.

So the more useful opening question is not "what can we automate?" It is "if we designed this today, knowing what is now possible, what would it look like?" Those two questions produce very different answers, and the second usually justifies the investment more.

Describing the work comes first

Answering that question depends on something that is rarely in place: a written description of how the process runs today.

We worked with a marketing team on their brief writing. Once the work was written down rather than discussed, it became clear that around seventy percent of briefs were arriving as reactive messages with no formal intake at all. The interesting problem was never the drafting. It was that there was no front door.

That had gone unnoticed for two years, and not through carelessness. Describing a process and performing it are different skills, and performing it well can hide the problem, because a capable person absorbs the chaos and produces a decent brief anyway.

This is why the description has to come from the people who do the work, and why it helps to write it down rather than talk it through. Talking through a process tends to produce the happy path. Writing it down brings the exceptions into view.

What good and bad look like

Done well, process design starts from the outcome rather than the current steps. It states what finished and correct means, specifically enough to be checked rather than felt. It decides deliberately where a person belongs, which is usually at judgement and approval rather than at retyping. And it plans for failure, because a process that only works when everything goes right will not survive contact with a normal week.

Done badly, it paves over the existing route, complete with the review step nobody needed and the handover that exists because of a system switched off years ago.

The other common failure is the opposite: elaborate structure wrapped around something that was one straight line and needed a checklist. Structure has a cost, and it is paid by whoever maintains it.

Building the competency

The judgement sits with you. Only the people who do the work know which steps carry real thinking and which are habit, what your products and customers actually need, and which parts they would defend if challenged. That knowledge is your IP, and it is the part worth building as a lasting capability in your team.

What you bring in alongside it is acceleration. That means tools that make the work visible, a method for describing and redesigning it, people who have run the exercise many times, and the build capacity to act on what comes out.

Neither half works well without the other. Internal knowledge without the means to act on it stays a list of good ideas. Bought in capability without that knowledge automates the confusion and gets it faster.

Part of the series that starts with The jargon is complicated. The capabilities underneath are simple. Next: Loop Engineering, how complex builds actually get delivered.