There’s a particular kind of knowledge that lives only in the head of a senior engineer, and it dies when they do. Not the things you can look up. The real knowledge is different. How this specific system actually behaves. Why it was built the strange way it was. What the undocumented failure modes are. Which warning signs precede which disasters, how to fix the thing nobody else understands. Decades of it, accumulated through experience that can’t be repeated, and almost none of it written down.
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 genuine loss, to everyone who would have benefited from understanding what that person understood, not just to the company. 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 actually 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 was really designed 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.
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 actually 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.
The hard truth is that this knowledge has an expiration date, and it’s your retirement or your death, whichever comes first. Memory fades even before that. The specifics, the exact reasoning, the war stories that carry the lessons, all of it gets blurrier every year. The engineer who could have explained precisely why the system was built that way, ten years after leaving, remembers only that there was a good reason.
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’s worth everything to the person who faces it next.
You might think this is a job for documentation, not a book. Write it all up in a wiki and be done. But documentation captures the what, not the why, and it certainly doesn’t capture the story. The reason tacit knowledge transfers so poorly is that it’s bound up in experience, in the narrative of how you came to know what you know. A book can carry that. It can tell the story of the disaster that taught you the lesson, so the lesson sticks the way a bullet point never will.
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 actually 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, not a manual.
The hardest part of preserving this knowledge is that you barely know you have it. It’s so familiar to you that it doesn’t feel like knowledge, it feels like common sense, even though no one else possesses it. That’s exactly where a ghostwriter who understands your world earns their keep. 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 carry it, before it leaves with you. You can see how I work on the memoir ghostwriting page.
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 actually 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, not just 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.
