I have spent most of my career around what people usually call the “hard” side of manufacturing technology. Machines. Networks. Data pipelines. MES screens. OPC UA tags. MQTT topics. Historians. Systems that can be diagrammed, measured, and optimized.
Yet the longer I work in digital transformation, the more obvious one thing becomes.
The technology is rarely the hardest part.
The real challenge is human coordination. Getting smart people from different functions. With different goals, languages, and concerns. To move in the same direction long enough to actually change how a plant operates.
Digital transformation looks like a technology program from the outside. In reality, it is mostly a human system problem that happens to involve technology.
Where Most Transformations Actually Struggle
When transformation programs begin, the assumption is usually that the difficult part will be the systems. Legacy machines. Integration layers. Data models. Network security.
Those things are complicated, but they are predictable. With enough expertise and time, technical problems usually get solved.
Human systems are different.
Operations focuses on uptime and production flow.
Automation focuses on stability and safety.
IT focuses on security and standardization.
Quality focuses on compliance and documentation.
Engineering focuses on future-proof design.
Finance focuses on cost and measurable return.
Every one of those perspectives is valid. The problem appears when each group optimizes for its own definition of success.
That is usually where projects slow down. Not because people disagree about the technology, but because they are solving slightly different problems.
The turning point in many successful programs is surprisingly simple. The team agrees on one clear sentence.
What problem are we solving first, and what does success actually look like?
If that answer cannot be explained in plain language, the program is not ready to move forward yet.
Reality Lives on the Shop Floor
Another common issue appears when transformation efforts happen mostly in meeting rooms.
Slides get better. Architecture diagrams get cleaner. Strategies become more impressive.
But real manufacturing does not behave like a slide deck.
On the shop floor, work is messy. Sensors fail. Lines stop for reasons no system captures. Operators are juggling tasks while supervisors ask questions. Someone always needs to restart something, clean something, or sign something.
Designing systems without understanding those realities almost guarantees friction later.
A simple example is downtime tracking.
In a meeting, it sounds easy to say, “We will capture downtime reasons digitally.”
In practice, an operator might have twenty seconds to log that information. They may be wearing gloves. The line may be waiting. Someone may already be asking what happened.
That is why simple operator interfaces are not just helpful. They are essential.
The most reliable designs are not validated in presentations. They are validated against real workflows on the plant floor.
Resistance Usually Has a Story Behind It
Resistance to transformation is another pattern that appears in many organizations.
It is easy to interpret resistance as fear of change. In many cases, the real reason is more practical.
People remember previous initiatives that promised improvements and delivered frustration. They remember systems that added work instead of removing it.
In one manufacturing site I worked with, operators had already experienced several digital initiatives in just a few years. None had lasted.
So when a new project arrived, the reaction was predictable.
Instead of presenting features, we asked questions.
What frustrated you about the previous systems.
What part of your job is unnecessarily difficult today.
What would actually help you during a shift.
Listening changed the tone of the project. Some of the strongest skeptics eventually became the most helpful contributors.
Not because the technology was impressive, but because their reality was finally acknowledged.
Trust Is Built Quietly
Trust between teams is rarely created during kickoff meetings or steering committees.
It develops in smaller moments.
Admitting when you do not know something.
Following up quickly on a small commitment.
Explaining a constraint without dismissing someone’s concern.
Showing up on the shop floor early in the morning.
Answering a call when something breaks.
Those actions slowly change how teams see each other.
When people believe you are trying to solve the problem together rather than defend your own area, discussions become more productive.
Translation Is an Underrated Leadership Skill
Many conflicts in digital transformation are not technical disagreements. They are language gaps.
Automation might say, “We cannot touch the PLC.”
IT hears, “They are resisting standards.”
IT might say, “We need certificates, patching, and least privilege.”
Operations hears, “They are slowing production.”
Quality might say, “If it is not documented, it did not happen.”
Engineers hear, “Innovation is blocked again.”
A large part of leadership in cross-functional programs is translation.
Understanding what someone actually means.
Understanding what risk they are trying to avoid.
Understanding what conditions they need before they can say yes.
Once that translation happens, many technical debates become easier to resolve.
Alignment Is Continuous Work
Another lesson is that alignment does not happen once.
Teams sometimes try to solve alignment with a single workshop or strategy session. That rarely holds for long.
Priorities shift. New risks appear. Teams interpret decisions differently.
The most effective teams maintain alignment through frequent, short conversations where trade-offs are discussed openly.
Sometimes even simple tools help. For example, visualizing risks and benefits together can make disagreements clearer and easier to resolve.
Alignment is not a milestone. It is an ongoing process.
Governance Should Reduce Chaos, Not Add Bureaucracy
Earlier in my career I assumed governance existed mainly for control.
Now I see it as a way to protect the teams doing the work.
Without practical governance, digital programs tend to drift.
Different naming conventions appear.
Assets are modeled in multiple incompatible ways.
Quick experiments quietly become permanent production systems.
Security exceptions accumulate.
The goal is not heavy bureaucracy. The goal is clarity.
A few standards that truly matter.
A clear path for decisions.
A defined platform owner.
A backlog that reflects real priorities.
A definition of done that includes validation and cybersecurity.
When governance stays close to the work, it supports teams rather than slowing them down.
Progress Usually Comes from Small Wins
Large transformation programs often begin with ambitious visions. Multi-site platforms. Advanced analytics. Artificial intelligence.
Those visions are useful, but momentum on the ground usually comes from smaller improvements.
Automating a repetitive report.
Improving a confusing alarm.
Simplifying a screen operators use every day.
Small wins make progress visible. They build confidence that the transformation is not just another presentation.
The Culture of the Team Matters
Finally, the strongest cross-functional teams share responsibility.
They celebrate success together.
They own failures together.
They do not distance themselves when something goes wrong.
That behavior sounds obvious, yet it is surprisingly rare.
When teams adopt that mindset, complex programs become far easier to navigate.
Final Thought
Digital transformation is often presented as a technology challenge.
In practice, it is mostly a coordination challenge between people who see the world differently.
When the human system works. When teams share goals, communicate clearly, and trust each other. The technology has a chance to succeed.
When the human system fails, even the best architecture will struggle.
You can build an impressive platform and still end up with a very expensive collection of systems that almost worked.
The difference is rarely the technology.
It is the people.
Leave a Comment