Some of the biggest changes in how I work didn’t come from reading a whitepaper or going to a conference. They came from conversations. Quick ones, sometimes. A comment over coffee, a pushback during a design review, a frustrated operator explaining why nobody trusts “the new system.”
After 20+ years working on industrial data and manufacturing projects, I can point to five conversations that shaped how I think about this work.
1. “You’re solving a problem nobody asked you to solve.”
This one came early. I was maybe three years into manufacturing IT, excited about connecting everything. I had put together this great architecture, data flowing from the shop floor all the way up to the ERP. I was proud of it.
A plant manager looked at it, paused, and said, “That’s nice. But who asked for this?”
He wasn’t being rude. He just wanted to know which operator, which supervisor, which engineer had said, “I need this data.” And I didn’t have a good answer. I had built something because I could, not because someone needed it.
That conversation taught me to always start with the problem. Not the architecture. Not the platform. The problem. Who is struggling, and why? If you can’t answer that clearly, you’re not ready to build anything.
2. “We already have a Historian. Why do we need another system?”
I heard this one at a large manufacturing site during a workshop. An automation engineer was genuinely confused about why we were adding a new cloud data layer when they already had a system collecting thousands of data points.
And honestly, it was a fair question.
The real answer wasn’t that their system was bad. It was doing exactly what it was built to do, storing time-series data for process control. But the new needs, things like quality predictions, efficiency dashboards, comparing performance across sites, required something different. They needed data with context, not just raw numbers.
That conversation pushed me to get better at explaining why a shared data layer matters, in plain words. Not “we need semantic interoperability.” More like, “Right now, if someone asks what the batch yield was last Tuesday, three people give three different numbers. We need one answer everyone trusts.”
If you can’t explain it to the engineer who’s been running that plant for 15 years, you don’t understand it well enough yourself.
3. “Stop showing me dashboards. Show me decisions.”
This came from a VP of Operations during a project review. We had just set up a bunch of real-time dashboards, live data streaming in, color-coded alerts, the works. The whole team was proud.
The VP looked at it and said, “It’s pretty. But what decision does this help me make at 7 AM on a Monday?”
That hit hard. Because he was right. We had built visibility without purpose. Lots of data on the screen, but no clear action tied to it.
After that, I started building every dashboard, every report, every screen around one question: what’s the decision? If the answer is “it’s just nice to know,” that’s a warning sign. Nice-to-know doesn’t survive the first budget cut.
Now, whenever I design something, I think in terms of decisions per shift, not data points per second.
4. “You IT guys always leave after go-live.”
An operator told me this during a site visit, about two years after a system had gone live. He wasn’t angry, just tired of it. He said the system worked fine for a few months, then things started breaking. Small things. A data mapping changed, a dashboard stopped updating, a new product was added but nobody fixed the setup. And no one came to help.
That conversation changed how I think about project scope. I stopped treating launch day as the finish line. Now I push hard for support plans, clear ownership, simple guides, and training that actually works, not just a document nobody opens.
The truth is, most projects don’t fail at launch. They fail six months later, quietly, when the people who built it have moved on and the people who use it don’t know how to keep it running.
If you want your project to last, plan for the boring part. The upkeep. The fixes. The handoffs. That’s where real value lives.
5. “I don’t care about the technology. I care about my people.”
This one came from a site director at a manufacturing plant. We were talking about a big modernization effort, replacing old control systems, adding new computing at the edge, rolling out analytics. Big scope, big budget.
I was deep into the technical details when she stopped me and said, “I don’t care about the technology. I care about my people. Will they understand it? Will they trust it? Will it make their day easier or harder?”
That was a turning point. Because she was absolutely right. You can build the most elegant system in the world, but if the operator on the night shift doesn’t trust the data, or the maintenance tech can’t figure out what went wrong, or the engineer feels like the system was forced on them, it won’t work.
Since then, I always make change management and training a core part of the work, not something we think about at the end. I spend time on the floor with operators before designing anything. I ask them what’s annoying, what’s slow, what they wish they had. And then I try to build that.
Technology is the easy part. People are the hard part. And the important part.
So, What Did I Actually Learn?
Looking back, these five conversations all point to the same thing. This work is not a technology problem. It’s a people problem wrapped in technology.
The best systems I’ve seen weren’t the most advanced. They were the ones where someone took the time to understand the real problem, explain the solution in simple words, build for decisions instead of data, plan for what happens after launch, and put people first.
That’s it. No magic framework. No fancy method. Just listen more, assume less, and never forget that every sensor, every data point, every dashboard exists to help a person do their job better.
If you’re early in your journey, my advice is simple. Go have more conversations. Not with vendors. Not with analysts. With the people on the floor. That’s where the real insights are.
Leave a Comment