When a Tech Leaves, So Does the Building

There’s a guy on every campus who knows the building. Not the drawings — the building. He knows the breaker that’s mislabeled, the valve that has to be cracked before the other one, the unit that trips if you restart it too fast, and the fact that the east wing air handler was rebuilt in 2014 by a contractor who cut a corner nobody documented.

He retires, or takes a job across town, and on his last Friday your building becomes 30% less operable. Not gradually. Immediately.

This is a risk, not a personnel story

Facilities departments treat turnover as an HR event — post the job, interview, hire, train. What actually happened is that a single point of failure failed, and the department had no redundancy for it.

If a critical piece of equipment had one control board with no spare and no documentation, you’d call that a risk and do something about it. The same condition in a person gets called experience and celebrated.

Both things can be true. Experience is real and valuable. It’s also, undocumented, a liability sitting on your org chart.

The exit interview doesn’t work

The standard response is to schedule a knowledge transfer. Two weeks of walking the campus with the replacement, or a couple of sessions where the departing tech “writes everything down.”

It fails, every time, for a reason that isn’t anybody’s fault: people can’t inventory their own expertise. Twenty years of accumulated judgment doesn’t come out on demand. Ask him what you need to know and he’ll tell you the six things he happens to think of. The other four hundred surface only when the situation arises — and by then he’s gone.

Knowledge transfer at the exit is triage. The capture has to have been happening all along.

Capture it as a byproduct of the work

The only mechanism that reliably captures tribal knowledge is the record of the work itself — because the work is where the knowledge is being used.

Which is why how a work order gets closed matters more than most departments treat it. Compare:

Fixed.

Unit was short-cycling. Found the low-pressure switch tripping on startup — same as last summer. Root cause is the liquid line filter loading up faster than the PM interval. Replaced the drier, reset, monitored 20 minutes, stable. This unit needs the drier at 6 months, not 12. Third time I’ve seen it.

The second one took ninety seconds to write. It contains a diagnosis, a root cause, a history, and a maintenance recommendation. If that tech leaves tomorrow, the next person opens the asset record and inherits three summers of pattern recognition.

The first one preserves nothing. And the first one is what most systems accept.

Why techs write “fixed”

Not laziness. Three real reasons:

  • Nobody ever reads it. Writing into a void is demoralizing. If notes never come back up in a conversation, the message is that they don’t matter.
  • The system makes it optional. Anything optional at 4:45 on a Friday doesn’t happen. That’s not a character flaw, it’s a design flaw.
  • It’s been used against them. If detailed notes have ever become the basis for second-guessing, the rational response is to write less.

All three are fixable, and all three are on the manager, not the technician.

Three things to change

  1. Make the note a condition of closing. Not encouraged — required. A job that can be closed with two words will be. This is the single highest-leverage change available to a facilities department, and it costs nothing.
  2. Read them out loud. In your weekly huddle, pull one good close-out and say why it was good. Notes get written when writers know they have readers.
  3. Attach everything to the asset. A note on a work order that isn’t linked to equipment is a note nobody will ever find again. The asset record is where knowledge accumulates into history.

The test

Pick your most experienced technician and ask yourself honestly: if he gave notice this afternoon, what would we lose that isn’t written down anywhere?

Whatever comes to mind is the gap. It won’t close in two weeks of exit interviews. It closes one work order at a time, starting with the ones being written today.

Try MaintenanceOps

MaintenanceOps is work order software built around documentation integrity — enforced labor notes, stamped and attributed actions, and an audit trail that holds up when someone asks what happened.

See how it works → · Request more information →

Share your thoughts or opinion

Discover more from Maintenance Ops

Subscribe now to keep reading and get access to the full archive.

Continue reading