Generic software stalls at the last mile

TL;DR: A vendor sells the same capability to everyone, but value only exists inside one customer's messy environment. The distance between those two things is the last mile, most pilots die there, and an FDE is the person sent to close it.

Where you are. First lesson of the course. Before any technique, you need the reason the job exists, because it explains every strange thing about how FDEs are hired and measured.

The gap nobody owns

Enterprise software deals have a shape. A vendor demonstrates a capability. The buyer agrees it would be valuable. A pilot starts. Then, often, nothing happens for four months and the pilot quietly ends. The retrospective calls it a change-management issue, everyone nods gravely, and the same fate is arranged for the next pilot.

The failure is rarely the product. The capability worked in the demo and it still works. What broke is everything between the capability and the place it was supposed to be used. Data sits in three systems with three different customer identifiers. The workflow exists in someone's head rather than in a document. An approval step nobody mentioned turns out to be mandatory. The security team has not been asked yet. And half the assumptions about outbound network calls are wrong.

Each of those belongs to a different role, and none of those roles owns the whole:

So the gap belongs to nobody, and work that belongs to nobody does not get done.

Why the answer is a person, not a document

The obvious fix is to write better documentation and hand it to the customer's own engineers. Companies try this first because it scales, and because it is cheaper, which is a compelling argument right up until it does not work. It fails for a reason worth understanding: the work in the last mile is not the execution of a known plan. It is the discovery of what the plan should be, and that discovery only happens with your hands in the actual data.

Nobody can specify in advance that the customer identifier in the billing export carries trailing whitespace on a stubborn minority of rows. Or that the workflow everyone described has an undocumented exception for one region. Or that the thing users actually want is not the thing their director asked for. Those are found by building against the real system and watching real people use it.

That is why the answer is an engineer who is physically or virtually inside the customer's environment, writing production code against their systems, for weeks or months. Not an advisor, and not someone who runs workshops about the plan: an engineer who ships, and who is still there when the shipped thing meets reality.

Palantir, which invented this role, made the split explicit in its own vocabulary. Its embedded engineers are Deltas and its core platform engineers are Devs, and the company's framing of the difference is the tightest one available: a Dev is one capability for many customers, a Delta is many capabilities for one customer. Same engineering bar, opposite direction of travel. For a stretch of Palantir's early history there were more Deltas than Devs, which tells you how much of the value turned out to live in the last mile rather than in the platform.

What this means for you

Three consequences follow, and they explain most of what feels odd about FDE hiring.

You are measured on adoption, not delivery. A feature that shipped and nobody uses is a failure, even if it matched the specification. This is the single largest difference from a product engineering role, where correctness against a spec is the job.

Ambiguity is the work, not an obstacle to it. In most roles a vague ticket is a defect in the process. Here the vague request is the raw material. Interview loops test this directly, which is why they hand you a deliberately underspecified problem and watch what you do in the first three minutes.

The bar is production, on someone else's terms. Your code runs in an environment you do not control, where you may not have direct access, and where a re-run that double-processes records is an incident rather than a failed test. Prototype habits do not survive here.

None of this makes the role harder than product engineering. It makes it different, and it explains why strong engineers sometimes fail the loop: they prepare for the coding round and get filtered by the round about the customer.

Do this before moving on

Find a real FDE job posting from a company you would consider. Read the responsibilities and sort every line into one of three buckets: things a product engineer would also do, things a consultant would also do, and things only this role does. The third bucket is small, and it is the actual job description. Keep the list. You will use it in the next lesson.

Go deeper

• What is a Forward Deployed Engineer? covers the origin of the role and where it is hired today, which this lesson assumes.
• Scoping ambiguous problems is the technique behind the second consequence above, and the one interviews probe hardest.
• Stakeholder management goes past the engineering into who has to agree before anything reaches daily use.
• Why customer-facing engineering? is the closing question in most loops, and your answer should now have a real reason behind it.
• Palantir interview prep shows how the company that invented this role still tests for it.

Key takeaways

• A platform is the same for every buyer; value only appears inside one customer's environment, and the distance between them is the last mile.
• That gap belongs to no traditional role, so it goes unowned, and unowned work is where pilots die.
• Documentation does not close it, because the work is discovering the plan rather than executing a known one.
• You are measured on adoption rather than delivery, which is the deepest difference from product engineering.

Check yourself

Answer before you look. Recalling it is what makes it stick; recognising it does not.

1. 1A pilot has stalled after four months. The capability demonstrated correctly and still does. What is the most likely cause?

   The product is missing a feature the customer needsWork in the gap between the capability and the customer's workflow was owned by nobodyThe customer's engineers are not skilled enoughThe pilot was under-resourced on infrastructure

2. 2Why can a vendor not close the last mile by writing better documentation?

   Answer it, then reveal

3. 3You shipped everything in the agreed specification and nobody uses it. In an FDE role, how is that judged?

   A success; the specification was metA neutral outcome; adoption is the customer's responsibilityA failure, because the role is measured on adoption rather than delivery