We gained visibility. Then we found the next problem.
I started my career at Vermont Electric Cooperative as a SCADA engineer. We had just been awarded millions in federal funding and were adding thousands of real-time data points to the system, two-second resolution across every substation.
I was building displays and dashboards for the control center operators as they moved from a tile map board (yes, little 1-inch by 1-inch tiles) to a digital map board. The control room had more visibility into the system than it ever had before, and as a young engineer I felt like I was having an impact.
From tile board to digital map board: visibility expanding inside the control room.
Every year, I'd spend a couple of weeks exporting a slice of that data for the engineering team so they could do their annual studies on transformer loading and run load flows on the distribution system. I wasn't a software engineer, but the only way to get the data out was to write SQL queries, one feeder at a time, otherwise things would crash. Format it. Hand it off. Eventually we bought an OSIsoft PI historian that gave the engineers direct access. Problem solved, in theory. In practice, the workflow didn't change. They still ran one big annual study. The historian had years of data sitting in it, but nobody was watching for anomalies that weren't outages. There was no notification when a substation transformer trended toward overload. There was just the annual report, and the phone call from a member when the lights went out.
Around the same time, we had just finished deploying AMI 1.0. The data lived in the MDM and a handful of staff could log in to look at it. Key accounts, IT, the people whose jobs touched billing data closely. Customer service reps got their view through NISC SmartHub. If anyone wanted aggregations like transformer loading, that meant a manual CSV export. Real-time queries meant a different tool. Historical analysis meant another.
We eventually invested in more software to combine interval data on every meter, identify transformer loading on every transformer, add sensor data where AMI couldn't reach, and pull in DER telemetry from batteries, EV chargers, and C&I sites through Texture. By any reasonable measure, VEC was pushing the boundary of what visibility could mean for a co-op.
And yet, in every conversation I had with co-op staff at VEC, and now across the dozens of conversations I have at Texture, I hear the same line. Some version of:
“We have so many tools, so much data, and my staff is overwhelmed by all the things we need to look at.” — what co-op operations staff actually say
More data, more tabs, same staff
I spent years, alongside many in the industry, telling utilities that the answer to operational complexity was visibility. More data sources. More integrations. More data. More tools. Each layer was sold on the same promise: if you could just see more, you could be proactive instead of reactive.
What actually happened is that utility staff now have six tabs open instead of one plus 10 CSVs.
This is something we ran into when I was at VEC. We added software for transformer loading. It identified about 1,000 overloaded transformers. Half of those turned out to be the wrong size in GIS, which was useful to know. The other half got divided up among the six utility design staff, about 80 each to review. Here's the catch: this wasn't part of their daily workflow. They had originally wanted the software for analyzing new services and replacements, not for triaging a list of 80 transformers that might or might not be problems right now. They wanted to solve this new problem, but nobody had time to sort through their pile and figure out which ones to act on this week versus next quarter.
That's the pattern. “Go look at the dashboard” is not a workflow. It's a chore that competes with every other thing a small operations team has to do in a day.
A 30,000-meter co-op might have one or two people responsible for everything that touches engineering operations. Outages, load growth, planning, member complaints about voltage, the new battery program someone signed off on last year. That person does not have time to monitor a dashboard. They have time to respond to things.
And if you're a larger co-op with the luxury of a data analyst, the odds are they've just built you more dashboards.
Here's the underlying issue: Most grid software assumes someone is sitting in front of a screen, watching. The reality is that the engineer is in a truck. The ops manager is in a board meeting. The line supervisor is on the phone with a member. Nobody is watching the screen.
The screen, in fact, is not where the work happens.
Most grid software stops at visibility. The work happens in the two layers above it.
The shift: from visibility to monitoring, notification, and resolution
The unlock isn't another dashboard. It's two layers that sit on top of the data and let utility staff decide what matters.
Monitoring and notification is the first. Resolution is the second. Most grid software today gives you the data and stops. The work of figuring out what to do with it falls back on whichever staff member happens to have a tab open.
-
Monitoring and notification - The platform watches the data instead of asking the staff person to. A monitor gets set up once, with a clear definition of what counts as a problem. Member meter usage above 2x the 30-day baseline for 3 days. Transformer loading above 93% on a feeder for more than an hour. The detection method might be a fixed threshold, an anomaly against a baseline, or a missing-data signal that something stopped reporting. The routing knows which staff person owns that class of issue, what severity gets them paged versus emailed, and what channel they actually read.
-
Resolution - The part the industry doesn't talk about enough. A notification that doesn't lead to a closed-out action is just another thing in someone's inbox. Resolution means the notification carries enough context to act on, the person who receives it can acknowledge or hand off, and the system tracks whether it actually got handled. That's the difference between an alert and an open ticket.
The dashboard era assumes someone is watching. Monitoring & notifications assumes nobody is.
Go back to the VEC transformer story.
With 1,000 transformers identified, six engineers, 80 each to review, and no daily workflow for it.
In a monitoring-and-notification model, those 1,000 transformers don't land as a list, they would land as 1,000 monitors quietly running in the background. Most of them never fire. The GIS errors get flagged once as a data-quality issue and routed to whoever fixes GIS.
The 50 that are actually trending toward thermal limits this summer would send alerts in priority order, routed to the engineer who owns that part of the system, with the historical loading curve and the nearest swap candidate already attached. The other 450 stay monitored but quiet. No triage pile, no dashboard to remember to open. The work shows up when there's work to do, and not before.
This isn't even a hypothetical pattern.
Imagine if Facebook worked like a SCADA dashboard. You'd log in every morning, scroll through every post from every friend, every page, every group, sorted chronologically, and try to figure out which ones mattered. Nobody would use it. Instead Facebook watches the feed for you, decides what's worth your attention, and sends a notification when something genuinely needs you. That's the design pattern. The grid is not magical. The data volume is smaller than what Meta processes in a minute.
Imagine Facebook, but with two different operating models. One has three billion users. One would have zero.
Visibility is the foundation, not the ceiling
The industry spent twenty years building visibility. That was the right work. Utilities of all shapes and sizes needed it. Without it, none of what comes next is possible.
But visibility was always a means, not the end. The end is action. Catching the transformer before it fails. Reaching the engineer before the member calls. Closing the loop on the issue so it doesn't fall through the cracks. That doesn't happen on a dashboard. It happens in a notification, in an inbox, on a phone, in a workflow built around the fact that the staff doing the work are almost never sitting at a desk.
What's missing isn't the technology. It's grid software that starts from the fact that nobody is watching the screen.
