Years ago, people used to say something about certain employees:
You cannot get fired, but you also cannot get promoted.
The idea was that the person knew too much. They were the only one who understood the system, the customer, the process, or the collection of scripts holding everything together. The company could not afford to lose them. Unfortunately, it could not afford to move them either.
It sounds almost flattering. It is not.
It is also not true. You can get fired.
You can get laid off. Your company can merge with another company. A new executive can arrive with a new plan and no interest in the history of the old one. A project can be cancelled. A department can be reorganized out of existence. You can make a mistake. Someone can decide that the work you have spent years protecting should be replaced by a product they saw in a presentation last Tuesday.
No matter how important you believe you are, an organization can and eventually will continue without you.
The better question is: what happens to your work after you are gone?
Indispensable Is Not the Same as Valuable
There is a kind of job security that comes from being the only person who knows how something works. The build fails, so they call you. The database stalls, so they call you. A customer asks why a decision was made five years ago, and everyone turns toward your desk.
That can feel good. It can feel like proof that you matter.
But if every important question ends with your name, you have not built security. You have built a bottleneck.
Worse, you may have built a cage.
The company cannot promote you because nobody can take over your current work. You cannot take a real vacation because the system follows you through your phone. You cannot move to a new team without carrying the old one on your back. Every emergency reinforces the idea that you are essential, while quietly taking away your ability to do anything else.
And still, you can be fired.
When that happens, the mythology of indispensability disappears very quickly. What remains is a group of frustrated people trying to understand a system they inherited from someone who is no longer available to explain it.
That is not a legacy. It is deferred failure.
The Work Is Not Finished When It Works
Engineers are often rewarded for making something work. We celebrate the launch, close the ticket, merge the pull request, and move on to the next problem.
But working software is only part of the job.
Can someone else deploy it? Can they tell when it is unhealthy? Do they know which alarms matter and which ones have been noisy for three years? Can they restore it from a backup? Do they know why the obvious solution was rejected? Can they identify the assumptions that were true when the system was designed but may not be true anymore?
If the answer to those questions exists only in your head, the work is not finished.
Documentation is not the paperwork that happens after the real work. It is part of the real work. A system that functions only while its original author is present is not complete, no matter how elegant the code may be.
I have inherited systems where the code was the only documentation. People like to say that code is self-documenting. Sometimes it is. Code can tell you what the system does.
It rarely tells you why.
It does not tell you about the meeting where legal rejected one approach. It does not explain that the strange retry interval exists because a vendor’s API failed under a specific load. It does not record that three apparently cleaner designs were tried and each one created a worse problem. It does not tell the next person which compromise was deliberate and which one simply ran out of time.
Without that context, the people who follow you are forced to repeat your mistakes before they can make any progress of their own.
Documentation Is Loyalty to Yourself
People sometimes talk about documentation as loyalty to the company. There is some truth in that. If an organization pays you to build something, leaving behind enough information to operate and maintain it is part of delivering the thing they paid for.
But companies are not always loyal in return. Priorities change. Budgets disappear. Good employees are laid off alongside bad ones. Pretending otherwise is naive.
So this is not an argument for blind loyalty to an employer.
It is an argument for loyalty to yourself.
Your professional standards belong to you. Your principles belong to you. The care you put into your work is part of the reputation you carry from one job to the next. You do not document because you believe the company will keep you forever. You document because you have decided what finished work looks like.
That distinction matters.
I want to be clear about this: failing to document your work is not an act of self-protection. It is a lack of dedication to your own career. It says that your standard for the work ended at the edge of your personal involvement. Whatever happened next was somebody else’s problem.
That attitude does not protect your value. It undermines it.
Professional ethics are easiest when they are rewarded. They matter most when nobody is checking. Writing down what the next person needs to know may not earn applause. It may not appear in a quarterly presentation. It may not save your position during a reorganization.
Do it anyway.
Not because the company deserves a piece of you after you leave, but because leaving confusion behind is beneath the standard you should set for yourself.
What Useful Documentation Looks Like
Documentation does not have to be a 300-page manual nobody will read. In fact, that is often another way to avoid documenting anything useful.
The goal is not volume. The goal is continuity.
At a minimum, the next person should be able to find answers to a few basic questions:
- What is this? Describe the system or process in plain language. Explain who uses it and what problem it solves.
- How does it fit together? Identify the major components, dependencies, data flows, vendors, and external services.
- How do I operate it? Record how to deploy it, monitor it, restart it, restore it, and determine whether it is healthy.
- Why is it this way? Capture the decisions, constraints, rejected alternatives, and compromises that shaped it.
- Where does it break? Document known failure modes, dangerous edge cases, recurring incidents, and the alarms that require immediate attention.
- Who owns what? Make responsibilities clear. A list of systems without owners is just an inventory of future arguments.
- What should happen next? Leave an honest account of technical debt, unfinished work, and improvements you would make if time allowed.
Keep those answers close to the work. A runbook hidden in somebody’s personal folder might as well not exist. A design decision buried in an old chat thread will disappear. A document that has not been reviewed since the system was launched is a historical artifact, not operational guidance.
The best documentation is used while you are still there. Ask someone else to follow the deployment instructions. Let a teammate handle an incident with the runbook while you watch. Give a new employee the architecture notes and see what questions they still have.
If the documentation only makes sense when you are standing beside the person explaining it, you have written notes for yourself, not documentation for them.
Make Your Replacement Possible
Some people resist sharing knowledge because they think it makes them easier to replace.
They are right.
You should be replaceable.
That does not mean your contribution was unimportant. It means your contribution was strong enough to survive your departure. It means you created something larger than your own continued availability.
Making yourself replaceable is also how you become available for better work. If another person can operate what you built, you can move on to the next system, the next problem, or the next level of responsibility. The ability to transfer knowledge is not a threat to promotion. It is one of the clearest demonstrations that you are ready for it.
Of course, documentation does not guarantee a promotion. Nothing does. Organizations make irrational decisions all the time.
But withholding knowledge guarantees something worse: even if you are promoted, you will still be doing your old job whenever the phone rings.
Leave a Path, Not a Monument
There is a temptation to think of career legacy in terms of monuments: the major platform, the successful launch, the product that made money, the emergency you solved when nobody else could.
Those things matter. But monuments do not help much when nobody knows how to maintain them.
A better legacy is a path.
It is the architecture record that keeps a future team from reopening an argument you already settled. It is the runbook that helps someone recover the service at two in the morning without calling you. It is the test that explains an edge case better than a comment ever could. It is the honest note that says, “This part is fragile, this is why, and this is what I would change next.”
Most of the people who benefit from that work will never thank you. Some will never know your name.
That is fine.
The point is not to remain the hero of a story after you leave. The point is to make sure the story can continue without you.
The Test
Eventually every job ends. Sometimes you choose the date. Sometimes someone else chooses it for you.
When that day comes, imagine the person sitting in your chair a month later. They are trying to understand the systems you built and the decisions you made. They do not have access to your memory, your old conversations, or the reasons that seemed obvious at the time.
What did you leave them?
If the answer is a collection of mysteries, emergency phone calls, and undocumented exceptions, then years of hard work will be remembered mostly as frustration. Whatever brilliance went into the system will be obscured by the difficulty of carrying it forward.
If the answer is a clear trail of decisions, operating knowledge, warnings, and possibilities, then your work continues to have value after you are gone.
You can get fired. You can get promoted. You can resign. You can retire. None of those outcomes are entirely under your control.
What you leave behind is.