"Who fixed it last time?" If the answer is…

In October 2026, Delin S. asked on LinkedIn how maintenance leaders find their repeat-offender machines. One of the replies, from Teodora Terzieva, reduced the whole problem to one question and one test:

"Who fixed it last time? If the answer is a name and not a record, that knowledge goes on holiday every time the person does." (Teodora Terzieva, comment on Delin S.'s public LinkedIn post)

She ended with a question of her own: "What happens in your plant when your best technician is off?" Swap "off" for "retired" and the holiday becomes permanent.

Short answer: If "who fixed it last time?" is answered with a person's name, the fix only exists while that person is reachable. Holidays, shift changes and retirement switch it off. The remedy is not a bigger manual. It is a findable record per fix: machine, fault as displayed, what was checked, what worked, and the sensory cue, written as a number.

Applies to: maintenance and field service teams, in plants and at machine builders, OEMs, dealers and AMC contractors, where one or two senior technicians are the usual answer to "what did we do last time?". Last verified: 11 Nov 2026. Author: Muhammed Fahiz

What does "a name, not a record" look like on the shop floor?

It looks like a phone call instead of a search. The machine trips, the junior technician on shift doesn't recognise it, and the first question is who was here last time. If that person answers the phone, the job goes well. If they are on leave, on another site or retired, the job starts from zero.

Charles Baxley described the same moment in a public LinkedIn post: "Then three days later the same machine goes down. 'What did we do last time?' Nobody remembers." We wrote about that close-out habit in "It's running now" is not a fix.

Delin S.'s original post lists what follows when repair history "lives on paper, in scattered files, or in someone's head". One of the items is "Technicians start from zero every time." His summary line is the one we keep coming back to: "A repair you cannot look up is a repair you are likely to repeat."

A name is not useless. It tells you who to ask. But it is a pointer to a memory, and a memory has office hours.

What actually leaves when a senior technician retires?

Mostly the things that were never written down because they felt obvious to the person who knew them. Ayesha Ashraf relayed a plant manager's account in a public LinkedIn post in August 2026:

"A plant manager once mentioned that when their most senior technician retired, half the "process" left with him. Nothing was written down. It just lived in his head." (Ayesha Ashraf, public LinkedIn post)

That is a second-hand account, and "half" is the plant manager's estimate, not a measurement. The shape of it is familiar, though.

Yasser Mansour Ahmed, who describes moving from maintenance technician to senior technician to mechanical maintenance supervisor, listed the kind of knowledge he means in a public LinkedIn post in September 2026. The technician who remembers:

"Don't trust that reading immediately." "This pump behaves differently after a long shutdown." "We had this problem before - check this area first." "That vibration has a history." (Yasser Mansour Ahmed, public LinkedIn post)

His verdict: "That knowledge is rarely written down completely."

Deanna Nesbit, who runs an executive search firm with a niche in the crane industry, made the same point from the hiring side in an October 2026 post. Senior technicians "know which units drift out of spec", and "most of it isn't even on their radar as 'things I should teach someone' - it's just how they work." She is a recruiter, so read that as an observation about hiring, not field data.

None of these four posts gives a number you could plan around, and we haven't found a study that measures how much repair knowledge leaves with a retirement. What they agree on is the type of knowledge that goes: machine-specific, learned from past failures, and carried in someone's head because nobody asked for it to be written.

Industrial gear reducer on a cast base coupled to an electric motor, with a mechanic's stethoscope and a torque wrench resting on the housing, one foot-mounting bolt shaded blue, and a closed troubleshooting manual on a stand beside it

Why doesn't the manual already cover it?

Because the manual describes the machine as designed, and this knowledge describes one machine as it has actually behaved. Gyanendra Pandey, who works as a technical and operations trainer, gave the clearest example in a public LinkedIn post in September 2026:

"A machine starts vibrating. A junior technician reads the troubleshooting manual, checks the steps, and finds nothing. A senior technician walks up, touches the casing, listens to the pitch, and tightens one specific bolt by feel. The vibration stops." (Gyanendra Pandey, public LinkedIn post)

His post opens with "Your most valuable maintenance procedures are not in the OEM manuals," and later adds: "The problem is that 'how it feels' cannot be scheduled or scaled."

Yasser Mansour Ahmed's post makes the same split. After the expert leaves, "The machine keeps running. The drawings are still there. The manuals are still there. The CMMS still has its records. But something important may be missing."

So there are three places a fix can live:

Where the knowledge sits	What it covers	What happens when the senior tech is away
OEM manual	Every listed cause for the model, written before the machine shipped	Still there, but it is the list Pandey's junior already checked
A senior technician's memory	Which cause it usually is on this machine, and the cue that gives it away	Gone for the shift, the holiday or for good
Your own service records	What was found and done on this serial, if someone wrote it	Still there, if the record holds the cue and can be found

The third row is the only one you control. It is also the one that is usually thin.

Can "by feel" knowledge go into a record at all?

Some of it can, if it is written as something the next person can check. Pandey's own answer, in the same post, is to "translate sensory cues - like acoustic feedback or specific resistance - into measurable metrics like torque values and clearance specifications." He also says this "requires moving beyond standard exit interviews and actually observing the wrench-in-hand adjustments on the floor."

That translation is the useful bit. "Tightened the loose bolt" helps nobody. An invented example of the alternative: "Vibration on the gearbox side; found the outboard foot bolt below spec; torqued to the value in the manual; vibration back to normal" gives the next technician a place to start, and the senior technician doesn't need to be there.

Here is how the four remarks in Yasser Mansour Ahmed's list could turn into fields. The quotes are his; the right-hand columns are our suggestion, not his.

What the senior tech says	What to write in the record	Which field holds it
"Don't trust that reading immediately."	Which reading, on which instrument, and what to do instead (wait time, second reading, reference point)	Checks and readings, with a note on the method
"This pump behaves differently after a long shutdown."	The asset ID, the condition (after shutdown of how long, if known), the symptom, and what was done	Machine identity + trip / symptom conditions
"We had this problem before - check this area first."	A link to, or the number of, the earlier report on the same serial, and the area that turned out to matter	Previous visit / related report + cause found
"That vibration has a history."	Each earlier vibration job on that asset, with readings and what was changed	Machine history, searchable by asset ID and symptom

A record like that doesn't replace the person. It makes their answer available when they are not.

How do you test whether your records pass the "name, not a record" test?

Take Terzieva's question literally and try to answer it without asking anyone. This is a check we'd suggest, not a published method.

Pick five recent repeat jobs. Machines that came back with the same fault, from your breakdown register, job cards or service reports. If you can't find five, that is already a result. (How to spot repeat breakdowns in mixed records covers the grouping.)
For each one, find the previous visit from the records alone. No phone calls, no asking around. Use only the files your team would actually search.
Write down what you found. For each previous visit: did it name the machine (asset ID or serial), the fault as displayed, what was checked, what worked, and the parts?
Count the answers that were a name. Every time the only way forward was to ask a person, mark it.
Ask the named person what was missing. When they tell you the cue (which bolt, which reading, which sound), put it into the record for that serial, then and there.

If most answers in step 4 were a name, the problem isn't your search tool. It is what gets written at close-out, and where it gets filed. Our posts on the service engineer job card format and the field service report template list the fields that make the next lookup possible.

Roll slitter-rewinder machine with a clear document pocket of blank sheets fixed to its side guard and a blank nameplate, and an open record book with blank ruled pages and a pen on a steel stand in front

What should you capture before a senior technician leaves?

Capture fixes against machines, not a general interview. An exit conversation tends to produce stories. What the next technician needs is the story attached to the asset ID and the fault code they will be staring at. A practical order:

List their machines. Which assets do people call this person about? That list is the scope.
Walk each machine with them. Pandey's point about observing "wrench-in-hand adjustments on the floor" applies here. Ask what they check first on this machine, and why.
Write the cue as a check. A reading, a torque, a clearance, a position, a sound with a condition ("knock only after a cold start"). If they can't give a number, write what they do and mark it "value not confirmed."
Tie it to the old reports. If an earlier job card or service report covers the same fault, link it or note its number. That turns "check this area first" into a record someone can find.
Let a junior do the next one from the record. The first time the fault comes back, the junior works from the written note while the senior is still around to correct it.

The same applies to the person who is merely on leave. Terzieva's holiday version is the cheap rehearsal for the retirement version.

Is this really a memory problem?

Partly. Not everyone in the thread agreed. Kevin Bruce replied to Delin S.'s post: "This is not a memory problem. This is process failure problem. That's a lack of accountability." Dave Trevor-Roberts wrote that when a machine has no downtime or redundancy and maintenance is always reactive, "You will never be able to eliminate the root causes, even if you have records and resources."

Both are fair. A record doesn't fix a process that keeps damaging the machine, and it doesn't create downtime windows. What it does is stop the same diagnosis being done from scratch every time the person who did it last isn't there. Andrew Nonchev put the precondition plainly in the same thread: "If a repair isn't tied to an asset ID and a failure code, you cant search for it, and if you cant search for it you never see it repeating."

What this doesn't tell you

All the quotes here are public LinkedIn posts and comments, each one person's view. Ashraf's is a second-hand account; Nesbit writes as a recruiter; Pandey writes as a trainer. None reports a measured loss. We found no study that measures how much repair knowledge leaves with a retiring technician, so this post doesn't give a figure. The tables translating remarks into fields and the five-job check are our suggestions.

Where does HangerSearch fit?

Once the fix is written down, the next problem is finding it when the same machine is down and the person who wrote it isn't answering. If your old service reports are hard to search for other reasons (scans, mixed wording, files in several places), see why searching service reports is a data problem. And for the wider case of an alarm someone solved years ago, see the alarm someone already solved three years ago.

HangerSearch is private, retrieval-only search over your team's own finalized service reports, searched where they already sit. You search by fault code, model or symptom. It shows the earlier reports that match and why each one matched, and opens the cited page. Nothing is generated, and if there is no similar report, it says so. It can't recover a cue nobody wrote down, which is why the record comes first. See how we handle your reports.

Book a 20-minute demo: hangersearch.com

FAQ

What does "if the answer is a name, not a record" mean?

It is Teodora Terzieva's test from a comment on a public LinkedIn post: if the only answer to "who fixed it last time?" is a person, the fix is only available while that person is. When they are on leave or retire, the next technician starts from zero.

How do you capture maintenance knowledge before a technician retires?

Work machine by machine. List the assets people call them about, walk each one with them, write each cue as a check (a reading, torque or clearance where possible), and link it to the earlier job card or service report for that serial. Then let a junior handle the next repeat from the record.

Can tacit "by feel" knowledge be written down?

Some of it. Gyanendra Pandey's suggestion is to translate sensory cues such as sound or resistance into measurable values like torque and clearance. Where no value is known, write what was done and mark it "value not confirmed", so the next technician knows it still needs checking.

Isn't the OEM manual enough?

The manual lists the possible causes for the model. It can't say which cause it usually is on your machine, or which cue gives it away. That knowledge comes from your own service history, if it was written down and can be found.

Sources

Delin S., public LinkedIn post, "Maintenance keeps fixing, but the same machine keeps breaking." (11 Oct 2026), with comments by Teodora Terzieva, Kevin Bruce, Dave Trevor-Roberts and Andrew Nonchev (12 Oct 2026): https://www.linkedin.com/posts/delinsirkov_maintenance-cmms-reliability-activity-7514852511011463168-0mhw. Reopened logged out 11 Nov 2026. Supports: the opening quote and question, the Delin S. quotes, and the dissenting and data-side comments.
Gyanendra Pandey, public LinkedIn post, "Your most valuable maintenance procedures are not in the OEM manuals." (28 Sep 2026): https://www.linkedin.com/posts/gyanendra-pandey-planthead_your-most-valuable-maintenance-procedures-activity-7510194524120506368-WEiV. Reopened 11 Nov 2026. Supports: the junior/senior vibration example, the "how it feels" line, observing adjustments, and translating cues into measurable values.
Ayesha Ashraf, public LinkedIn post, "A plant manager once mentioned that when their most senior technician retired..." (Aug 2026): https://www.linkedin.com/posts/ayeshasdr_a-plant-manager-once-mentioned-that-when-activity-7499188997156564992-SkA8. Reopened 11 Nov 2026. Supports: the second-hand retirement account.
Yasser Mansour Ahmed, public LinkedIn post, "What happens to a machine when the person who knows it best leaves?" (12 Sep 2026): https://www.linkedin.com/posts/yasser-mansour-ahmed-a13ab2422_industrialmaintenance-mechanicalmaintenance-activity-7504474840813314050-2cyj. Reopened 11 Nov 2026. Supports: the four remarks, "rarely written down completely", and the manuals/CMMS line.
Deanna Nesbit, public LinkedIn post, "Your best crane tech has 20 years of knowledge." (1 Oct 2026): https://www.linkedin.com/posts/deanna-nesbit-4645977_your-best-crane-tech-has-20-years-of-knowledge-activity-7511424952949207040-HVo-. Reopened 11 Nov 2026. Supports: the "drift out of spec" and "just how they work" quotes. Recruiter post; context, not field data.
Charles Baxley, public LinkedIn post, "One of the worst answers you can hear after a breakdown is: 'It's running now.'" (2 Sep 2026): https://www.linkedin.com/posts/charles-baxley80_one-of-the-worst-answers-you-can-hear-after-activity-7500832090196758528-GACa. Supports: the "Nobody remembers" quote.

"Who fixed it last time?" If the answer is a name, not a record