Connected Sensors Don’t Buy You Uptime. Operating Discipline Does.

I have shipped connected products and I have carried the operational consequences when they under-deliver. The pattern is consistent: teams buy telemetry and call it “digital maintenance.” Then uptime does not move, and everyone blames the model, the cloud, or the plant culture.

My view is simpler and more uncomfortable. Connected sensors do not buy you uptime. Operating discipline does.

When I ran a smart-building business unit with full P&L responsibility, we built and sold connected sensors and controls across several countries. The tech worked. Data flowed. Dashboards were beautiful. Still, the results depended almost entirely on whether customers (and our own service teams) turned signals into owned actions, with clear economics and tight feedback loops. Later, when I ran operations in electrification and energy storage across Denmark and Ukraine, the same principle showed up again: reliability is an operating system, not a feature.

Yes, remote monitoring can support proactive maintenance and reduced downtime, as described in Manufacturing Dive’s piece on connected sensors and real-time monitoring for proactive maintenance. I agree. But “can” is doing a lot of work in that sentence. The missing piece is not more sensors. It is what you do after the alert.

The real failure mode: telemetry without an owner

Most sensor programs die in one of three places:

• No single throat to choke. Maintenance owns the assets, IT owns the network, engineering owns the spec, operations owns output. The alert lands in everyone’s inbox and in no one’s hands.
• No economic threshold. Teams treat every anomaly as urgent, then get alert fatigue. Or they ignore everything until a breakdown, then claim the sensors “didn’t predict it.”
• No closed loop. Even when a technician responds, the outcome does not feed back into rules, spares strategy, PM plans, or vendor accountability. The system never learns.

If you want a board-level translation: you did not buy uptime, you bought observability. Uptime is produced by execution.

Turn telemetry into an operating system: the closed-loop rule

I push teams to design reliability like a plant control loop. A sensor signal is only the measurement. The rest is your controller, your actuator, and your feedback.

Here is the closed-loop rule I use:

No alert is “real” until it has an owner, a decision rule, and a verified outcome.

Operationally, that becomes a small set of non-negotiables.

1) Assign ownership by asset class, not by technology

Do not create a “connected services” team that owns dashboards. Create asset owners who own uptime for a class of equipment (pumps, compressors, HVAC loops, conveyors, inverters). Their job is to make the system quieter and more accurate over time.

When I led R&D organizations across embedded, cloud, electronics, mechanics, and QA, I learned that cross-functional does not mean ownerless. It means one accountable owner who can pull the functions in when needed.

2) Define decision rules in money and time

Every alert needs a response policy that is explicit about economics. Not “high, medium, low.” Real thresholds:

• What is the cost of a false positive (truck roll, production interruption, unnecessary spare)?
• What is the cost of a miss (scrap, lost output, safety risk, contractual penalties)?
• What is the latest safe intervention window (hours, shifts, days)?

This is where uptime becomes a business conversation instead of an engineering debate.

3) Make response a product, not a project

The best programs treat “diagnose, decide, dispatch, verify” as a product with a roadmap. You iterate response playbooks the same way you iterate software.

In industrial environments, the playbook often matters more than the predictor. A simple rule with a fast response beats a brilliant model with slow approval and missing spares.

4) Close the loop with three feedback tables

If you want the system to improve, you need structured learning. I use three tables, even in lightweight setups:

• Alert-to-work-order mapping: every alert either creates work or is dismissed with a reason code.
• Work-order outcome: confirmed fault, prevented failure, no issue found, wrong asset, wrong threshold.
• Post-mortems for escapes: any breakdown on a monitored asset is reviewed against “what did we see, when, and why did we not act?”

This is basic quality discipline applied to reliability. I spent eleven years in power electronics and market quality roles, and the lesson transfers cleanly: without structured feedback, you repeat the same failures with better graphs.

A lived example: connected devices are easy, interventions are hard

When I was CEO of a connected building-controls business unit, customers often asked for “more data” to reduce service calls. Our devices could deliver it. The hard part was operational integration on the customer side.

The ones who succeeded did a few unglamorous things:

• They named one operations owner for critical systems (not an IT owner for the platform).
• They standardized the top failure modes and stocked the parts that actually failed.
• They built a fast path from alert to access (permissions, keys, site rules), so the technician could act within the intervention window.

The ones who failed did the opposite. They rolled out sensors broadly, routed alerts to generic inboxes, and argued about the accuracy of predictions while the same assets kept failing. They did not have a closed loop. They had a data lake with opinions.

This is also why I am strict about architecture in my own ventures. In IBHQ and Shopeno, I treat operational signals as commitments: every metric exists to trigger a decision, a task, or a customer-facing outcome. If it does not, it is noise and it gets removed. The goal is not visibility. The goal is controlled execution.

The board and operator checklist for this quarter

If you are a board member or an operator and you want to know whether your sensor program will move uptime, ask these questions in this order:

1. What is the business outcome? Is the goal fewer breakdowns, shorter MTTR, lower spare spend, higher OEE, or fewer emergency callouts? Pick one primary metric.
2. Who owns uptime by asset class? Names, not departments. If ownership is shared, it is owned by nobody.
3. What are the top 10 failure modes? If you cannot list them, you are not doing reliability, you are doing instrumentation.
4. What is the decision policy per failure mode? Threshold, intervention window, and economic tradeoff.
5. How does an alert become work? Show the path from signal to work order to dispatch to verification. Time it.
6. What is the learning loop? Where do outcomes get logged, reviewed, and used to tune thresholds, PM plans, and spares?
7. What gets removed? Which alerts, dashboards, and metrics are you actively deleting to reduce noise?

If you want a deeper lens on how I think about operator-grade systems, my framing in AI Architecture Isn’t a Diagram. It’s an Operator’s Checklist. applies here too: the value is in contracts, ownership, and failure handling, not in diagrams.

My opinion: stop funding sensors, start funding response capacity

Most organizations under-invest in the “last mile” of reliability. They fund devices, connectivity, platforms, and pilots. Then they starve the response system: spares, access, dispatch capacity, playbooks, and time for post-mortems.

If you want uptime, budget for the unsexy parts first. Buy the discipline. Then add telemetry where it tightens the loop.

That is the difference between a connected factory and a controlled factory. One collects signals. The other converts signals into fewer failures.