Don’t trust the Process™

Why you should never *set out* to build a process

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” – John Gall, Systemantics

If you only take away one thing from this piece, let it be this request — tear down every process that isn’t based on a strong understanding of what makes the work successful. 

I keep seeing this.

Process is safety. It promises security that things will happen at certain times, that there won’t be any surprises, that everything that needs to be done will be done and everyone involved will know what to do. 

And in the right context, that’s beautiful. Picture an orchestra, or a football team, or the Philadelphia 76ers (if you know, you know). Great process can create great work on a repeatable schedule, and the teams that crack it have an incredible advantage. 

But the absolute crux of process is that it improves efficiency.

Process takes a method that has demonstrated it can produce results and standardizes it, so that it can produce results over and over again — even if elements of the team change or unexpected challenges pop up. 

Process increases efficiency by standardizing things. Standardizing things doesn’t make sense if you don’t yet know what the standards should be. 

The factory’s ready! We’ve got conveyer belts and choppy machines and grabby robots and all the other gadgets. Now, what should we manufacture?

Never create process before creating successful work. 

I keep seeing people want to design these complex systems and workflows to handle a task that’s never been done before. 

“We want to get partners to market our business. Here’s when we’ll ask Ashley to find the partners, here’s when we’ll put the partner in contact with the rest of the team, here’s when we’ll review what the partner has produced, and here’s the super detailed project management workflow I’ve built to keep track of the whole thing.”

Ok, but what happens when…

• Ashley is busy and doesn’t reach out to the partner right away

• The partner doesn’t respond

• The partner responds, but then stops responding and you never hear from them again

• The partner responds, and keeps responding, but the work they produce is terrible

• Your team gets pulled into other stuff, and is forced to keep the partner waiting

• An executive sees something a partner produced (that you approved) and hates it, threatening to bring the whole thing down

• The process runs absolutely perfectly, like a performance of the Rite of Spring, but gets absolutely zero results for the business

Just one example, but the underlying idea is everywhere — instead of building an entire giant system with assumptions that you don’t even realize are assumptions…

...go make it work once. 

Find one partner. Hold their hand through the whole thing. Measure the results. You’ll learn more from this than from hours (really: weeks) spent building a process that wobbles the first time you encounter something you didn’t anticipate. 

What happens if you build process first? Almost definitely the process is wrong and huge chunks of it have to be scrapped. You will never be able to pre-design for every contingency, and trying to is like building a giant factory that has tons of equipment you don’t need — and is still missing that one machine that you can’t do without.

Process makes existing work more effective. But it can’t create effective work on its own.

The original purpose of a hierarchy is always to help its originating subsystems do their jobs better. This is something, unfortunately, that both the higher and the lower levels of a greatly articulated hierarchy easily can forget. Therefore, many systems are not meeting our goals because of the malfunctioning hierarchies. – Donella Meadows, Thinking in Systems

Process exists to make the system more efficient. It only makes the system more effective (i.e. produces better results) by increasing the efficiency of something that is already effective. 

Why do terrible, ineffective, bureaucratic, hair-pulling processes exist then? Why is it so many people’s first instinct, on facing a new problem, to create an elaborate Trello workflow and assign deadlines that no one will admit are arbitrary? 

Because process is seductive. Because it promises predictability. Because it banishes uncertainty. Because it creates the illusion of knowing what will happen tomorrow, or next week, or next quarter. 

But it’s a lie. As blatant a lie as any politician, or a kid who definitely brushed their teeth, you betcha.

Process for process’ sake can’t make things not go wrong — it just says that if things go wrong, they won’t go wrong in these very specific ways that the process solves for. If the process is poorly constructed, everything can and will go wrong in all of the other available ways.

I’ve had people who love process try to commiserate with me as someone who also loves process. Except, I hate process. I love systems. Process as part of a working system is beautiful. Process on its own should never be praised.

If your first instinct is to create a process to solve a problem, stop. Solve the problem first (once), and then create process one step at a time, each time tackling the thorniest, messiest problem you encounter. You will end up with a process every bit as complex — and probably more complex — than the one you would have designed from scratch. 

Except that it will actually work.