The Industrial IoT Blog

If there’s one thing I wish more people understood about IIoT architecture, it’s this: the tech is hard, yes — but managing people up, down, and sideways is the real superpower. You can have the cleanest architecture, the best platform, or the slickest cloud dashboards. None of that matters if you miss the human part. Projects stall, get blocked, or quietly die. I’ve seen it happen.

And after years connecting machines, systems, and teams across factories, labs, and supply chains, I’ve learned that this skill isn’t optional. It’s the difference between a shiny pilot that never goes anywhere and a platform that actually transforms how a company works.

Below is what “managing up, down, and sideways” really looks like in the trenches of smart manufacturing — not in a glossy playbook, but in real life.

What “Managing Up, Down, and Sideways” Actually Means

• Managing up: Influencing senior leaders, sponsors, and decision-makers. You’re helping them understand risks, tradeoffs, and the reality on the ground — even when it’s uncomfortable.
• Managing down: Leading technical teams and contributors. You’re responsible for motivation, clarity, and delivery, especially when priorities shift or the work gets messy.
• Managing sideways: Aligning with peers, partners, and departments like IT, OT, Quality, Cybersecurity, Engineering, Procurement, and vendors. You often have no formal authority, but you still need the group to move in one direction.

Most IIoT architects don’t realize how much of their job will involve these three dimensions. In reality, this is the work that determines whether your architecture gets deployed and adopted — or becomes another abandoned diagram.

Managing Up: Speaking Exec (and Speaking Truth to Power)

When you’re leading IIoT initiatives, you spend a surprising amount of time translating between the shop floor and the top floor. Executives want outcomes: compliance, productivity, cost, speed. They don’t care about MQTT, Sparkplug B, OPC UA, or your perfectly designed data model. They want to know:

• “Will this help us release products faster?”
• “Will we avoid a recall?”
• “What’s the risk if we wait?”

So I frame every recommendation in business terms. When we had to sunset a legacy manufacturing integration system, I didn’t start with “unsupported protocol” or “technical debt.” I started with:

• the risk of losing regulatory data,
• the cost of emergency fixes,
• the opportunity to enable real-time analytics for product release.

I’d use numbers where I could and keep the jargon out.

But even with clear framing, you still get pushback. Execs juggle a hundred priorities. Digitalization is just one. Sometimes you repeat the message. Sometimes you wait until a compliance audit or a production incident creates urgency. Timing matters as much as logic.

And then there’s the harder part: speaking truth to power.

In one global rollout, certificate management and network security turned out far more complex than expected. We had to tell senior leadership, “We can’t scale this until we fix it, and it will push the timeline.” Not fun, but necessary. If you sugarcoat, you lose credibility. If you’re overly negative, you lose support. The trick is to show real data, propose options, and be transparent about what you need — budget, resources, or simply political air cover.

Many leaders love the idea of “digital transformation” but underestimate the messiness of dealing with legacy systems, site diversity, or stubborn equipment suppliers. As an architect, you have to help them see the whole chessboard, not just the move they want to make.

Managing Down: Leading Delivery Teams Through the Chaos

On the other side, you’re the one keeping technical teams focused. These are the people debugging PLC connections, mapping data, configuring brokers, or figuring out why the historian is dropping tags at 2 AM. They want clarity and support — and they want to know that their work matters.

What’s worked for me is being hands-on when needed but not micromanaging. I’ll join a mapping session or help debug a stubborn MQTT connection, but I give teams room to own their piece.

I set clear priorities — “Let’s get real-time OEE working at the first pilot site before we automate everything.” I protect them from random scope changes. I keep documentation visible and track progress transparently. Weekly meetings, even short ones, help keep blockers visible.

And motivation is crucial. IIoT programs are marathons, not sprints.

Sometimes managing down means defending your team — pushing back on unrealistic deadlines, calling out resource gaps, or saying “no” to scope creep. Good leaders make space for their teams to succeed instead of burning them out.

Managing Sideways: The Art of Cross-Functional Alignment

This is the most underrated — and the most critical — part of IIoT leadership.

You’re surrounded by functions that don’t naturally speak the same language:

• IT
• OT
• Engineering
• Quality
• Cybersecurity
• Procurement
• Vendors
• Data teams

Each group has its own priorities, constraints, and fears. And no single team owns the whole puzzle.

I’ve seen more projects stall because of cross-functional misalignment than because of technical issues.

When we rolled out a new connectivity platform, Cybersecurity had to approve firewall rules, Quality had to validate compliance, Engineering had to confirm data requirements, and vendors had to stay aligned with our architecture standards. If you don’t bring these groups in early, you’ll get blocked — often at the worst moment (sometimes the day before go-live).

In one case, a vendor’s architecture drifted away from the validated design we had aligned with our integration partners. That created confusion and mistrust — not because anyone was incompetent, but because people weren’t talking early enough. We had to pause, regroup, and realign around what “good” meant for the business, not for any single team.

In another case, integrating equipment data required negotiating with both local engineers and global data teams. Each had its own standards and tools. The only path forward was transparency: shared success criteria, open workshops, and a willingness to say, “We don’t have all the answers yet.”

Sideways management is basically structured herding: over-communicate, document decisions, share risks early, and escalate with facts (not emotion) when needed.

Translating Tech to Business (and Back)

A big part of managing in all directions is translation — not just language, but context.

For execs, I strip out the tech:
“Here’s the business value, and here’s the risk.”

For engineers, I get specific:
protocols, models, performance metrics.

For cross-functional partners, I connect the dots:
“Here’s how this impacts your process, your audit trail, or your shift operations.”

I always use real examples — screenshots, before/after views, pilot lessons. And if I don’t know the answer, I say so. People appreciate honesty more than a made-up explanation.

The Politics and the Pushback

Let’s be real: not everyone wants change. Some fear extra work, others fear losing control. Some just don’t want another system. I’ve seen resistance from every direction — local engineers, IT, operators, vendors.

The only way through is empathy, patience, and persistence.

Quick wins help. Giving people a voice helps. Being transparent about non-negotiables helps. And sometimes you accept that not everyone will be happy. But if you build trust, most will come around when they see the results.

The Hidden Skills Nobody Talks About

These don’t show up on job descriptions but matter more than any protocol or cloud service:

• Translating between worlds — explaining tech risk to business leaders and business priorities to technical teams, using real examples.
• Building trust — people follow people, not architecture diagrams.
• Staying humble — you will get things wrong; own it and move on.
• Negotiating and setting boundaries — especially with vendors who drift from validated designs.
• Empathy and patience — because many people have run plants for decades and deserve respect for that experience.

Wrapping Up: Why This Skill Matters

Too many IIoT projects fail because people chase technology instead of fundamentals: governance, communication, alignment, and clarity. A perfect architecture is useless if nobody uses it, nobody understands it, or nobody is aligned around it.

I’d take a moderately good system with a well-aligned team over a perfect architecture with poor alignment any day.

Managing up, down, and sideways isn’t glamorous, but it’s the real work of digital transformation. If you want to make a difference in smart manufacturing, learn to navigate the people side as much as the tech.

The best IIoT architects aren’t the ones who know every protocol. They’re the ones who can walk into a room with executives, operators, and engineers — and leave with everyone pulling in the same direction.

And honestly? Never underestimate the power of a shared coffee break or a simple “thank you.” In the end, the human part is what moves the needle.