The Two Fears in Engineering: Being Irreplaceable vs. Being Easily Replaced
How our insecurities show up in code reviews and why the most 'secure' engineers often limit their own growth
I've been thinking a lot lately about two opposing fears plaguing many engineers: irreplaceable and easily replaceable. It's funny how two completely contradictory fears can exist in our minds simultaneously.
This topic has been on my mind since my conversation with my ex-manager, Stephan Claus, at HomeToGo. During one of our 1:1s, he asked me a question that fundamentally changed how I approach my work: "Are you building yourself to be irreplaceable or preparing yourself to be replaced?" That question has stayed with me throughout my journey as an engineer and a manager.
The Irreplaceability Trap
You can spot engineers caught in the irreplaceability trap from a mile away when you look at their code and pull requests. They're the ones who build complex systems that only they understand. Their code lacks comments, has minimal documentation, and often employs clever but obscure techniques. They might even subtly discourage others from touching "their" parts of the codebase.
"I'm the only one who knows how this works" becomes a badge of honour and job security. I get the appeal - being the go-to person feels good and provides a sense of value. Who doesn't want to feel essential?
But this approach is deeply flawed. When you make yourself irreplaceable:
You become a bottleneck for your team
Your vacations are interrupted by urgent questions
You can't move to new, interesting projects because you're tied to maintaining your "territory"
You limit your growth by focusing on protecting rather than expanding your knowledge
I've seen this at every company I've worked at. There's always that one person who has been there for years and has become the keeper of sacred knowledge. They often end up stuck, unable to explore new technologies or methodologies. Their "job security" becomes a prison.
The Replacement Anxiety
On the flip side, there's the fear of being easily replaced, especially prevalent in the era of AI and rapid technological change. This manifests in engineers who:
Hesitate to share knowledge or document their work thoroughly
Try to be involved in every decision, even outside their domain
Taking on too many responsibilities makes one seem indispensable
Chase every new technology without mastering fundamentals
I've fallen into this trap myself. Early in my career at Wix, I was so worried about proving my worth that I'd take on anything, regardless of whether it was my strength. I was stretched thin and constantly anxious. Not a sustainable way to work, trust me.
Code Tells the Story
These fears become most visible in pull requests and code reviews. Engineers fearing replacement often submit massive PRs with many unrelated changes to show how much they do. They might defensively respond to feedback or try to incorporate every trendy pattern or technology.
Those trapped in the irreplaceability mindset tend to submit minimal PRs with enough information for approval but not enough for proper understanding. They might hand-wave away questions about how something works with "it's complicated" or "I'll handle that part."
Looking back at my code from different periods in my career, I can see exactly where I was on this spectrum.
Finding the Balance
My conversation with Stephan helped me realise that the healthiest approach lies in the middle. The goal should be to make yourself valuable but not irreplaceable.
Here's what I've learned works better:
Document everything. Clear documentation doesn't diminish your value; it multiplies it by showing you're a team player who cares about collective success.
Mentor others. Teaching what you know doesn't make you replaceable; it makes you a leader. I've found some of my biggest opportunities came after I helped others understand systems I had built.
Build systems, not silos. Focus on creating processes and architectures that are both intuitive and maintainable, rather than just clever.
Embrace "T-shaped" knowledge. Have deep expertise in some areas but maintain a broader understanding across many domains. This makes you adaptable rather than replaceable.
As a manager now, I look for engineers who approach their work this way. They're the ones who make the whole team better, not just themselves look good.
The Paradox
Here's the interesting paradox I've discovered: the more you try to make yourself irreplaceable, the more limited your growth becomes. Conversely, the more willing you are to make your knowledge replaceable (through documentation, mentoring, clean code), the more valuable you become to organisations.
Some of the best engineers I've worked with actively tried to make themselves "replaceable" by documenting everything, mentoring others, and building intuitive systems. Ironically, these were the people the company valued most and would fight hardest to keep.
So, ask yourself, which fear is driving your decisions? Are you hoarding knowledge or spreading it? Are you building a fortress around your code or a community around it?
I'm grateful to Stephan for asking me that question years ago. It fundamentally changed how I approach my work, teams, and career. As an engineer and a manager, I now strive to create value by sharing knowledge rather than holding it in.