There’s a particular kind of knowledge that lives only in the head of a senior engineer, and it dies when they do. I mean how this specific system behaves in production, why it was built the strange way it was, what the undocumented failure modes are, which warning signs come before which disasters, and how to fix the thing nobody else understands. Decades of it, earned through experience nobody can repeat, and almost none of it written down. Few things in this work bother me more.
When that engineer retires, the knowledge walks out the door.
When they die, it’s gone for good. I’ve watched it happen, and it’s a real loss to the company and to everyone who would have benefited from understanding what that person understood. A book is how you stop it from vanishing. I’m built to write that book. I ran enterprise technology for two decades, and I know exactly what kind of knowledge is worth saving.
The senior engineer carries decades of knowledge that exists nowhere but in their head. When they retire, it walks out the door. When they die, it’s gone. A book is how you save it.Share on X
Every long technical career produces a body of knowledge that no manual contains. You know that this system, the real one in production, doesn’t behave the way its documentation claims. You know that when a particular symptom appears, the cause is almost always one specific thing, because you’ve seen it twenty times. You know why a decision that looks wrong was right given constraints nobody remembers anymore.
You know where the bodies are buried, which shortcuts are safe and which will kill you, what the system’s designers really meant it to do versus what it ended up doing.
This is called tacit knowledge, the kind you can’t easily transfer because it lives in experience instead of in documents.
It’s the most valuable knowledge an organization has and the least protected. I wrote about its equivalent in the trades in ten skilled trades where the knowledge is dying, and the technical world has exactly the same problem. The master craftsman and the master engineer both carry irreplaceable knowledge that disappears if no one captures it.
My take
Get it out of your head while you still can. The manual doesn’t know which symptom always points to one cause, why the strange design was right, or which shortcuts will kill you. You do. That knowledge leaves the building the day you retire. A book is how it stays. Start with the failures and the warning signs, because nobody else can reconstruct those. Every company that loses that knowledge pays to relearn it the hard way.
What knowledge does a senior engineer carry that no manual contains?
The reasons behind decisions: why a system was built a certain way, what failed before, and which warnings matter.
From the podcast
Vladimir Ingerman spent almost twenty years in Siberian oil and gas before Halliburton brought him to the United States in 1990, and describes what the move transferred, on Leaders and Their Stories:
Move Western technology to Soviet space, and my family loved it.The technology moved because a person moved with it. No manual holds that part and no handover document captures it.
This knowledge has an expiration date, and it’s your retirement or your death, whichever comes first.
Memory fades before either one. The specifics, the exact reasoning and the war stories that carry the lessons all get blurrier every year. The engineer who could have explained exactly why the system was built that way remembers, ten years after leaving, only that there was a good reason. That’s a bad way to treat people who spent a career earning what they know.
This is the same urgency I write about in the witnesses are dying and your story dies when you do. The window to capture what you know is open now and closing. Every year you wait, more of the detail is lost, and the detail is where the value is.
A vague memory of having solved a problem is worth little. The precise account of how you solved it is worth everything to the person who faces it next.
You might think this is a job for documentation.
Write it all up in a wiki and be done. I’ve got nothing against wikis, but I don’t trust one to hold the reasons behind a decision. Documentation records what a system does and says almost nothing about why, and it never tells the story. Tacit knowledge transfers so poorly because it’s bound up in experience, in how you came to know what you know. A book can carry the disaster that taught you the lesson, so the lesson sticks.
And a book does something documentation cannot: it preserves you, the person who knew these things, alongside the knowledge.
Your judgment, your way of thinking about problems, the hard-won instincts that guided your decisions. That’s what the next generation needs, and it’s what disappears most completely when a senior person leaves. The knowledge and the person who held it are captured together, and that makes it a memoir.
I’ve written memoirs for people who were already gone, working from their papers and interviewing their families.
It’s worth doing, and the family can tell me what that person was like. They can’t tell me why the system was designed around a failure nobody else remembers, or which alarm that person knew to ignore. That part went with them, and no amount of interviewing brings it back.
The hardest part of preserving this knowledge is that you barely know you have it. It’s so familiar to you that it feels like common sense, even though no one else possesses it. That’s exactly where a ghostwriter who understands your world justifies the fee. I know what questions to ask, because I know what kind of knowledge is hiding in a technical career.
I can pull out the things you’d never think to mention, because to you they’re obvious, and they’re the most valuable things you know. That’s the work: getting the irreplaceable knowledge out of your head and onto the page, in the form of stories that hold it, before it leaves with you. You can see how I work on the memoir ghostwriting page.
If you’re a senior engineer planning to get to this after you retire, I’d push back hard. Start while you still work near the systems and the people who can jog your memory, because the details you’d need are already fading, and they’ll fade faster once you’ve left the building.
Frequently Asked Questions
Tacit knowledge is the kind of expertise that lives only in a person’s head instead of in any manual or wiki. It includes knowing how a system behaves in production, why it was built the strange way it was, what the undocumented failure modes are, and how to fix the thing nobody else understands. I saw this constantly during my two decades running enterprise technology, where the real answers rarely matched the official documentation.
This knowledge matters because it’s the most valuable an organization has and the least protected, since it exists only in the experience of the person who earned it. When that person retires or dies, the knowledge disappears with them unless someone captures it first.
Because documentation captures the what, not the why, and never the story. Tacit knowledge transfers poorly precisely because it’s bound up in experience. A book can tell the story of the disaster that taught the lesson, so the lesson sticks the way a bullet point never will, and it preserves the person’s judgment and way of thinking alongside the facts.
Because it’s an expiration date: retirement or death, whichever comes first, and memory fades even before that. The specifics, the exact reasoning, the war stories that carry the lessons, all blur with time. The window to capture what you know is open now and closing, and the detail, where the value lives, is lost a little more every year.
It’s a memoir built around preserving knowledge as well as life events. The goal is to capture the irreplaceable technical understanding alongside the person who held it, their judgment and instincts, in the form of stories that carry the lessons. It serves the next generation of engineers as much as it honors the career.
By asking the right questions. That requires understanding the technical world well enough to know what knowledge is hiding in it. Senior engineers barely recognize their own expertise because it feels like common sense to them. A ghostwriter who ran enterprise technology knows to pull out the things you’d never think to mention. They’re often the most valuable things you know.
Yes. I ran enterprise technology for two decades and ghostwrite books, so I understand both the knowledge worth preserving and how to get it out of your head and onto the page before it disappears. You can see how I work on the memoir ghostwriting page.
Before that knowledge walks out the door, get it into a book. The Ghostwriting Advantage covers how to get your book written for you when the expertise lives in your head.
