Falsely Thinking It Was Just Another Automation Project
When I first took on this project, I expected it to be a straightforward engineering challenge, optimise processes, integrate new machines, automate repetitive tasks, and increase efficiency. The goal seemed clear: take a production plant that relied heavily on manual labor and implement automation step by step. Simple, right?
I quickly realized I was wrong. This wasn’t just about machines, PLC programming, or optimizing workflow efficiency. It was about people, fear, and trust. The factory had operated the same way for years. Some of its manual labor reliance was due to strict regulations, but a significant part was simply because automation had never been prioritized. The real challenge was not making the machines run, it was getting people to trust and accept them.
There was an enormous disconnect between the different stakeholders. Workers on the production floor feared automation, believing it would replace them. They felt like decisions were being made over their heads without anyone asking for their input. Meanwhile, engineering teams struggled to push automation forward because the existing manual processes weren’t well-documented, making it difficult to design a structured transition. Management, on the other hand, wanted automation to move quickly but failed to recognize the resistance it was creating. Nobody was on the same page.
The real problem wasn’t technology, it was communication.
Understanding the Manufacturing Process and Its Limitations
Before introducing automation, I needed to fully understand the existing production process. The plant relied on a sequence of manual steps, beginning with raw material preparation, followed by CNC machining and grinding, and then moving into quality control, assembly, coating, and final inspection. While some individual machines were automated, the overall workflow was heavily dependent on human decision-making and adjustments. Operators manually checked parts, recorded measurements with callipers and micrometers, and made process adjustments based on experience rather than real-time data.
This system led to several major inefficiencies. Quality control, for instance, was inconsistent, as it relied on individual interpretation rather than standardized metrics. Measurements were manually recorded at fixed intervals, which meant defects were often caught too late. Data was being collected but wasn’t being used to optimise processes dynamically. Because there was no automated feedback loop, machine adjustments were made reactively rather than proactively.
Regulatory constraints complicated the situation further. Some steps in the process had to remain manual to meet industry compliance requirements. This meant full automation was not an option. Instead, we had to design a flexible system that could operate in three different modes—fully manual, partially automated, and fully autonomous, depending on specific needs.
A New Approach: Gradual, Flexible, and Worker-Inclusive
The realisation that automation couldn’t be implemented overnight led to a different strategy. Instead of trying to overhaul the entire plant at once, we introduced automation in small, controlled steps, treating each production area as an independent cell. This allowed us to test, validate, and adjust before scaling automation further.
We also focused on flexibility. Each cell could operate in one of three modes. In manual mode, everything functioned as it always had, giving workers full control. In assisted mode, automation supported workers but still allowed for human intervention. Fully autonomous mode was introduced gradually, allowing machines to take over completely once processes were stable. This adaptability helped ease the transition and gave workers time to get comfortable with the changes.
Another key component was real-time quality monitoring through the redesign of Statistical Process Control (SPC). Previously, SPC was handled manually, with operators recording measurements on spreadsheets. The new system replaced this with optical measurement technology, allowing for live data collection at a much higher precision. Instead of relying on manual checks every 20-30 minutes, we now had an automated system that could instantly detect deviations and make real-time process adjustments. This reduced errors, improved consistency, and eliminated much of the guesswork in quality control.
The Real Struggle: Getting People to Accept It
Technically, everything was set up for success. But the biggest hurdle wasn’t technical, it was psychological. Workers saw automation as a threat, not a tool. Many had been working there for years and felt like automation was being forced upon them without any regard for their knowledge and experience. There was skepticism about whether the machines would work as expected, and many feared that once automation took over, their jobs would become irrelevant.
To address this, I had to change the way automation was introduced. Instead of presenting it as a management decision, I made it a collaborative process. We organized workshops where workers could voice their concerns and ask questions. More importantly, we let them test the automation before it was fully implemented, giving them a chance to interact with the new systems, understand how they worked, and see firsthand that they weren’t being replaced—they were being supported.
This shift in approach made all the difference. The more workers got involved in the process, the more they started to trust it. They saw how the SPC dashboards allowed them to track real-time data and make informed decisions. They realized that automation wasn’t about taking control away from them but helping them work more efficiently with fewer errors.
Management also had to adjust its perspective. Initially, they were focused on speeding up automation, but they had underestimated the importance of bringing workers along for the ride. Once they saw that resistance decreased when workers were included in the process, they started prioritising communication and training.
Lessons Learned: More Than Just an Engineering Problem
Looking back, I can say that this project was far more than just a technical challenge. It was a lesson in leadership, change management, and communication.
Automation isn’t just about machines, it’s about people. If the people using the system don’t trust it, even the most advanced technology will fail. The key is to introduce automation gradually, ensure flexibility, and make workers part of the transition rather than forcing it upon them.
Communication is just as important as technical execution. The biggest reason this project initially stalled wasn’t due to technical limitations, but because no one was talking to each other, not between management and workers, not between engineering and operations. Once we bridged that gap, things started to move forward.
Fear is the biggest roadblock in automation, not technology. People don’t fear machines; they fear being left behind. Addressing those fears, showing the benefits of automation, and giving them control over the process helped turn skepticism into acceptance.
Finally, small steps work better than big jumps. By automating cell by cell, we avoided overwhelming workers and minimized risk. Testing, validating, and adjusting before scaling further ensured that automation was implemented in a way that worked for everyone.
Final Thoughts: More Than Just a Project
This project started as a technical automation challenge but ended up being something much bigger. It was a deep dive into understanding people, adapting strategies, and learning how to implement change without forcing it.
Would I take on another automation project? Absolutely.
Would I assume it’s just about machines and efficiency again? Never.