Your Process Is a Rube Goldberg Machine

Stop adding steps. Start designing workflows that actually work.

Think of a Rube Goldberg machine: a chain reaction of levers, pulleys, and dominoes designed to accomplish a task that could be done with a single switch. Every added step introduces a new potential failure point. The more steps we have, the more likely that something will go wrong and the whole system will fail. Yet, when facing a new challenge in managing the team, our first instinct is to add more process: an approval gate, a new state in Jira, a new alignment meeting.

Before we dive in: I’m Roman, CTO at a startup, and I write High-Impact Engineering — a weekly newsletter for engineering managers, directors, and CTOs.

This issue explores why complex processes fail and how to fix them.

Generated with ChatGPT

KISS your process

KISS is a well-known principle in engineering. Keeping the systems we built as engineers simple is a key skill for an engineer.

Experienced engineers know that building a complex system is easy and building a simple one is hard. We all build our share of Goldberg’s machines. At the time when you are building it, it looks logical and common sense. Let’s add a global state here, a database trigger there, and then a circular dependency between these three things, because it is faster.

It might even work, but then the already complex system needs to be maintained and extended.

My way of catching this complexity can be described by a phrase

I am not that smart.

It means that when I build something, and then I start feeling that I am having trouble keeping up with the mental model of everything that happens in the system, I stop.

I start thinking if I outsmarted myself, and the thing that I am building is now so complex that I start to lose the mental model of all the details. If the answer is yes, it means that I built something smarter than me. I created a monster!

If it is the case, I return to the drawing board and start simplifying. Until I end up with something that I totally understand and can manage.

The same principle applies to the process design.

As a single person, it is easy to design a multi-step process that involves several actors perfectly executing their own part and passing the work forward.

Alice - Product Owner, Bob - Designer, Carol - Software Engineer, Dylan - QA - work on a ticket, passing it forward to completion. Bob and Alice work on a ticket, Carol implements it, Dylan verifies, and then Alice validates the desired behaviour. Simple. Or is it?

Someone forgets to move a ticket or update a field. Someone finishes their part and is supposed to update the documentation, but it does not happen. The documentation gets misinterpreted, and the next step gets executed incorrectly. As a result, we end up with a broken feature in production.

Organizations, even consisting of extremely smart people, are dumb.

It is easy to blame people for not following the process. But let’s be clear: it’s rarely the people who are broken.

When we design workflows that rely on perfect memory, flawless timing, and constant coordination we engineer failure into the process from the get-go. Complex processes don’t expose human weakness. They create it.

Before throwing more process onto the broken process, it is a good idea to go back to the drawing board and look at the root cause.

Do we rely too much on each person performing their own step flawlessly?

Ownership

Goldberg’s machine does not have a supervisor. If one of the dominoes doesn’t fall at a proper speed and angle, the chain reaction stops. I have been in many cross-functional projects with no owner. It usually ended up with a lot of confusion about who is doing what, and why things don’t move. A project manager, a scrum master, a tech lead — someone needs to coordinate the parties, track dependencies, remove blockers, and ensure deliverables actually cross the finish line.

Without explicit ownership, complex processes fragment. Tasks get dropped, assumptions go unchallenged, and “orchestration” becomes everyone’s responsibility and no one’s. When complexity creeps in, a clear owner is the only thing that keeps the machine from grinding to a halt.

Ownership, however, is not an excuse for unnecessary complexity. An owner who compensates for a broken process by sheer willpower is just another failure point. If the process only works because one person is heroically holding it together, you still have a Goldberg’s machine — you have just put someone in charge of catching every domino that falls the wrong way.

Too many steps

As in Goldberg’s machine, having 20 steps to switch on the light is fun but unnecessary. And it won’t likely work as designed, not from the first go, and it will fail occasionally when one of the steps fails.

People on my team and I created diagrams of processes, of how we want to work. Most of it was never fully implemented. It was too complex, and although it looked nice on a diagram, it was very fragile. It relied on multiple people, doing certain things in a certain order. When we simplified — fewer handovers, fewer syncs, fewer approvals — the process actually stuck. A good heuristic is that if you need an instruction on who is doing what at which stage, try to simplify.

Constraints

Even simple systems fail. People forget, or they are pressured to deliver. We can reinforce the process by making it impossible to move work forward without satisfying certain criteria. A simple example everyone is familiar with is mandatory code review. If we want to enforce code reviews in our team, we make it impossible to merge the code until the review is done. To the same category belong all kinds of continuous integration rules, static checks, and ticketing system constraints.

For example, a ticket cannot be closed before it is validated by the QA team. This can be enforced in the ticketing system. For a critical work, we can use checklists. The process cannot proceed until all items on the checklist are checked.

Organizational debt

Sure, with enough trial and error and patience, you can make a Goldberg’s machine work. As with complex software, by debugging and tweaking long enough, we can fix a bug or implement a reliable feature. As with software, a badly designed system creates debt. In the case of a process, it is organizational debt.

Do you have organizational debt in your processes?

Reevaluate your process against Rube Goldberg’s criteria

• How many handovers does it require? Are all of them strictly necessary?

• Do you have a clear owner, or are you relying on people to self-manage the orchestration?

• Do you have guardrails in place, or does the process rely on memory and goodwill?

If any answer makes you hesitate, it might be a signal that you have a Goldberg’s machine.

The better approach is to design a system that is not smarter than a person or organization who need to use this system. Simplify first. Add guardrails and owners as needed, and you should end up with something that is just complex enough to serve its purpose.

If this was useful, subscribe to get one practical take on engineering leadership every week.