In a world full of crises, job security is among the remaining safe havens. I bet you're pushing yourself to work harder, overdeliver and make yourself so valuable that getting rid of you would be unthinkable. It sounds sensible enough, but so does most bad advice. Intuitive choices don't always produce the best outcome. So here's my less-than-intuitive take: make yourself replaceable.
I'm not conspiring to get you fired. I promise. The job you're desperately clinging to might disappear anyway. Or you might want to leave it. And when that happens, being indispensable to one company can quickly make you less valuable to the next.
Meet Sam
Every company has a Sam.
Sam has been around for a while. Long enough to know why that innocent-looking if statement must never be touched. They know the three undocumented environment variables required to run the payment service locally, the exact sequence of commands needed to deploy it, and which command needs to be run twice for reasons nobody quite remembers.
Sam led the migration from six years ago that left behind a database column everyone is too afraid to delete. They know which customer still depends on an API endpoint deprecated in 2019, which service occasionally crashes on Tuesday afternoon, and which supposedly temporary workaround has quietly become the flagship infrastructure.
None of this is written down, of course. It doesn't need to be; Sam knows, and Sam doesn't forget.
When something breaks, everyone knows whom to call. When a strange bug appears, someone tags Sam. When a new engineer has questions nobody can answer, Sam sees an invitation pop up on their calendar.
Everybody wants to be Sam
Sam didn't set out to become a single point of failure. Nobody does. People who take their work seriously want to be good at it. Great, even.
So Sam delivers. They take ownership of the payment service and become its resident expert. They pick up the difficult tickets because they can solve them faster. They jump into incidents because they know where to look. When someone gets stuck, Sam helps. When nobody knows the answer, Sam finds it.
And it works!
People trust Sam. Managers praise Sam. Colleagues depend on Sam. Their name starts appearing in conversations before they've even been invited to them. The more important the problem, the more likely someone is to say: ask Sam.
The engineer who keeps putting out fires becomes a hero. The engineer who makes the building less flammable enjoys considerably less acknowledgement.
Why wouldn't you want to be Sam?
Especially when jobs feel precarious. If you're going to survive the next reorganisation, surely being the person everyone depends on is a better strategy than being the person nobody notices is on holiday.
Employee of the decade: Sam
Sam is officially indispensable. Little did they know, indispensability comes with unforeseen side effects.
The first one appears when Sam tries to move away from the system that now depends on them. A new project comes along, and Sam would be perfect for it. But who would look after the payment service? A position opens on another team. Sam is interested, but replacing them would take months. Promotion brings more responsibility, but Sam already has plenty of that.
There are systems to maintain, incidents to investigate and questions only they seem able to answer. The company has spent years concentrating knowledge around Sam. Moving them somewhere else would only create a Sam-shaped hole.
Then Sam goes on holiday.
They keep an eye on their phone, just in case. Obviously, nobody intends to bother them. Until something breaks. Someone just needs to know whether that obscure configuration value is still required. Or why the deployment failed. Or whether touching that database column will summon something from the underworld.
Sam replies. Of course Sam replies. Sam always replies.
The same thing that made Sam difficult to fire has made them difficult to move, difficult to promote and, apparently, difficult to send on holiday.
Sam wanted job security. They got the job part, along with the growing suspicion that it might be theirs for life.
No fire, no glory
Sam is partly responsible for the mess they find themselves in. But organisations are remarkably good at creating Sams.
Take a quick tour through your favourite job board and the message is hard to miss. Companies want owners, go-to people, experts, rockstars, superheroes and whatever other title we have invented for people carrying the entire load of a team.
Then they reward exactly that behaviour.
When production goes down at 2 a.m. and Sam saves the day, everyone notices. There are thank-yous, retrospectives and perhaps an honourable mention at the next all-hands. When another engineer quietly prevents the same incident from ever happening, crickets.
And that's the problem: heroism is loud and clear. Prevention is silent and elusive.
Answer twenty questions a week and everyone knows you're helpful. Improve the documentation so nobody needs to ask them and your impact suspiciously goes down. Jump into every difficult problem and your contribution is obvious. Teach others until they no longer need you and it can look remarkably like you're doing less.
Organisations reward what they can see: incidents resolved, lines of code pushed, and messages sent.
The engineer who keeps putting out fires becomes a hero. The engineer who makes the building less flammable enjoys considerably less acknowledgement.
It's hard for Sam not to relish the attention and praise they receive. The saviour complex afflicting many engineers can easily tickle their ego and inflate their sense of importance. Being needed is flattering. Constantly stepping in to save the day can feel less like a failure of the system and more like proof of Sam's value.
Permanent resident
There is a less obvious problem with becoming indispensable.
Over the years, Sam has accumulated an extraordinary amount of knowledge. They know the product, the codebase and its history better than almost anyone. They know which decisions were deliberate, which were compromises and which were made on a Friday afternoon and quietly regretted ever since.
This knowledge makes Sam extremely valuable—to this company.
There is a difference between expertise and institutional knowledge. Expertise travels. Understanding the ins and outs of browsers, databases, team dynamics and communication is a skill you can pack up and take to your next job. Knowing why your company's billing service occasionally duplicates an invoice is considerably harder to fit into a cardboard box and carry with you.
And while Sam was busy becoming the world's foremost expert on this particular system, the rest of the world kept moving. Maybe they haven't designed a new system in years because they're maintaining this one. Maybe they haven't encountered different architectures because this architecture needs them to babysit it. Maybe the technology they know best is still around largely because replacing it would require taking Sam away.
None of this makes Sam a worse engineer. Quite the opposite. But "good engineering" isn't a universal language that translates neatly across the industry.
The problem becomes obvious when Sam finally decides to look elsewhere. Suddenly, years of highly valuable knowledge have a market of exactly one buyer.
“I can do this in ten minutes” is exactly how Sam remains the only person who can do it in ten minutes.
Sam has become spectacularly qualified for the job they already have. They built the walls, the ceiling and the door to the prison cell they find themselves in. They even threw the key in the ocean. Meanwhile, their manager and their entire hierarchy were applauding the construction work.
Kill your darlings
Not literally.
The solution isn't for Sam to know less, care less or become worse at their job. It's to make sure the value they create doesn't require their continued presence. In other words, Sam needs to remove Sam from the system.
Start with the things that live exclusively in Sam's head. If an architectural decision matters, Sam writes down why it was made. If setting up the project requires a two-day guided tour, they simplify the setup. If releasing the application involves a sacred sequence of terminal commands performed in the correct order, they automate them.
The same applies to all the little rules Sam has accumulated over the years. If they keep pointing out the same mistake in code reviews, perhaps a lint rule can take care of that instead. If a particular assumption must never be violated, perhaps a test or a type can make violating it difficult. If colleagues keep asking the same question, Sam shouldn't become exceptionally efficient at answering it. They should remove the reason anyone needs to ask.
The goal isn't better documentation. Documentation is just one way of getting there. The goal is to reduce the amount of knowledge the system requires one particular human being to remember.
Sometimes Sam's replacement is another engineer. Sometimes it's a wiki page. Sometimes it's a test, a type or a CI pipeline.
And sometimes the best solution is retiring the complicated thing everyone needed Sam to understand in the first place.
The best systems shouldn't remember who built them, and shouldn't mourn their absence.
Hands off, Sam
Getting knowledge out of Sam's head is only half the job. Someone else eventually has to use it. This is where things get uncomfortable.
Sam can fix the problem in ten minutes. Alex will need an hour. Sam knows exactly where to look. Alex will spend twenty minutes in the wrong directory, another ten reading code that has absolutely nothing to do with the problem and eventually ask a question whose answer Sam knew before Alex even opened their laptop.
Every instinct tells Sam to grab the keyboard. To Sam I say: "Step away from the keyboard and keep your hands where I can see them."
"I can do this in ten minutes" is exactly how Sam remains the only person who can do it in ten minutes.
Let someone else investigate the incident. Let another engineer lead the migration. Give away the interesting ticket you know you could finish faster. Pair with someone who has never touched that part of the system, then resist the urge to turn pair programming into one person typing and another person watching.
It will be slower. That's the whole point.
Efficiency is easy to measure over the next hour and surprisingly difficult to measure over the next year. Doing everything yourself wins today. Teaching someone else how to do it means that, eventually, you don't have to.
Seniority is often framed as accumulation. More knowledge. More responsibility. More ownership. More systems with your fingerprints all over them. At some point, perhaps it should work in the opposite direction too. More delegation. More collaboration. Less Sam.
The measure of a senior engineer isn't only how much gets done when they're in the room, but how much can still get done when they're not. That's where Sam needs their manager fully on board: to understand the true cost of short-term gains, appreciate the real value Sam brings to the team and the organisation, and reassure Sam that all their intangible contributions aren't going unseen.
What was your name again?
Making yourself replaceable doesn't mean making yourself redundant. It means making sure your career can survive without your current job.
The systems you build should survive your holidays, your promotion and eventually your resignation. The knowledge you accumulate should make you more useful outside your current bubble, not just more difficult to remove from it.
Job security is comforting, but jobs are remarkably insecure. Teams get reorganised. Strategies change. Budgets disappear. Companies get acquired. Sometimes you simply wake up one morning and realise you'd rather be doing something else. Being indispensable won't necessarily protect you from any of that. It might just make you less prepared for what happens next.
So automate the thing only you know how to do. Write down the thing only you remember. Teach someone the thing only you understand. Then go learn something you don't. Rinse and repeat.
The engineer who cannot be replaced is stuck exactly where they are. The engineer who can be replaced is free.