The best automation lessons I learned weren't in IT.

Every automation starts with a question most people get wrong

When I see another manual task, most people ask: "How do we automate this?"

My first question is almost always different: "Why does this process work this way in the first place?"

Over the years, I realized this question is what leads to the right solution. This habit formed long before I worked with Linux, Docker, or DevOps. It came from manufacturing.

The Conveyor That Scratched Itself

Before moving to IT, I spent years in production management at a large home appliance factory. We didn't just assemble imported kits; we manufactured the products end-to-end, raw metal to finished box.

On one of the assembly lines, there was a problem everyone had simply gotten used to. About every sixth appliance at the end of the line was sent back for rework due to scratches on the painted chassis. Around 17% of the production required rework daily.

For most, this had become the norm:

  • — "It happens."
  • — "The conveyor runs fast, you can't avoid it."

But I was more interested in data than explanations. The quality control inspector recorded all defects, so I built a Pareto chart. Scratches were the clear number one on our waste list.

So instead of holding another meeting, I spent a few hours standing next to the line, just watching the process.

Eventually, the cause became obvious. At one of the stations, an operator drilled holes in the chassis. Metal shavings fell directly onto the conveyor belt. The belt itself was padded with soft rubber to protect the painted surfaces. And that was the problem.

The shavings got embedded in the rubber and stayed there. Every subsequent chassis slid over these tiny metal particles, which acted like sandpaper. The scratches didn't happen because of worker negligence — they were created by the assembly process itself.

We changed the sequence of operations and added vacuum cleaning immediately after drilling. The defect rate dropped from 16.7% to 1.3%. No new machinery. No expensive investments. No automation. We just fixed the process.

Years Later, I Saw the Same Problem in IT

Years went by. I was working with infrastructure, automation, and DevOps. And one day, I realized I still solve problems the exact same way.

A recent project was automating driver routing for service engineers. At first glance, it looked like a classic routing optimization problem. It seemed like the key was just using Google OR-Tools correctly.

But very quickly, it became clear that the algorithm wasn't the main bottleneck. The real challenges were completely different:

  • — addresses were entered in dozens of formats;
  • — many tickets lacked coordinates;
  • — business rules had accumulated for years, full of exceptions;
  • — part of the data was simply inconsistent.

The optimization algorithm worked perfectly. The real engineering work was building the process around it. Looking back, I realize that inconsistent addresses were the metal shavings on the conveyor belt. Until you clean them up, no algorithm will make the process truly efficient.

Automation Is Not Always an Improvement

Sometimes I imagine how we could have solved the factory problem differently. For example, by installing an expensive industrial robotic painter at the end of the line to automatically repaint all the scratched chassis. It sounds absurd, doesn't it?

But in IT, we do this far more often than we think. Instead of figuring out why a process works incorrectly, we write another script. Then another cron job. Then another container. Then another monitoring system. As a result, we don't automate the process. We automate its flaws. And the better the automation works, the faster those flaws multiply.

Common Sense Described in Methodologies

Many things that seem like common sense are actually described in classical methodologies:

  • — PDCA (Plan-Do-Check-Act) taught me that any improvement starts with observation and measurement, not implementation.
  • — Lean forced me to look not for new tools, but for waste that can be eliminated entirely (Muda).
  • — The Theory of Constraints showed that almost every system has one true bottleneck, and optimizing anything else rarely yields meaningful results.

Today, I barely think about these methodologies. They have simply become a part of how I approach engineering tasks.

Tools Change. Mindsets Don't.

Over the years, I've worked with dozens of technologies. Tomorrow, new tools will appear, and some of the current ones will become history. But before writing the first line of code, configuring a new service, or automating another process, I still ask myself the same question I first asked years ago standing by that conveyor line:

"What problem is this process actually trying to solve?"

Because when you understand the process, the technology is almost always the easiest part.