Productivity & Processes
Practical articleMaluure Principle: Never Automate a Bad Process
Automation makes good workflows faster and bad workflows faster at being bad. Our first Maluure principle explains why order matters and how to tell if a process is ready for automation.
of Josef Kujawski6 min read
Short answer
Automation is a multiplier: it makes good processes faster and bad processes faster at being bad. That's why the first Maluure principle is: never automate a bad process. The order is always understand, simplify, stabilize, and only then automate. Automating an unclear workflow cements its weaknesses and makes later corrections more expensive.
The observation: automation as an accelerator without direction
Few promises sound as tempting as this one: just automate that annoying step, that recurring task. There are plenty of tools for it, and technically they mostly work flawlessly. Yet we regularly see projects where automation has caused more harm than benefit.
The reason is almost always the same: a process got automated that didn't work well in the first place. The result isn't a solved problem, it's a problem on a continuous loop.
The principle
Never automate a bad process.
Automation is a multiplier. It multiplies speed and consistency, but it multiplies errors, detours and bad assumptions just the same. An unclear approval process doesn't get clearer through automation, it just gets unclear faster, for more people, with less chance to intervene.
Kernaussage
Automation amplifies what's already there. It fixes nothing. That's why the rule always is: simplify and stabilize the process first, then automate.
Context: where this principle comes from
The idea is older than any no-code tool. Bill Gates put it this way: automation applied to an efficient operation magnifies the efficiency. Applied to an inefficient operation, it magnifies the inefficiency. [1]
In software development, this pattern is known as "premature automation": you build an elegant solution for a workflow you haven't understood yet, and thereby cement its weaknesses. Every later correction becomes more expensive because it's now cast in code.
Application: the three-stage test
Before we automate anything for clients, we check three stages:
- Understand: Can someone on the team explain the process in five sentences, including the exceptions? If not, it hasn't been understood.
- Simplify: Which steps would disappear if you reinvented the process today? Often it's thirty to fifty percent.
- Stabilize: Does the simplified process run stably by hand for a few weeks? Only then is automation an investment instead of a risk.
The solution: process first, then tool
Concretely, this means for you:
- Write down the process before choosing a tool. The tool shouldn't define the workflow, it should be the other way around.
- Cut steps before you automate them. An automated unnecessary step is still an unnecessary step.
- Keep a manual fallback. Every automated process needs a documented way to work without it.
- Schedule reviews. Automated processes age. What made sense two years ago can be dead weight today.
| Question | Good sign | Warning sign |
|---|---|---|
| Is the process documented? | A notice, a wiki entry | "Only Sabine knows that" |
| Are there exceptions? | Listed and rare | "It depends" |
| How often does it run? | Weekly or more often | Twice a year |
| What does an error cost? | Little, correctable | A lot, hard to correct |
The Maluure approach
We love automation. A large part of our own work runs on workflows we built ourselves. But as a rule, we only automate what we've simplified and proven manually beforehand. That's slower on day one and faster from month two onward.
The most expensive automation is the one that cements a process nobody questions anymore. Simplify first, then stabilize, then automate. In that order, always.
Related articles
Frequently asked questions
Why is it bad to automate a bad process?+
Automation amplifies what's already there. An unclear or flawed workflow doesn't get better through it, it just becomes wrong faster and for more people. Errors then run on a continuous loop, and corrections become more expensive because they're baked into software.
How do I know if a process is ready for automation?+
Three signs: the process is documented and can be explained by several people, it has been simplified and runs stably by hand, and it repeats often enough that the effort pays off.
What does premature automation mean?+
The term describes automating a workflow before you've truly understood it. The consequence: weaknesses get cemented, and every later change becomes more costly.
Should I buy a tool first and then adjust the process?+
No. Write down and simplify the process first, then choose the tool. Doing it the other way around means adopting the tool's assumptions instead of your own requirements.
How much can you save through simplification before automation?+
In our projects, rethinking a process from scratch often eliminates thirty to fifty percent of the steps. That typically also cuts the effort for the actual automation in half.
Does every automated process need a manual fallback?+
Yes. Every automated workflow should have a documented manual path so operations can continue if the tool fails or in special cases.
How often should automated processes be reviewed?+
At least once a year. Automated workflows age, because requirements, tools and teams change. What made sense two years ago can be dead weight today.
Sources
- Bill Gates: The Road Ahead (Automatisierung effizienter und ineffizienter Abläufe), Viking Press (1995)
#Automation#Processes#Productivity#Maluure Principle#Digitalization
Author
Josef KujawskiManaging Director & Creative Director at Maluure
Josef leads the strategic and creative development of brands at Maluure. For over a decade, he has guided medium-sized businesses from brand positioning to digital delivery.
Managing Director of Maluure GmbH, Cologne. Specialising in corporate design, brand strategy and digital brand experiences.
Related articles
Psychology & Decisions
The Peak-End Rule: What Visitors Really Remember About Your Website
The peak-end rule explains why people judge experiences by their peak and their ending, not by the average. With Kahneman's experiments and concrete rules for checkout flows, contact forms, and farewell pages.
5 min read
Psychology & Decisions
The Paradox of Choice: Why More Options on Your Website Mean Less Revenue
The paradox of choice explains why visitors faced with too many options decide nothing at all. With the jam experiment, the limits of the effect, and concrete rules for navigation, pricing pages, and forms.
5 min read
Development
Core Web Vitals: What Google Measures on Your Website and Why It Costs Revenue
Core Web Vitals are Google's yardstick for loading speed, responsiveness, and stability of a website. What LCP, INP, and CLS mean, which thresholds apply, and how to improve the scores concretely.
6 min read