Why the best FDEs work to make customers stop calling them

One practitioner quoted by Insight Partners set their team a goal that sounds self-defeating: to “literally work ourselves out of a job”. In a profession paid to sit close to the customer, that is the definition of doing the job well.

Many engineers have the opposite instinct. When you are the only person who understands the pipeline, knows why the prompt is written the way it is and how to rerun the evals, you feel valuable. The customer calls you whenever something goes wrong, and every call feels like a vote of confidence.

That is the trap. If you work as an FDE or want to become one, understanding early why being “irreplaceable” is a risk rather than an achievement will shape how you design each engagement, and how you talk about it in interviews.

FDE lock-in does not live in the code

When engineers talk about lock-in, they usually think of proprietary data formats or APIs that are hard to swap out.

Cohere points to a different kind, more specific to this line of work: “The more FDE-specific lock-in risk is operational dependency.” Cohere puts it in a category of its own, quite separate from technical lock-in, so the check you run has to differ too: not where the code lives, but who knows how to operate it.

Cohere spells out the consequence: an enterprise can own a deployment without having the capability to operate it. Picture it. The code sits in the customer’s repo, the infrastructure runs on the customer’s cloud, and the contract states plainly that the customer is the owner.

Yet when the system breaks at two in the morning, the only person who knows what to do works for another company.

More important, Cohere does not treat this as the unavoidable price of the FDE model. “Operational dependency is not an inevitable consequence of working with FDEs,” Cohere writes, and it goes further: deep vendor involvement should leave the customer more independent, not less.

In other words, dependency is the result of specific decisions made during the work, so it can be avoided by making different ones.

Design to leave from day one

Insight Partners distils its advice into one short line: “Solve the hard problem, then leave.” In its view, every engagement should be designed to end from the outset. Once the result is proven, ownership passes to the teams who will productise it and run it at scale.

Jason Martin of Databricks describes the model through the promise made to customers: bring your hardest problem, his team will solve it, and then “the IP is yours, we’ll hand it over to you”.

That promise only means something if the customer also receives the ability to use the IP. Handing over a repo nobody on the customer’s side can read is like handing over the keys to a car nobody knows how to drive.

That is why Cohere stresses timing. Building the customer’s capability has to run throughout the engagement rather than being treated as a last-minute handover exercise. A two-hour training session in the final week rarely turns anyone into an operator; several weeks of working side by side can.

Try counting: how many tasks can only you do?

Imagine a hypothetical 12-week engagement. You build a RAG system that helps an insurer’s claims team answer questions about policy terms.

The system has six recurring operational tasks: ingesting new documents, rerunning the eval suite, tuning prompts when quality drops, monitoring costs, handling errors when document formats change, and updating the list of test questions.

In the first version, you do all six yourself because it is faster. By week 12, the “tasks only the FDE can do” count still stands at 6 of 6. You leave; three weeks later the legal department changes its contract template, accuracy drops, and the first thing the customer does is call the vendor.

In the second version, from week two you ask the customer to assign an engineer to work alongside you. From week 3, one task a week moves from “FDE does, customer watches” to “customer does, FDE watches”, starting with low-risk work such as document ingestion and leaving the hardest, handling format-change errors, until week 8.

By week 8 the count is 0 of 6, and in the last four weeks you mostly observe, refine the runbook and deal with the genuinely hard cases.

Both versions deliver the same working system. Only the second delivers capability. Whether the count reads 6 of 6 or 0 of 6 is something you can track every week, put in the status report, and use to show the customer how close they are to not needing you.

Leaving the customer is not leaving the problem

There is a reasonable worry: if the customer no longer needs you, where does an FDE’s value lie? Rajkumar Irudayaraj of Alteryx answers by reframing the question. In his view, an FDE should be “a continuous learning loop for the company”, not “a permanent crutch for the customer”.

The value does not disappear when you leave; it moves elsewhere. Every time you have to write a patch yourself because the product lacks a feature, that is a signal for the product team.

PostHog’s FDE handbook requires such product gaps to go back to the owning team with good context, because good context makes the fix faster and the next customer never runs into the problem again.

Return to the insurance example. If errors from a changed contract template keep needing manual fixes, the right move is not to teach the customer to fix them by hand forever, but to write a ticket for the team that owns document ingestion: which documents broke, how they broke, and what the impact was.

Once the product handles it on its own, the fifth task on the list disappears for every customer, not just this one.

Two ways to run the same engagement

Set side by side, the two approaches differ in small decisions, not in skill.

Aspect	The “irreplaceable” FDE	The FDE who makes themselves unnecessary
Who operates the system	Only the FDE knows how to run evals, fix prompts and handle incidents	Customer engineers do it; the FDE observes and refines the runbook
When capability is built	One handover session in the final week	Throughout the engagement, one task moved each week
What the customer owns at the end	The deployment and the IP, but no ability to run them	The deployment, the IP and a team that knows how to run them
Product gaps	Patched by hand on site; only this customer benefits	Sent to the owning team with context; the next customer never hits them
Sign of success	The customer calls the FDE whenever something goes wrong	The customer no longer needs to call

The left-hand column is not technically wrong: the system runs and the customer is happy in the short term. But every cell on the left is a debt, paid by you, by the colleague who comes after you, or by the customer at the worst possible moment.

The story to tell in interviews

If you are preparing to move into FDE work, look through your current experience for a time you made yourself unnecessary to someone else.

It might be the runbook you wrote so the on-call team could handle a class of incident on its own, or the time you taught another team to run the data pipeline you built.

A story like that persuades far more than “I was the only one who could fix it”.

On your CV, state the handover outcome with concrete numbers rather than just “deployed system X”. A line such as “handed all 6 operational tasks to the customer’s 2-engineer team; customer ran evals independently from week 8” shows a recruiter you understand how an engagement ends.

When reading job ads, look out for words such as handover, enablement or working with product teams: they hint at how the company thinks about the FDE role.

If you are already an FDE, the first thing to do at your next customer is to list the operational tasks in the first week and ask the customer who will take on each one. The question may sound as if you are planning your exit. In fact it shows the customer you are planning for the day they can stand on their own.

The measure worth pursuing is not how often the customer calls you, but whether you leave behind a team that can do the work itself.