Making Yourself Fireable — Reading First Order Effects

Making yourself fireable — Part Three

There is no dashboard that says, “Congratulations, you are now 63% fireable.”

I kind of wish there were. It would make this much easier to explain in a review. It would also let us pretend there is a clean causal line between better documentation, a successful handoff, a promotion, and whatever comes next.

There is not.

A manager can promote someone for a lot of reasons. A client can bring a consultancy back for a lot of reasons. A team can be happy for a while and then get reorganized. A system can keep working because the new owner is excellent, or because nobody has touched the risky part yet.

So I do not think the first feedback to watch for is a promotion, a new project, or a client renewal. Those things may come later. They are all valuable signals when they do. They are also trailing signals, and they can move independently of whether you are doing this work well.

The first question is smaller: is the work beginning to move without having to pass through you by default?

That is not a glamorous question. It is a useful one.

A handoff starts when the work actually changes hands

At a product company, I saw a crisis coming for a new HTML5 frontend: roughly 3,000 network stubs would need to be implemented by hand. I raised the problem to my boss as an opportunity to add significant value, then built an API middleware client that connected the frontend to the existing backend services. This was before Swagger and OpenAPI. It was not some little generated utility tucked away in a corner. It was central to how the new frontend was going to talk to the rest of the company.

Then the company reorganized and grew quickly. Another developer was promoted to front-end architect, and the middleware work moved to her.

We started formal knowledge transfer the next day. I did not get a long period to prepare a perfect handoff. I also did not get to keep treating the project as mine while someone else carried the architect title.

The immediate signal was simple: the work had a new owner, and the company could move me to critical certification work.

That does not prove I had done everything perfectly. It does show the difference between talking about succession and making it real. The project no longer had to wait for me to be available before the company could use the person it had just promoted.

That is what I mean by a first-order effect. Not the eventual career story. The immediate change in how work flows.

Look for the shape of the questions to change

One of the first things I notice during a healthy transfer is that the questions change.

At the beginning, somebody may need to ask, “How does this work?” That is normal. They are building context.

As the work starts to become theirs, the questions get more specific. They bring a tradeoff. They have a judgment they want to test. They can explain what they tried, what they found, and the decision they are ready to make. They might lead a pull-request review, run a standup, work through a troubleshooting path, or make a bounded technical choice without waiting for me to narrate every step.

That is a much better signal than silence.

Silence can mean the documentation worked. It can also mean that somebody is stuck and does not feel safe saying so. It can mean the system has not had to do anything difficult yet. It can mean stakeholders are still quietly bypassing the new owner and calling the person who used to own the work.

Fewer interruptions are nice. Demonstrated capability is better.

The documentation gives you another immediate test. Can someone follow the onboarding path and get the application running? Can they run the end-to-end test workflow that matters in this domain? Can they find the reason an important decision was made, not just a diagram of the current state?

If they can, good. If they cannot, that is not a verdict on them or on you. It is the next gap in the plan.

Gaps are feedback, not a reason to retreat into ownership

I think this is where the practice gets uncomfortable.

You give someone a piece of work. They run into a missing detail. A stakeholder is worried. The incoming engineer asks questions that make it obvious they do not yet understand the domain. An outstanding technical problem is going to get worse if you leave it alone.

It is very tempting to say, “Okay, never mind. I will take it back.”

Sometimes the work really is not ready to move. That is different.

I had a client project where I had built billing code, performed daily medical-billing processing, and become the primary support and troubleshooting subject-matter expert. The code and the process were documented. The client had not yet built the internal team with the skills needed to take the work safely, and the sensitivity of the material made transfer harder.

The first-order feedback there was clear, even if it was not the feedback I wanted: the documentation was not the limiting factor. Receiving capacity was.

The handoff was delayed almost nine months. I kept making the single-point-of-failure risk visible. I did not pretend that putting the process in a repository had somehow solved the problem.

There was a different kind of choice on a voice-interactive kiosk project. We needed to turn an early prototype into an on-site demonstration, with a 3D avatar, official scripts and voice acting, animation, and substantial AI improvements. The schedule and the unfamiliarity of the work meant a clean handoff would not happen in time. We knowingly deferred it to meet the live-demo goal.

I would make that same choice again. The right answer is not always “handoff now.” It is to see the tradeoff honestly instead of pretending that a concentrated bus factor has no cost.

Neither of those examples means you should abandon the transfer at the first sign of trouble. They mean you should figure out what the sign is telling you.

Is the gap documentation? Fix the documentation.

Is it practice? Narrow the work and let the next owner try again.

Is it authority? Make the ownership explicit with the stakeholders who keep routing around the new person.

Is it a real capacity or safety problem? Slow down, say so, and keep preparing rather than acting as if the handoff has already happened.

What I do not think works is quietly returning to shadow ownership. If the work has to come back, it should be handed back through an explicit conversation. Otherwise the new owner is nominally responsible while you are still doing the job. That is bad for both of you.

Do a readiness check that involves real work

The best immediate feedback comes from a real test, not a declaration that the handoff is complete.

Try to onboard from the repository documentation alone. Ask the next owner to lead a decision they have been preparing for. Let them run a support workflow that does not begin with you. See whether ordinary questions start going to them instead of around them.

You do not need to turn this into a scorecard. The point is not to measure your worth with a spreadsheet. The point is to create a moment where the dependency either holds or shows itself.

If it holds, you have evidence that the work is easier for somebody else to own.

If it does not, you have a more honest action plan than you did yesterday.

That is the first order of value: the team can see where the work still depends on you, and you can start reducing that dependency without waiting for an emergency to reveal it.

The second order is what becomes possible when that work really does begin to move. That is where the next article goes: not a promise of promotion, but the new opportunities that capacity and trust can create.