Making Yourself Fireable — Building an Action Plan

Making yourself fireable — Part Two

At the end of the first article, I asked a slightly rude question:

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

If your answer is “a lot, and nobody,” I do not think the next move is to panic.

It is also not to declare that you are handing the whole project to somebody else next week. That is one of the ways a good idea turns into a bad handoff. The person taking the work needs time, context, and actual authority. You may need to stay accountable for a while. The project may not be ready. They may not be ready.

The useful thing is to pick one dependency and make it a little less dependent on you.

That is the action plan. It is not especially glamorous. It is documentation, cross-training, making decisions visible, and giving work away before somebody has to take it from you in an emergency.

The difference is the intent. I am not waiting for someone to ask me to delegate. I am looking for the knowledge, work, or responsibility that would create a problem if I were suddenly gone, then making a plan to reduce that problem.

Start with work that can actually run

The first thing I usually look at is the onboarding path.

Can a new engineer get the application running using only the documentation in the repository? Not the documentation plus a helpful Slack thread from two years ago. Not the documentation plus an hour with the person who remembers which environment variable is wrong. Just the documentation.

I like to re-onboard myself from time to time. I will try to follow the instructions as if I have forgotten everything—which, six months after I last touched a project, is not entirely hypothetical.

When that fails, I do not treat it as proof that somebody did a bad job documenting. Documentation naturally gets out of date. The project changes. A new dependency appears. An old service disappears. Somebody who already knows the answer stops noticing that it is missing.

The failure is useful information. It tells me where the next gap is.

For me, the required documentation belongs in the code repository. It needs to help the unknown future maintainer, but it also needs to help my forgetful future self. Setup instructions are part of that. So are the reasons behind major design decisions. A diagram showing what the system looks like today can be useful. A record of why it became that way is often more useful when somebody is trying to change it later.

The details depend on the work. In a healthcare application, a new engineer may need valid fake-patient identifiers and a path through the real testing workflow: register a test patient, schedule with a test doctor, document and sign the visit, then generate the insurance and patient invoices. If that path lives only in one person’s head, the project is not really ready for a new owner.

In an AI system, the handoff material may be old experiments, evaluations, prompt test cases, and the history of how a system prompt changed over time. If a new team changes the prompt after handoff, they should be able to evaluate that change against something more useful than “it seems okay to me.”

This is not a request to document every thought you have ever had. It is a request to make the work runnable and the important context recoverable.

Pick a person, then give them a real slice

The next question is not only “what would be lost?” It is “who could take this work?”

For each hat I am wearing—solution architect, analyst, data scientist, front-end engineer, sales engineer, tech lead—I try to identify someone who could eventually wear that hat too. That does not mean I expect them to wear all of it tomorrow. It means I have stopped treating the work as naturally attached to me.

The best first transfer is often a small, real one. Let somebody lead a pull-request review. Ask them to run the standup. Work through a production problem with them and let them take the next troubleshooting step. Give them an explicitly bounded decision.

They need to be able to do the work, not merely watch it happen.

I have seen this work well when a project changes stages. At a product company, I started proofs of concept for a browser-automation suite used for data integrations and for an analytics reporting backend. At the POC stage, we accepted a concentrated bus factor. The goal was to find out quickly whether the idea was worth pursuing. If the proof failed, we needed to be able to fail fast.

Once each POC was proven, though, we added a junior engineer and grew it into a full project over the next several months. At that point, the explicit goal was for me to be the first person removed.

That was good for the project because its future did not depend on one person. It was also good for the engineers joining it. The work became an opportunity to grow their careers, not a thing I protected because I had started it.

There is an uncomfortable part here. Giving someone a real slice of work means they may do it differently than I would. They may make a mistake I could have avoided. If I keep taking the work back whenever that happens, I have not handed anything off. I have created shadow ownership with better branding.

That does not mean I should throw someone into a situation they cannot handle. It means the transfer has to match the person and the project. Start with a small slice. Make the boundaries clear. Add more as the person demonstrates that they can carry it.

Make the plan visible

If I do all of this silently, it can turn into an invisible act of overdelivery. It may make a project healthier without creating any room for the people involved to grow.

So I try to include the person who is learning the work and my boss. I will tell the engineer that the goal is not merely for them to know about the project. The goal is for them to be able to take it if I am unavailable or needed somewhere more critical. I will ask my boss whether a particular engineer needs help getting there.

That is a different conversation from, “I would like to get rid of this project.” It says that I am trying to make the team stronger and create room for the next piece of work.

It also gives other people a chance to point out something I am missing. A manager may know that an engineer is already overloaded. The engineer may not want the role I have imagined for them. A stakeholder may have a legitimate concern about risk. Those are not necessarily reasons to stop. They are reasons to adjust the plan before an emergency adjusts it for you.

On a client project, this needs even more care. A client may hear a consultant talking about becoming fireable as a plan to leave them with the problem. There is a real tension there, and I do not think an individual contributor can solve it just by choosing better words. For now, I keep the focus on concrete value: making the system easier to support, making the technical context durable, and helping the people who need to work with it next.

Keep the loop small

I do not have a single test that tells me I am now fireable. I do not think that is how this works.

For me, it is a loop:

1. Name one knowledge gap, workflow, decision, or responsibility that depends too much on you.
2. Identify the person who could take the next useful slice.
3. Make that slice runnable and understandable.
4. Let them actually own it.
5. Notice what still comes back through you.
6. Pick the next gap.

Start with documentation and internal cross-training. Then involve peers and your manager. Extend the practice carefully to clients or customers when the relationship, capacity, and business priorities make that appropriate.

That is slow on purpose. You do not need to turn a project into a succession plan in a week. You do need to stop assuming that the knowledge in your head will somehow become available to the next person when the time comes.

Pick one current dependency this week. Try to re-onboard yourself from the repository. Write down one decision that only exists in your memory. Ask someone to lead one real slice of work.

Then watch what happens.

The next article is about how to read that immediate feedback. Not promotion. Not a new assignment. The smaller signs that tell you whether work is actually starting to move without having to pass through you first.