Making Yourself Fireable

Making yourself fireable — Part One

“Making yourself fireable” sounds like terrible career advice.

Honestly, it may be the worst possible phrase to use at work if you have not earned the right to explain it yet. I would not recommend opening a one-on-one with your boss by saying, “I have a plan to make myself easier to fire.” That conversation is probably not going to go where you want it to go.

But I have spent a good part of my career trying to do exactly that.

Not because I want to be disposable. Not because I think a company should be able to swap out an experienced engineer for somebody else with the same title and call it even. And definitely not because I think making myself fireable is some kind of protection from a layoff. It is not.

For me, being fireable means that I can be removed from a project without leaving a giant resource gap behind me. The technical knowledge, decisions, onboarding path, and ownership should be somewhere more durable than my head. Someone else should be able to keep going.

That is really just another way to talk about bus factor: the unpleasant question of how many people could be hit by a bus before a project loses the knowledge or capacity it needs to keep moving.

I am using an equally uncomfortable phrase on purpose. “Making yourself fireable” is not a sanitized discussion of succession planning or knowledge management. Those are useful terms, and we will talk about the work they describe. But if we sand this idea down too much, we can miss the actual question: what happens to the work when you are no longer available to do it?

It is also, I think, one of the ways an individual contributor can keep finding higher-value work without treating management as the only path forward.

The first time somebody asked me to watch my own bus factor

My first job after college was at a non-profit during the dot-com crash. We were replacing something like 30,000 static web pages with a CMS-driven site connected to print-publishing workflows. It was a large project for me at the time, and I was learning an enormous amount by doing it.

My manager asked me to do more than build the system. She asked me to watch the bus factor and make sure the rest of the team could support it.

The non-profit part mattered. She and I both knew, and openly acknowledged, that I was not going to remain there for long. That was not a secret or a betrayal. It was a big reason she wanted the work to be supportable by the people who would remain.

I do not remember having a grand theory about this. I was early in my career. I probably just wanted to prove that I could build the thing.

But the request changed how I thought about the work. The goal was not to create a system that only I could understand because I had been there from the beginning. The goal was to build what the organization needed and make sure the organization could keep using it.

That organization did keep using it. Three years later, I left for a startup. The departure was not a crisis. They were not afraid the system would fail without me, and the site continued for another two decades.

That was an important lesson for me. I had not made myself less valuable by making the system supportable. I had created room to go do something else.

This is not the same thing as being replaceable

There is a real difference here, and I want to be careful with it.

An experienced engineer is not interchangeable with another experienced engineer just because both of them have the same seniority label. Context matters. Judgment matters. A person who has spent years learning a system, a domain, a client, or a team will have knowledge that is difficult to recreate quickly.

Sometimes the important work does make you hard to replace for a while. That is not a failure.

The problem is when that temporary reality becomes the permanent operating model. You become the only person who can run the system. The only person who knows why a decision was made. The only person who can help a new engineer get the project working locally. The only person stakeholders call when something goes wrong.

At that point, you may feel indispensable. Other people may even tell you that you are indispensable.

I do not think that is usually the compliment it sounds like.

It can mean you have done important work. It can also mean you are now the bottleneck for work that should be able to move without you. You are stuck maintaining the resource gap you created—or inherited—while the next critical problem goes to somebody else because nobody can afford to move you.

Being fireable is a direction, not a finish line. I do not know that there is a point where you can say, “Good news, I am now completely fireable.” Every project changes. People leave. New systems get bolted on. Documentation drifts. You come back six months later and discover that your forgetful future self needs the same onboarding help as a brand-new teammate.

The useful question is simpler: what would be lost if I vanished from this project, and who would take this work?

If the answer is “a lot, and nobody,” there is work to do.

Company code, not my baby

Years later, I was at a product company watching a new HTML5 frontend approach a problem that was going to hurt. We were looking at roughly 3,000 network stubs that would need to be implemented by hand. I saw that crisis coming and raised it to my boss as something I could work on that would add significant value to the team.

The result was an API middleware client that connected the frontend to the existing backend services. This was several years before Swagger and OpenAPI. It was not a trivial generated client sitting on top of a specification. It became a central part of the work.

Then the organization reorganized and grew quickly. Another developer was promoted to front-end architect.

There was an assumption from some people around us that I might have a hard time giving the middleware work up. It was “your baby,” after all.

It was not my baby. It was company code.

The new architect deserved the opportunity to work on it. More importantly, the company needed somebody else to be able to own it. We started formal knowledge transfer the next day. There was no long period where I got to carefully prepare the perfect handoff before the transition started.

That might sound reckless. I do not think it was. The work had to move, and the organization had a new need for me: critical certification work. Because I was willing to give the project away, I could move to where I was more useful at that moment.

I do not mean that as a tidy cause-and-effect story. I cannot prove that one handoff produced one opportunity. Organizations are messier than that. But I have seen the pattern enough to take it seriously: if every important thing you have ever done still requires you, you are going to have less room to do the next important thing.

Fireable does not mean absent

There is a bad version of this idea where you throw documentation into a repository, name a new owner, and disappear. That is not what I mean.

The person taking over needs real ownership, not shadow ownership with you quietly making every decision behind the scenes. They also need the capacity, authority, and skills to take the work. A handoff is not successful merely because the prior owner wants to be free of it.

There are times when the right decision is to wait. I have been in a client situation where I had written the billing code, performed the daily medical-billing process, and become the primary support and troubleshooting subject-matter expert. The code and process were documented. The client was still building its internal team, though, and it had higher staffing priorities than adding the skills needed to take the work over safely.

I could document the handoff and make the risk visible. I could not make the receiving capacity appear by force of will.

So the handoff was delayed for almost nine months. That was not an argument against reducing the bus factor. It was a reminder that fireability is not abdication.

The same tension gets sharper in consulting. Helping a client become capable can look like preparing to leave. Keeping a client dependent can create short-term billable work, but it can also leave the client trapped and make the consultant too dependent on the client in return. I do not have a commercial model that resolves that. I will come back to it later in this series.

For now, I think the core responsibility is more modest: do not build an ivory tower around work that other people need to carry.

Start with an honest inventory

This is not a request to announce a transition tomorrow. For a junior engineer, the first useful step might be finding the piece of onboarding knowledge that only lives in somebody’s Slack message—or in your own memory—and making it easier for the next person to find. For a more experienced engineer, it might be identifying the teammate who could begin taking a real slice of the work.

Either way, start with the same question:

What would be lost if I vanished from this project, and who would take this work?

Write down the answer without judging it. The gaps are normal. They happen even on teams trying to do the right thing.

In the next article, I want to talk about what to do with that list: how to turn one dependency into a small action plan that makes the work easier for somebody else to own.