Making Yourself Fireable — Consulting Without Trapping the Client.

Making yourself fireable — Part Five

There is a strange thing about trying to make yourself fireable as a consultant.

If you say it too directly, it can sound like you are planning your exit before the work is done.

I understand why a client might hear it that way. They hired a consulting team because they have a problem. They need the problem solved. If the consultant starts talking about making themselves unnecessary, it can sound a little like, “Good luck with that.”

That is not what I mean.

I think a consultant should not need a client to remain dependent in order to be valuable. The work should leave the client more capable where it can. The technical context should be durable. The people who will own the system next should have a real chance to learn it and lead it.

That does not mean every engagement should end with the client fully independent. Sometimes the client does not have the staff, authority, time, or specialized knowledge to receive a handoff safely. Sometimes the deadline is real enough that a clean transition has to wait.

The hard part is that both of those things can be true while the business incentives are pulling in different directions.

The tension is real

Clients generally want work done quickly and as cheaply as possible. Consultants want to be paid fairly and have enough time to deliver quality work. I do not think it helps to pretend those interests line up perfectly.

They can become a kind of codependence.

A client can become dependent on the consulting team because the consultants hold the technical context, make all the important decisions, and remain the only people who can respond when something goes wrong. The consulting team can become dependent on the client too. One reliable engagement can become so important that nobody wants to risk changing the relationship, even when the client needs to build more internal capability.

I am not saying that every long engagement is unhealthy. Some problems need long-term expertise. Some clients deliberately want an ongoing partner. The question is whether the dependence is an honest choice or simply the result of nobody making the work transferable.

This is also where I need to name a limit. I am a senior individual contributor. I do not have a model for how consultancies should price, scope, or contract for capability transfer. Those are real commercial questions, and I do not have the expertise to hand somebody a framework that solves them.

What I can talk about is the work I have done inside an engagement: make technical context durable, help the next team learn it, state when the handoff is unsafe, and respect the client’s right to lead its own system.

Let the client own its own system

One healthcare engagement began as an MVP. The consulting team was there to help establish the business case. Once the business case was proven, the client hired staff to build the full product.

The transition took longer than originally planned. That was not because the incoming team was incapable. It was because the consulting team had to be willing to give up leadership control and follow the client team’s lead.

The client chose a new technology stack—the one its new team knew best. They expected pushback. Instead, we helped them troubleshoot and deploy it.

I think that matters. The client did not owe us permanent technical ownership just because we had built the MVP. If their team was going to live with the system, they had a legitimate interest in choosing technology it could understand and support.

That choice may not always be the one I would make. That is not the point. A consulting team can become so identified with its own implementation that it starts treating client autonomy as a threat. I do not want to be part of that.

Leave behind more than the running system

I saw a different version of this on a technical-support chatbot for vehicle mechanics. It was the client’s first custom AI system; before that, it had used out-of-the-box agent solutions. The team did not have internal subject-matter experts, and the project became more complicated than anyone expected.

As the work wound down, the consulting team focused on handoff and helped the client’s staff through production launches.

For an AI system, the handoff is not only the deployed application. The next team needs the context for how the system became what it is: experiments, evaluations, prompt test cases, and the history of how a system prompt evolved and was evaluated. Without that, a prompt change after handoff can become a guess. The new team has no baseline for deciding whether it improved the system or quietly made it worse.

The client valued gaining a more advanced capability without being explicitly dependent on the people who introduced it. They continued finding work for us.

I do not want to claim too much from that. The continued work could have come from any number of things. It does not prove that the client was fully autonomous, and it does not prove that enabling a client mechanically produces more revenue.

But I would rather earn future work because a client trusts us to help them become more capable than because they are afraid they cannot operate without us.

Sometimes the transfer has to wait

There is a bad version of this argument where the consultant ships documentation, announces a handoff, and treats any remaining problem as the client’s problem now.

That is abdication. It is not fireability.

On one project, we had to turn an early prototype into an on-site demonstration: a voice-interactive kiosk with a 3D avatar, official scripts and voice acting, animation, and substantial AI improvements. We knew the schedule and unfamiliarity of the work meant we would not have time for a clean handoff.

We deferred it to meet the live-demo goal. That created future handoff cost. I would make the same choice again.

The intended deployment environment disappeared during the 2020 pandemic, so the project did not continue. That does not make the tradeoff imaginary. It means the project ended before that future cost came due.

I have seen a slower, more uncomfortable version of the same problem in medical billing. I had built the billing code, was performing the daily billing process so patients could be invoiced, and had become the primary support and troubleshooting subject-matter expert. The code and process were documented. The client was building an internal team from scratch, but adding the specific skills needed for the handoff was not its highest staffing priority.

The material was sensitive, and there was not an easy way to hand it to someone who was not ready to receive it. I made clear that this was a costly single point of failure and that using a software architect for ongoing billing was expensive. The handoff still had to wait almost nine months.

Documentation did not make the client ready. It made the risk visible and kept the work ready for a future handoff.

That distinction matters. Sometimes the responsible action is to keep carrying the work while making the dependency plain. A clean handoff has to be delayed when the receiving capacity does not exist.

Leave the relationship stronger than you found it

I do not have a clean answer for the commercial tension in consulting. I am still figuring out where the line is between helping a client become capable and making it look like I am preparing to leave them behind.

For now, I try to demonstrate the practice more than announce it. I make the system easier to support. I put the important context where the next authorized person can find it. I help people take real ownership. I say clearly when the work is not ready to move.

That will not resolve every incentive problem. It will not tell a consultancy how to price an engagement. It will not create a client team that does not yet exist.

It can keep me from confusing a client’s dependency with my own value.

On a current engagement, ask two questions:

What capability will the client retain if our team is unavailable next week?

What condition would make a handoff unsafe today?

Bring the answers into the appropriate conversation—inside the consulting team, with the client, or both. If the answer to the first question is “almost nothing,” do not use that as evidence that the engagement is going well.

It may be the most important problem on the project.