A PLC fault stops a line during the night shift. The maintenance team is present, the controls team is on call and the operating procedures are available. Yet the only person who understands the program’s change history won’t be back until morning.
The plant is staffed. The system isn’t covered.
That distinction matters because automation can hide personnel risk behind stable production. When equipment runs normally, a single employee may continue handling every difficult alarm, software change, restore and vendor conversation. The dependency becomes visible only when that person can’t respond.
Why headcount hides capability concentration
An organization chart shows who works in maintenance, engineering, operations and IT. It doesn’t show who can recover a robot cell after a failed update or explain why a historian was configured around an old network limitation.
That knowledge is rarely contained in one neat procedure. Part of it may sit in configuration backups and service records. The rest may include diagnostic habits, access permissions, vendor contacts, earlier modifications and workarounds that were never formally documented.
Automation also keeps changing the division of work. As Automation.com has previously discussed, changing automation roles and skills can’t be understood by counting positions alone. A plant may employ several controls engineers while still depending on one of them for a particular PLC platform or legacy interface.
NIST offered a useful way to think about the problem when it finalized SP 1308 on March 23, 2026. The guide says workforce decisions should reflect actual risks and planned responses, with capabilities adjusted as technologies and threats change. SP 1308 addresses cybersecurity, enterprise risk and workforce management. It isn’t an industrial staffing rule. Still, the underlying question travels well: does the workforce available at the time of a problem match the response the organization expects?
Define critical systems and minimum coverage
Start with the system rather than the employee. List the automated systems whose loss could affect safety, product quality, production, environmental controls or recovery time. Depending on the facility, that list might include a PLC-controlled process, safety system, robot cell, historian, supervisory platform or an interface connecting newer equipment to a legacy application.
Then define the minimum response each system requires. “PLC knowledge” is too broad to be useful. The plant may need someone who can recognize the failure, collect the right diagnostic information, restore an approved backup, contact the appropriate specialist and document what happened. Making an authorized program change is a separate capability and may belong to a different person.
The federal CareerOneStop model for advanced-manufacturing maintenance, installation and repair illustrates how specific the work can become. Its competency areas include diagnosis and repair, equipment upgrades, technical documentation, shift pass-down, programmable logic-controlled equipment, process controls, alarm analysis and root-cause work.
This is where managers need to resist a tidy but expensive assumption. Every system doesn’t require an expert on every shift. Some need an on-shift operator who can identify the fault and escalate safely. Others need a maintenance technician who can restore service from an approved state. A smaller group may justify immediate access to a controls specialist.
The required coverage should follow the consequence of delay.
Measure the one-person gap across shifts and sites
Once those requirements are defined, compare them with the people who can actually perform the work. Do this by system, shift and site. A facility with three qualified employees can still have a night-shift gap if all three work during the day.
A shift-level competency gap analysis can compare the minimum coverage each critical system requires with the demonstrated capability available across people, shifts and sites. The comparison should reveal where one employee remains the sole source of support, where nominal backups share the same schedule and where another location could provide help.
Keep the capability levels concrete. “Familiar with the system” could mean someone attended a course, watched a repair, or has performed the task under supervision. Those aren’t interchangeable. Test whether backup coverage is real A second name in a matrix is a starting point. The stronger evidence comes from seeing what that person can do.
Testing doesn’t mean creating a fault on a running line. Plants can use supervised troubleshooting, approved test environments, tabletop scenarios, backup reviews and planned maintenance windows. The exercise should match the expected response without introducing a new production or safety risk.
Ask the backup employee to locate the current documentation and configuration files. Can they identify the approved restore point? Do they have the required access? Can they explain when to stop and escalate? If outside support is part of the plan, can they find the service details and provide the information the vendor will need?
The most revealing problems are often mundane. A procedure refers to an obsolete server name. A configuration file is available, but the employee can’t access it. The vendor contract covers business hours while the assumed failure scenario occurs overnight. Training should also resemble the equipment people will support. Automation.com’s coverage of hands-on robotics training makes the practical point: operating, programming and maintenance capability develops through work with the technology, not through abstract awareness alone.
Any exercise must follow plant safety procedures, access rules, management-of-change controls and production restrictions. A coverage test that bypasses those controls proves the wrong thing.
Prioritize redundancy where absence hurts most
Most plants won’t have the time or budget to duplicate every specialist skill. They don’t need to. Rank each gap using three questions. What happens if support is unavailable? How quickly must the plant respond? How difficult would it be to transfer or replace the knowledge?
A safety-related system with a short response window deserves different treatment from a reporting application that can wait until the following morning. A widely supported platform may allow dependable vendor escalation. A custom legacy integration with poor documentation may require an internal backup because outside help can’t reconstruct years of local decisions quickly.
The strongest coverage plan usually identifies a primary owner, a backup with defined abilities and an escalation route. The backup doesn’t always need the primary employee’s full depth of knowledge. They do need enough skill and authority to carry out the response assigned to them.
Succession belongs in this discussion too. NIST’s workforce guidance advises organizations to create succession plans for all key positions, including workforce roles. For an automated plant, that principle should extend to system-specific capability. A job title may have several possible successors while a particular integration still has none.
Keep coverage current after the plant changes
Capability maps age faster than most managers expect. A controller upgrade can change the diagnostic process. A new integration can make yesterday’s backup incomplete.
Review coverage after those events instead of relying only on an annual training cycle. Incidents and near misses should trigger another look as well. If a response depended on one person, an undocumented step, or an unexpected permission, the coverage record needs to change.
Give someone ownership of the review. That person should confirm the requirements, supporting evidence, documentation, access and escalation routes. Without an owner, the matrix tends to preserve old confidence long after the operating conditions have moved on.
This is also why manufacturing training and readiness need to stay connected. Training completion records what an employee did in the past. Readiness asks whether that employee can perform the required response now.
Coverage exists only when it works
Automated plants will always depend on specialist knowledge. The goal isn’t to make every employee interchangeable or eliminate the value of deep expertise. The practical test is simpler: if the primary specialist is unavailable, can another appropriately qualified and authorized person carry out the defined response under the conditions in which it will be needed? Until the answer is supported by current evidence, the plant doesn’t have backup coverage. It has another name on a list.
