On Being Irreplaceable

Lately I’ve been having conversations with friends and colleagues around office colleagues, people we’ve come across throughout our careers and inevitably come to talk about the type of coworker we’ve all had to deal with at some point: the dreaded “job security” type.

We’ve all met this coworker: It’s the person that people always point you to when you have an issue with some deep part of the stack. It’s the person that cooked up that internal tool the entire org depends on that mysteriously has no docs available. It’s the person that always seems to speak out against large technology migrations like moving workloads to the Cloud or adopting Kubernetes. There’s a common thread whenever that person comes up in discussion in that they’re usually not the easiest people to work with. I’ve had frictions with that type in the past and have since strived to be the opposite.

I think that people who act in this way generally speaking do so because they want to make sure they are hard to replace. They’re people who are deeply afraid of layoffs and whose solution to the problem is to make sure that they have some sort of deep knowledge about a key part of systems they work on, making them hard to let go. I don’t agree with that line of thinking. I think there’s a false premise here that having some deep understanding of a part of a system makes you immune to layoffs, and I’ve tried very hard so far in my career to not be that person.

So what does that look like? How do you actually become irreplaceable at your job? My opinion is that, counterintuitively, you have to strive to be the most replaceable person in your organization.

This may sound ridiculous, but hear me out. What can you do, as a software engineer or systems administrator, to make sure you can easily be replaced? What can you do to limit your “bus factor” or the impact of you leaving for another position elsewhere? You will probably want to start with documenting and note-taking: Make sure you journal everything you do so you keep track of your progress on various projects as you go (which also has other personal benefits as well but that’s another discussion.) Keep documentation on how the solutions you build work, how to use and operate them. If you’re let go, or resign, hopefully your company will take back your computer and will at least have a trace somewhere of whatever you were working on.

The next level is to do those things out in the open. Keep your documentations and progress tracking in a public and easily discoverable place. Maybe write your docs right in the README of the project, or in a shared Google Docs. Instead of journaling in a local text file, keep detailed progress updates right in the comment section of your issue tracking software. Or if that’s not something that you feel comfortable doing, again a shared Google Docs will be just fine. You want to make sure that in the event where you have to leave your role, not only will you have taken detailed notes on what you were doing, but that this information is easily discoverable by other team members. You want to make sure they won’t have to search through backups or your old computer’s hard drive to find that information. They’ll have it right there at their fingertips.

Keeping a record of what you did and your progress on different tasks is only part of the story though. Your role as a team member isn’t just defined by the code you produced and the tasks you were working on; It’s also defined by the voice that you bring to product discussions, the opinions you’re bringing in and how you’re helping set the overall product direction. If you truly want to be a replaceable element, you need to be proactive in your communication. Keep an open channel with your manager and often talk about your vision for the short and medium term. This is obviously helpful to help you gain alignment on the project, but will also help you manager with capacity planning and understanding better how the team is doing and where the project is headed. Be proactive with your communications with other teams as well! It’s very unlikely that you work in a vacuum; The work that you do is generally within the context of a larger organization and will have impacts and be impacted by what other teams are doing. Ideally, you want to make sure that not only your team members know what the hell you were up to, but you also want those other teams to know what you were working on and the direction you were going so that they can carry that work past your departure.

The theme here, if it wasn’t clear enough, is communication. You want to be very transparent about what you’re doing and be proactive with your communications. When you do that, there’s a very interesting thing that happens. You start becoming someone that people can rely on a whole lot more. Everyone knows what you’re working on and the direction you’re taking. You’ll also find yourself pulled in to more and more discussions with other teams and other parts of the organization because you now have much more context and understanding of what other teams are doing and where everyone in the organization is headed; This understanding puts you in a very special position where you can bring very valuable insights to those higher level discussions. You know who to reach to answer any question that pops up, you know who to pull in to a project and who can help the most in any situation.

In other words, the same habits that make you the most replaceable as an individual contributor also turn you into a force multiplier, someone who can leverage other people around them to help get things done with a higher level of alignment with the business. That will make much more indispensable to the business than any technical knowledge about a system or process ever will. And that’s what I always strive for.