The FDE mindset

The classic consulting model separates thinking from doing: partners diagnose, analysts model, a deck lands, and delivery is somebody else's problem. That separation is survivable when the recommendation is an org chart. It is fatal when the recommendation is software.

In software, the decisive facts are only visible from inside. The data is dirtier than any interview reveals. The permission system nobody documented is the real architecture. The workflow's unwritten exceptions are where the value hides — and where the agents break. A recommendation written from outside the building encodes none of this. It compiles in the boardroom and fails in the repo.

Palantir turned this instinct into a delivery model: put engineers organizationally and physically inside the customer, give them the real data and the real users, and let working software be the consulting. Two details of that model matter more than the folklore.

First, the two hats. Palantir split the role between engineers who bend the platform to today's customer problem and engineers who feed what the field learns back into the product. Every workaround becomes a roadmap item; the field is the research department. Second, ontology-first integration: model the customer's business objects and actions once, and every subsequent application inherits them. That lesson — integrate meaning, not just data — is the subject of another essay on this site, and it came out of forward deployment, not out of a lab.

When the deliverable is a go-live, honesty stops being a virtue and becomes a constraint. You cannot hedge a deployment. Either the system works against real data behind real permissions, or everyone can see that it does not. That enforcement is the point.

Embedding also changes what the client keeps. A deck depreciates the day it is delivered. An embed compounds: every pull request is a teaching artifact, every review a transfer of taste, and the exit criterion is explicit — velocity holds after the engineer is gone. The measure of a forward deployed engagement is not what was shipped during it, but what the team ships after it.

The strongest counterargument: embedding does not scale. One engineer helps one team at a time, the good ones are scarce, and the client risks building around a hero who leaves. All true — and the objection misreads what is being scaled.

An embed does not scale like decks; it scales like training. The output is not consulting hours but a team that permanently builds differently, plus conventions and an integration layer the next team inherits. On dependence, the critique points the wrong way: decks create dependence, because you need the firm back to interpret them. A disciplined embed is designed to end — pairing from day one, rotating out of the critical path, measured on what happens after departure. If velocity drops when the FDE leaves, the engagement failed by its own definition.