If you manage people in the power business, the old picture is gone. Software no longer sits quietly behind the scenes. Operators still run the control room, planners still build the cases, market teams still place the bids, and IT still keeps the servers alive. But those functions now depend on software that must work together under time pressure. Grid operations, transmission planning, outage scheduling, interconnection studies, market clearing, forecasting, and customer-facing commitments are increasingly tied to the quality of the code and data behind them.
What changed is not just the volume of data. It is the cost of bad handoffs. This month, the Federal Energy Regulatory Commission put software squarely in view again with its July 2026 technical conference on improving market and planning efficiency through better software. FERC is not treating that as a side project. The conference agenda goes straight to grid-enhancing technology software, load forecasting, faster load interconnection assessments, and market-clearing performance. For middle and senior managers, the signal is clear: software is now a leadership issue. It belongs in operating reviews, staffing decisions, capital planning, and risk management.
Software Is Now Part of the Operating Model
Many utilities still talk about software as if it were only a tool-selection issue: pick the vendor, fund the project, survive the rollout, and move on. That approach breaks down when software is embedded in core operating decisions. The market-clearing engine, the state estimator, the outage scheduler, the planning model, the forecasting stack, and the data paths among them all shape what the company can see and act on.
FERC’s software effort makes that point plainly. The agency says it is identifying opportunities to improve efficiency in jurisdictional markets by encouraging RTOs and ISOs to consider new modeling software for market operations. The point is direct: better computational methods and better ways to optimize utility assets can improve operational efficiency for customers. That is not an IT statement. It is an operating statement.
Managers need to treat software the same way they treat a substation relay setting or an outage switching plan. If the model is wrong, stale, or too slow, the result is not just an inconvenient screen. It may be a missed dispatch opportunity, a late study, a non-credible outage plan, a pricing error, or an avoidable reliability risk. That changes who owns the problem. The software team cannot carry it alone, and operations cannot keep treating code as someone else’s department.
Speed Without Discipline Creates New Failure Modes
One reason this topic matters now is that the industry is under pressure to move faster almost everywhere at once. Interconnection queues are clogged. Large-load requests are piling up. Transmission plans are becoming more complex. Operators are dealing with tighter operating conditions and more variable resources. That pressure creates demand for faster software, but speed by itself can make a mess.
Look at the themes FERC put into this year’s conference. Day one includes grid-enhancing technology software and load forecasting. Day two includes work on end-to-end load interconnection assessment automation and market-clearing improvements. One presentation summary says automated load interconnection assessment, with full AC optimal power flow enabled, can support bridging-solution analysis at least three times faster. Another points to reducing nonbinding constraints to improve security-constrained unit commitment performance. These are not abstract gains. They aim at the bottlenecks managers are fighting right now.
But faster software also raises a management question: faster toward what standard? If teams rush automation without clean data, clear model governance, and a firm change process, they can move bad assumptions through the system more quickly. A sloppy manual process is slow. A sloppy automated process is fast and harder to catch. The manager’s job is not to applaud every acceleration claim. It is to ask where the data comes from, who validates it, how exceptions are handled, and what happens when the model result does not match operating reality.
The Real Issue Is Integration, Not Just Better Tools
Most utilities do not suffer from a lack of software. They suffer from too many systems that do not line up cleanly. Planning may use one data structure. Operations may use another. Market systems may rely on a third. Field and asset teams may update conditions in a work system that never reaches the planning model in time. Then managers end up in meetings where every slide uses a different version of the truth.
This is where software turns into a management problem before it becomes a technical one. If your forecasting team, outage team, planning group, and operations group cannot point to the same source of assumptions, then your review process is already weak. If your staff cannot explain why a study case differs from the operating model, then the problem is not just data architecture. It is accountability.
The practical fix starts with governance plain enough to survive a bad day. Who owns the base data? Who signs off on model changes? Who decides whether a temporary workaround is safe? Who has authority to stop a release before a critical period? Without those answers, software programs become long-running projects that consume money and patience while operating groups work around them in spreadsheets and side files. Once that happens, the official system becomes theater, and the shadow process becomes the real control room.
Forecasting and Planning Need Closer Ties to Operations
FERC’s choice to pair load forecasting with software efficiency was not accidental. Forecasting is no longer a once-a-year exercise that feeds a planning binder. It now has to deal with faster load shifts, electrification, weather stress, changing customer behavior, and the timing noise that comes with new large loads and new resources. The forecast has to be useful to planners, operators, market teams, and executives making public commitments.
NERC’s 2026 Summer Reliability Assessment makes the operating side of this plain. The report says record resource additions have improved readiness, but it also points to elevated risks from rapid demand growth, low wind or solar conditions, and the overlap of heat with maintenance outages. That means the planning case and the operating case cannot drift too far apart. The company needs a trusted path from forecast to outage plan to operating limits.
Managers should ask one hard question in every review: when the forecast changes, where does that change go next, and how quickly? If the answer is vague, the process is weak. A strong process shows how revised assumptions reach transmission studies, outage approvals, market offers, reserve expectations, staffing plans, and external messaging. That does not require one giant system that does everything. It requires a disciplined chain of record and a management culture that does not tolerate silent assumption drift.
Market Software Is No Longer a Niche Concern
There was a time when market software could be treated as the problem of traders, the market monitor, or ISO staff. That is over. Market software now affects resource commitment, congestion outcomes, uplift, interconnection timing, and the public case for affordability. When market engines struggle, everybody feels it.
FERC has been working this software thread for years, and the reason is easy to see. Security-constrained unit commitment and optimal power flow are not academic exercises. They are the engines behind day-ahead and real-time decisions. If those engines are slow, overloaded with weak constraints, or disconnected from better data and better formulations, the system pays in higher costs or worse dispatch quality. For managers at utilities and market participants, software literacy is now part of leadership. Not coding. Not vendor jargon. Basic operating literacy: enough to ask good questions about model performance, solve times, exception handling, and the tradeoff between precision and speed.
The same goes for transmission planning software. Grid-enhancing technologies help only if the models can represent them cleanly and operators trust the outputs enough to use them. A tool that looks promising in a pilot but never makes it into the standing operating process has not solved much. Managers have to push past pilot theater and ask whether the software changed a real decision, shortened a real timeline, or reduced a real constraint.
Cyber and Reliability Are Joined at the Hip
There is another reason software now belongs in management meetings: the more the grid depends on connected systems and automated decision paths, the thinner the line becomes between software failure and reliability failure. Not every problem is a cyber event, but every serious cyber weakness now has an operating consequence.
NERC’s 2026 Critical Infrastructure Protection roadmap speaks in the language of risk reduction, resilience, and security, but utility managers should read it as a daily operating issue. A patch cycle, access-control gap, vendor remote connection, or weak change record is not just a compliance matter. It can affect trust in data, visibility during an event, and the ability to restore or reconfigure safely. The old view that cyber lives in one silo and reliability lives in another no longer matches how these systems work.
This has staffing implications. Utilities need managers who can bridge engineering, operations, and software governance. They do not all need to be cyber specialists. They do need to understand how software dependencies can fail and how those failures show up on the operating side. A manager who cannot explain which systems are mission-critical, what the fallback process is, and how long the organization can run without a given feed is flying blind.
What Managers Should Change This Year
Start with ownership. Every mission-critical software path should have a named business owner, not just a system administrator or vendor account representative. That owner should be accountable for data quality, user adoption, change approval, and fallback procedures. If ownership is spread so widely that no one can be held accountable, then no one is actually in charge.
Next, stop treating software projects as finished when they go live. Go-live is the start of the hard part. Managers should review whether the system shortened cycle time, reduced rework, cut model disputes, or improved operating confidence. If none of those outcomes changed, the project may have installed software without improving the business.
Then tighten release discipline around peak seasons and critical study windows. The power sector has always known not to tinker carelessly with equipment before a tight operating period. The same habit should apply to core software. That does not mean freezing progress forever. It means matching change windows to system risk and forcing exceptions through a sober review.
After that, train managers to ask plain questions. Which model is the source of record? What assumptions changed? What happens if the feed fails? How long does the run take? What work still lives outside the system? These questions sound simple because they are simple. They also expose weak controls faster than a polished project dashboard.
Last, tell the truth upward. If the integration is not finished, say it. If a deadline was met by moving work to manual patches and spreadsheet bridges, say it. Executives can handle hard facts better than false comfort. The companies that manage this period well will be the ones where middle managers refuse to confuse software installation with operating readiness.
Conclusion
The power business has entered a period in which software quality shapes operating quality. That reality is now impossible to separate from reliability, affordability, and public confidence. FERC’s July 2026 technical conference on better software for planning and markets, together with NERC’s warnings about faster growth, tighter conditions, and more complex operating patterns, points to the same conclusion: software is no longer a side system. It is part of the operating system of the grid.
For utility managers, the takeaway is direct. Do not leave software to the project office and hope it sorts itself out. Pull it into line management. Tie it to operating ownership. Demand cleaner data, clearer model governance, safer change control, and honest reporting on what still depends on manual work. The grid will still depend on steel, copper, gas, and people in hard hats, but more of the daily outcome now runs on code. The next reliability stress test will not ask whether the software was installed. It will ask whether management knew how to govern it, trust it, and act on it when the system was under pressure.