Don't automate a process nobody agrees on

We were in a kickoff call to automate an approval workflow. Simple enough on paper: a request comes in, someone approves it, it moves to fulfillment. We asked the two teams involved to walk us through the steps, together, on the same call. That was the mistake, or rather it was the thing that saved the project. Because it turned out the two teams had spent the last three years running two different processes and neither knew it.

Operations thought finance approved requests over a certain amount. Finance thought operations was already checking budget before anything reached them. In practice, some requests got checked twice and some got checked by nobody. Both teams believed the process was working. Both were partly right, which is the worst kind of right.

Software makes disagreement permanent

When a process lives in people's heads, its contradictions are survivable. Two people handle the same case differently and the world does not end, because humans quietly absorb the difference. Someone notices, someone follows up, someone fixes it after the fact. The slack in the system hides the fact that there was never a single agreed process at all.

Automation removes that slack. Code does not improvise. It does the same thing every time, at the speed you built it to run. So if you automate a disputed process, you are not resolving the dispute. You are picking one side of it, usually without realizing you are picking, and then enforcing that choice thousands of times a day with no one in the loop to catch it.

A manual process that is quietly broken degrades slowly. An automated one that is quietly broken fails at scale, on the same day you turned it on.

This is why we push back when a client says the process is well understood and we just need to build it. Sometimes that is true. Often "well understood" means each person understands their own part and assumes the rest works the way they picture it.

Getting to a process everyone recognizes

Before we write code, we get the people who actually do the work into a room, or a call, and have them describe the process step by step out loud. Not the manager's version. The version the people clicking the buttons would recognize. We write it down where everyone can see it and we watch for the moment someone says "wait, that's not how I do it."

That moment is the whole point. It is cheap to find now and expensive to find after launch. What we are listening for is fairly specific:

• Two people describing the same step in ways that cannot both be true
• A step that exists only because of a tool limitation nobody remembers
• A decision point where the rule is really "ask this one person," which is not a rule, it is a person

When we hit real disagreement, we stop and name it. We do not try to average the two versions into something that sounds reasonable. Averaging a dispute usually produces a process that no one actually follows, which is worse than either original.

Sometimes the answer is to fix the process first

Here is the part clients do not always want to hear. Occasionally the right recommendation is to write no software yet.

If a process is genuinely broken, or if the two teams need to make a real decision about who owns what, then automating it now just locks in the confusion. We would rather say so and lose a few weeks of billable work than build something that quietly does the wrong thing and gets blamed on the tool later. In the approval case, we paused the build. The two teams took about two weeks to agree on who checks budget and at what threshold. Then we automated the process they had agreed on, and that build went fast, because there was nothing left to argue about while we were writing it.

The version we shipped was almost boring. One clear path, a couple of well-defined branches, no hidden second opinion. That is what a process looks like once people actually agree on it. The hard part was never the code.

What we actually sell

We think of ourselves as people who write software, and most days that is what we do. But a real part of the job is refusing to build the wrong thing quickly. A team that agrees on its process before we automate it ends up with a system they trust, because the system does what they decided it should do. A team that skips that step ends up with a fast, tireless, perfectly consistent machine for doing something they never agreed to in the first place. We have seen both. We would rather ship the first one, even when it means the first month of the project produces a document instead of a demo.