Eight months after a cartoning line goes live, the customer rings. They want a new carton size added to the recipe table. The engineer who programmed the line left in spring. A colleague opens the project folder on the office server and loads it onto a spare CPU. The rung comments are half missing, two function blocks do not match what the machine is doing, and the servo parameters are nowhere. What should be a morning becomes three days on site, mostly spent reading the running program back line by line.
Nobody did anything wrong in the usual sense. The engineer simply made dozens of online edits during commissioning, as everyone does, and the final version lived on one laptop. This is the commonest people risk in controls work, and it is cheap to close once the firm sees it as an HR design question rather than an engineering habit.
How it shows up before anyone resigns
- Project folders hold files called final, final2 and final_site_new, with no note of which one runs the machine.
- Every service call for one customer is routed to a single mobile number, whatever the fault.
- Drive and robot parameter backups exist only inside the drive or the controller cabinet.
- HMI and controller passwords are known by one person and written nowhere official.
- The red-pen markups on the electrical drawings stay in a site diary and never reach the drawing office.
- Fault history sits in a phone chat between the engineer and the customer's maintenance foreman.
Any two of these on a live account mean that account depends on one head. Owners tend to discover this only when the resignation lands.
What the gap costs
The obvious cost is unbillable diagnosis. Days spent reverse-reading a program are days not spent on the next job, and the senior engineer pulled in to help is usually the one already overloaded. Warranty visits stretch because nobody knows which change caused which symptom. Customers notice quickly. A maintenance head who waited three days for a recipe change starts asking other integrators for quotes on the annual service contract.
A second, quieter bill arrives as well. An engineer who knows they are the only route into a key customer's line holds real bargaining power. Most never use it deliberately. But pay conversations with that person are lopsided, and the owner ends up matching outside offers out of fear rather than judgement.
Reverse-reading itself is grim work. A colleague uploads the running program and compares it rung by rung against the archive. Symbol names come back as bare addresses. Comments vanish. Indirect addressing hides which recipe slot drives which servo axis. Every discovery gets scribbled on paper, because nobody trusts the archive any more.
Why it keeps happening
Small integrators staff each job one engineer deep, because the bench is thin and margins are tight. The commissioning rush rewards speed, and online edits are the fastest way to get a sequence running. Closure is tied to the invoice and the customer's signature, not to the state of the archive. Documentation has no hours in the estimate, so it gets done at night or not at all. And no single person owns the master copy, so everyone assumes someone else will tidy it.
No villain appears in this list. Each item is a gap in role design, workload planning or the definition of closure. So the fix belongs to the owner as much as to the technical head.
What to check first
Pick the last five jobs your firm closed. For each, ask an engineer who never touched it to restore the running program, HMI application and drive parameters. They may use only the server, plus a simulator or spare hardware. Time-box it to a couple of hours per job. Write down what was missing: comments, a parameter file, a password, a library version, the as-built drawing. That list is your real exposure, and it usually surprises people.
Six moves that close the gap
- 1
Name a second engineer at kickoff
The second name attends the design review and the factory test, and takes at least one site visit. Writing the code is not their job. Understanding it well enough to support it is.
- 2
Set one master-copy rule
Each job has one server folder. Any edit made on site is uploaded and logged with date, author and reason before the engineer leaves the plant that day, or the next morning at the latest.
- 3
Review the program before FAT
A colleague walks through the logic, tag naming and comments with the author for an hour or two. It catches errors and spreads understanding at the same time.
- 4
Write a short handover note at FAT and again at SAT
Network addresses, passwords held in the agreed vault, parameter backups, known quirks, open punch points and the customer contacts who matter. One page per stage is enough.
- 5
Make a restore test part of closure
Before the job is marked closed, the second engineer restores everything from the archive. If it fails, the job stays open, whatever the invoice status.
- 6
Share the service calls
Route some warranty calls to the second engineer from the start, with the author on standby. Customers learn there are two names, and the second engineer learns the line.
Making the habit stick
Rules like these fade unless they are part of how people are judged and paid. Put the restore test into the closure checklist that releases any project bonus. Mention well-documented jobs in the monthly review by name. Add documentation hours as a line in every estimate, so the engineer is not stealing time from the customer to do it. The technical head checks one archive at random each month and reports what was missing.
Integrators that build robot cells and firms that run SCADA systems face the same gap in different forms. The documentation guidance for robot integrators and the version for SCADA companies show how each trade sets out its packs. Our wider HR documentation process service handles the people side: who owns which record and how it is checked. The trade's other recurring patterns are collected on our industrial automation hub page.
When an engineer has already resigned
The notice period is the last chance, so plan it on day one. List every live account where the leaver is the only name. Pair each with a successor, and schedule restore tests and joint calls before the final fortnight, not in it. Our exit checklist and handover note gives a starting format. If the risk sits across several customers, the owner-level view in how to reduce single-engineer risk is the next read.
