When the Veteran Technician Retires: Keeping Wastewater Repair Knowledge on Site
Manuals and work-order history survive a retirement. The reasoning that made someone fast at this plant usually does not. A practical guide to capturing the knowledge that decides how long a repair takes, while the repair is happening.
Working on a live operating problem? Book Your 20-Minute Assessment
Ask an experienced wastewater technician why a particular pump keeps tripping, and the answer is often not in the manual.
They may remember that the same motor ran hot two summers ago during a heat event. They may know which seal failed last time, which replacement did not seat properly, which isolation valve has to be checked first because it passes, and which change in the sound means shut it down now rather than watch it until morning.
That knowledge is valuable precisely because it was expensive. It was paid for in failed repairs, second call-outs, and nights that ran long. And most of it was never written down, because at the moment it was being formed the person holding it was busy fixing something.
This guide is about that gap: what specifically disappears, why the systems you already own do not hold it, and what a utility can do about it that does not depend on the person staying.
The problem is not the headcount
It is tempting to file this under workforce shortage. That framing is real but it points at the wrong remedy, because it implies the answer is hiring, and hiring does not transfer what the leaver knew.
The pressure is well documented. Black and Veatch’s 2026 Water Report, based on a survey of more than 600 United States water sector stakeholders, found that retirements across engineering, operations and technical roles are creating capital-delivery and technical-capacity risk, and that more than half of respondents, 55 percent, now outsource engineering and technical staff. Among respondents whose digital strategy is not achieving most or all of its objectives, 71 percent cite staffing as a barrier and 48 percent cite legacy data and systems.
But the sharper finding in the same report is about what the remaining systems actually contain. Asked to rate the quality of their asset information, only 7 percent rated the asset information in their enterprise asset management or computerised maintenance management system as very good. Only 8 percent said the same of asset operations and maintenance costs, and only 10 percent of asset condition and performance. Asset characteristics fared better at 19 percent. Across several categories, fewer respondents rated their information as very good in 2026 than in 2025.
That is the actual problem. Not that experienced people are leaving, but that the systems meant to outlast them were never holding the part that mattered.
The report’s own conclusion is unusually direct: as experienced staff retire, utilities need stronger processes and decision-support tools that turn what has lived in people’s heads into repeatable practice.
Four kinds of knowledge, and only two of them survive
It helps to be precise about what is being lost, because the four things below are routinely discussed as one thing and they behave completely differently.
Documented knowledge is the manual, the drawing, the procedure, the specification, the pump curve. It is authored once, it is accurate about the equipment as designed, and it survives any personnel change perfectly. Its weakness is that it describes a generic asset, not yours, and it goes stale silently the first time somebody rebuilds something with a substitute part.
Recorded knowledge is the work order, the failure code, the labour hours, the part number issued, the timestamps. This is what a CMMS is for and it does the job well. It answers what was done and when. It survives retirement completely.
Observed knowledge is what the technician actually perceived at the asset. The sound before the trip. The colour of the oil. The temperature by hand on the bearing housing. The photograph of the coupling taken because something looked off. Some of this is capturable and almost none of it is captured, because capturing it competes with doing the work.
Experienced knowledge is the pattern across events. This asset fails this way. That symptom means the other thing. The listed seal kit does not fit the 2021 rebuild. The supplier who answers on a Friday. This is the layer that makes somebody fast, it is built only over years, and it exists nowhere but in the person.
Put plainly:
A maintenance system preserves the record of the repair. It rarely preserves the reasoning that produced the repair.
The work order says the seal was replaced. It does not say that the technician first suspected the bearing, checked the coupling alignment, ruled out an electrical cause by looking at the trend, and only then concluded seal. That reasoning chain is the reusable asset, and it is the part that leaves.
What that costs, concretely
The cost shows up in three measurable places, and none of them appear on a retirement spreadsheet.
Time to first correct action goes up. A technician without the history starts by rebuilding the picture: pulling trends, searching work orders, hunting for the right manual revision, asking around. On an unfamiliar asset that is routinely the longest single phase of the response, and it happens before anything is diagnosed.
Repeat failures stop being recognised as repeats. The same fault recurring on an eighteen-month cycle is an obvious pattern to the person who saw it twice and invisible to everyone else, because in the CMMS it is three unremarkable work orders separated by a lot of other work orders. Nobody escalates it to a design or application problem because nobody sees it as one thing.
Wrong-part rates rise. Configuration drift is knowledge held in people. When the person who did the 2021 rebuild leaves, the fact that the installed configuration no longer matches the catalogue leaves with them, and the next repair discovers it by fitting the wrong part and mobilising twice.
Why the usual answers do not work
“We will have them write it up before they go.” Exit documentation captures what somebody can recall on demand, in an office, months after the last relevant event, with no asset in front of them. It reliably produces general advice and reliably misses the specific, which is the only part with value. It also arrives as a document nobody opens during an incident.
“We will do a formal shadowing programme.” Good, and worth doing, and it transfers to exactly the people who happen to be shadowing. It does not scale to a crew across shifts, it does not survive the shadow leaving in turn, and it depends on a failure conveniently occurring during the handover period.
“We will add fields to the CMMS.” This is the most common answer and the most consistently disappointing. Adding a free-text cause field to a work order asks a person to summarise their reasoning at the moment they most want to go home. What comes back is “replaced seal”, because that is a truthful and complete answer to the question the field asked. The field is not wrong. The moment is wrong.
“We will record video.” Occasionally excellent for a specific procedure. Useless as a retrieval system, because nobody can find the ninety seconds that matter inside four hours of footage eighteen months later.
The common failure in all four is timing. Each of them tries to capture knowledge either before it is being used or after it has been used, and the only moment it exists in a form worth capturing is while it is being used.
What should survive the repair
Here is a more useful design question than “how do we capture tribal knowledge”. Take one completed repair. What are the specific things a future person would need, and would not otherwise have?
What should survive one completed repair
Figure 1. What should survive one completed repair. A central hub labelled one completed repair, with the note that the record is not the reasoning. Around it are eight items: what failed and how it presented, what the evidence showed, what was checked, what was ruled out and why, what actually fixed it, which part was fitted and whether it seated, what delayed the work, and what to check first next time. These feed one outcome: the next crew to meet this fault starts here instead of starting over.
Look at the two items that carry the most value: what was ruled out, and what to check first next time.
What was ruled out is the single most efficient thing one technician can hand another, because it deletes work. Knowing that the previous investigation eliminated the electrical supply saves the next person an hour and a trip to the motor control centre. It is also the item most reliably absent from every system, because a work order records what was done, and ruling something out feels like nothing was done.
What to check first next time is a judgement, not a fact, and it is the compressed form of everything the technician learned. It is also the only field on that list a person can answer in fifteen seconds while walking away from a finished job.
A practical capture standard
The design constraint is fixed and non-negotiable: capture has to cost the technician close to nothing, at the moment of the work, or it will not happen. Everything below is built around that.
Capture at the asset, not at the desk. The record should be created where the work is, on whatever device is already in the person’s hand, and it should attach itself to the asset rather than to a document folder.
Accept the format the person actually produces. A voice note. A photograph of the failed component next to the nameplate. A ten-second video of the sound. A typed line. Requiring a form is requiring a translation step, and the translation step is where capture dies.
Ask the two high-value questions explicitly. What did you rule out, and what would you check first next time. Nobody volunteers these, and everybody can answer them.
Capture the blocker, not just the fix. If the job waited four hours for a part, that is a fact about your parts system, and it is only visible if somebody records it at the moment of waiting. Aggregated across a year it is the strongest evidence a maintenance manager has for a budget conversation.
Photograph the nameplate on every rebuild. This one habit does more for configuration accuracy than any data-cleansing project, because it timestamps what is actually installed against what the catalogue believes.
Attach it to the asset, not to the work order. Work orders are transactions and they close. Assets persist for forty years. Knowledge filed against a transaction is knowledge filed in a drawer that is about to be shut.
Retrieval is the harder half
Capture without retrieval is a bigger archive nobody reads, and most knowledge-management efforts fail on this side rather than the capture side.
The test is simple and worth applying to whatever you already have. It is 2 a.m., an asset has tripped, and a technician who has never touched it is standing in front of it. Can that person get, in under two minutes and without knowing what to search for, the last three things that happened to this asset, the reasoning behind them, what was ruled out, and what the last person said to check first?
If the answer requires knowing which system to open, the retrieval has failed regardless of how good the capture was. The knowledge has to arrive with the fault, unprompted, because the person who needs it does not know it exists.
That is also the honest reason the historical answer has been “ask Dave”. Dave was not a better database. Dave was better retrieval.
Where AIMMS fits
EQUA AIMMS is built around the capture-and-retrieval loop described above rather than around a knowledge repository. During a repair it holds the conversation, the evidence used, the findings, the steps taken, the part fitted, the blockers hit and the outcome, against the asset. When that asset faults again, that history is assembled into the working context automatically rather than waiting to be searched for, with each line naming the record it came from and how old it is.
Two boundaries are worth stating plainly, because they are the difference between this and a system that quietly replaces judgement. Qualified people diagnose and repair; nothing is concluded on their behalf, and likely causes are proposed for a person to accept or reject. And your existing systems of record stay authoritative, receiving only what you approve.
The point is not the retirement
Treating this as a succession problem makes it a project with an end date, and it is not one. A crew loses knowledge continuously: to shift patterns, to sick leave, to the contractor who did the work and left, to the simple fact that the person who fixed something eighteen months ago has fixed two hundred things since.
The utilities that handle the retirement wave well will not be the ones that ran the best exit interviews. They will be the ones that were already capturing reasoning as a by-product of doing the work, so that the departure of any individual is a loss of a colleague rather than a loss of capability.
Start with one asset class and the two questions. What did you rule out, and what would you check first next time. It costs almost nothing, and it is the part nobody has.
Sources
- Black and Veatch, 2026 Water Report, 15th annual edition, survey of more than 600 United States water sector stakeholders, June 2026. Figures cited: 55 percent outsourcing engineering and technical staff; 71 percent citing staffing as a barrier and 48 percent citing legacy data and systems among respondents not achieving most or all digital-strategy objectives; asset-information quality rated very good by 7 percent for enterprise asset management and computerised maintenance management system records, 8 percent for asset operations and maintenance costs, 10 percent for asset condition and performance, and 19 percent for asset characteristics.