We previously introduced the knowledge-enabled operating model and the idea that knowledge readiness is more than moving information from one place to another. It should encompass designing work so people can use the right knowledge at the right moment. Addressing multiple aspects of an organization’s operating model (including its knowledge infrastructure) is central to helping practitioners use the right insights at the right time to support decision-making.
In our experience, though, when utilities roll out new technology, change a workflow or respond to regulatory requirements, the familiar response is to build more documentation and schedule more training. Those tools matter, but they are often used to solve problems that start elsewhere. If the workflow is confusing, the system allows too much variation or the right action depends on memory under pressure, more training will not solve the issue efficiently.
Instead, organizations should start by asking whether the work itself is efficient and whether systems and workflows are designed to support the users. Training can then do the work it is best suited for: building judgment, confidence and readiness where the process or system cannot fully guide the user.
Why Training Becomes the Default Answer
Defaulting to more documentation and training makes logical sense in that it is easier to assign someone to build a short video than it is to update a technology or redesign a workflow.
The problem is that training often addresses visible symptoms rather than the source of the issue. When execution breaks down, it is rarely because the workforce suddenly lost capability. More often, the operating environment has become too complex, fragmented or dependent on local knowledge to navigate consistently.
For example, if a field crew is expected to capture asset information in a new mobile tool, the question should not be, “Did we train them on every field?” A better question is, “Does the workflow make the required action obvious, prevent avoidable errors, and support the crew when conditions in the field do not match the clean process map?”
A stronger and more durable approach starts by making the work efficient and realistic, designing the systems to guide the user, and then implementing training to bridge any gaps.
Drive Work Processes to be Efficient and Realistic
Effective process and system design starts with operational reality. A common failure point in grid modernization and digital transformation efforts is designing around the documented ideal state instead of the operating reality. Utilities need to understand local workarounds, environmental constraints, crew experience, system limitations and the adjustments people make to get the job done.
That view of work should expose process issues, variation and legacy decisions before they are reinforced through technology or training. Teams should identify where work varies across groups, where handoffs reflect old constraints, and where steps persist based on old requirements. The purpose isn’t to standardize for its own sake but to decide which steps and variations still serve the business and are worth investing resources into encoding into systems and training.
This is especially important when utilities move legacy work into new digital platforms. Re-creating a manual, inefficient workflow in a modern system does not necessarily improve performance; it may just make the variation faster.
Use Systems to Guide the User
In physical safety, industrial organizations rely on a hierarchy of controls. They either remove the hazard or engineer controls into the environment before relying on administrative rules. The same logic applies to knowledge work. Utilities should remove or “engineer out” operational risk before relying on people to compensate for weak process or system design.
In the case of technology-enabled processes, once unnecessary steps are removed, the system should carry as much of the remaining burden as possible. Required fields, default values, validation checks, structured inputs and guided workflows can prevent common errors before they happen. Analog processes can achieve the same outcome by making the preferred path visible and hard to avoid. For example, a material staging checklist enables a crew to order and bundle the right items for a job, decreasing the likelihood that the crew misses a critical part or tool. In both cases, the design lessens cognitive load by making the right action easier to identify, easier to take and harder to miss.
Designing for Behavior When Performance Relies on Judgment
There will always be operational scenarios in which judgment cannot be engineered out of the workflow. A crew might encounter field conditions that do not match the record, an operator might need to act with incomplete information, or a supervisor might need to interpret a standard in a context the procedure did not anticipate.
In moments like those, the system should help the user apply judgment by surfacing relevant information, highlighting exceptions, clarifying options and making deviations visible.
Training then has a clearer and more valuable role: building the judgment and confidence people need when the work cannot be fully scripted. These kinds of system design decisions reduce unnecessary cognitive load, leaving people more bandwidth for the decisions that remain.
Train for Critical, Judgment-Dependent Tasks
Once the work has been simplified, structured and supported, training becomes a precision tool. Given limited training budgets and time, training should be treated as a last-mile solution to build capability for interpretation, application, decision-making and adaptation where the process and system cannot fully guide the work. Training should also focus on tasks that carry meaningful risk if performed incorrectly, whether that risk affects safety, compliance, data quality, customers or continuity.
Organizations also need to separate the concepts of documentation (the definition of what has to be done) from training (the process of building knowledge and skills). Utilities often package technical reference material, regulatory rules, data standards and process detail into courses and assume that exposure confers capability.
Documentation should live in the knowledge infrastructure, where people can access it at the point of need. Training can then teach people to leverage these materials during the execution of work, focusing on application and decision-making. If a training program is mostly explaining reference material, the organization may have a knowledge access problem rather than a training problem.
Before defaulting to training, utilities can use a simple filter to decide what belongs in the process, what belongs in the system or workflow, and what truly requires human judgment.
Conclusion
Utility operating environments are constantly evolving. Processes change, software platforms are updated, roles shift and experienced employees leave with context that was never fully captured.
These dynamics create knowledge risk and make consistent execution harder to sustain, but utilities cannot train their way out of constant change. If every process update, system release and role transition depends on people remembering more, the model will eventually break down.
Sustainable capability requires a different starting point. Utilities need workflows that are easier to execute, systems that support performance, knowledge infrastructure that supports the point of need, and training that is reserved for the judgment-dependent work where it can actually help.
This post is part of a series sharing perspectives about successfully navigating utility transformation. Learn more: