Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Introduction — The Skill List Gets You in the Door
Requirement Archaeology — What They Need vs What They Asked For
Modeling the Domain Into a Shared Model — The Core Act
Integrating Into Messy, Airgapped, Legacy Environments
Demos, Stakeholders, and Setting Expectations
Knowing When to Say No — Avoiding the Over-Build
How Success Is Actually Measured — Adoption, Not Lines Shipped
The Honest Part — Being the Bridge
Closing
References

Introduction — The Skill List Gets You in the Door

An earlier post mapped the knowledge a Forward Deployed Engineer needs — Linux, networking, Kubernetes, databases, API integration, security — and paired it with an interactive checklist to track your progress across those domains. That map gets you in the door. It says almost nothing about what you actually do once you are inside a customer's building, which is a different and stranger craft.

Palantir frames the role by contrast: a regular engineer builds "one capability, many customers," while a Forward Deployed Software Engineer — a "Delta," in Palantir's internal name — builds "one customer, many capabilities," someone who "embeds directly with our customers" to make an existing platform solve their toughest problem. The skill list tells you what a Delta knows. The craft is what a Delta does with a single customer, over months, to turn their reality into something that works. Six moves make up most of it.

What the customer ASKS for
   |
   |   requirement archaeology   (dig for the real pain)
   v
What the customer NEEDS
   |
   |   shared domain model       (the contract both sides point at)
   v
What you BUILD  -- demo -->  feedback   (the model was wrong; repeat)
   |
   |   say no to the rest        (build only what moves the goal)
   v
ADOPTION   (they still use it after you leave)  =  the only score

Read top to bottom, that loop is the job. Named as six moves:

Requirement archaeology — dig past the request to the pain underneath.
Domain modeling — turn the customer's reality into a shared model both sides can point at.
Integration — wire that model into messy, airgapped, legacy systems where the data never matches the docs.
Demos — treat a working demo as the primary feedback instrument, not a sales prop.
Saying no — build only what moves the goal; refuse the rest.
Optimizing for adoption — the only score is whether they still use it after you leave.

The rest of this post takes them one at a time.

Requirement Archaeology — What They Need vs What They Asked For

The stated request is almost never the real one. It is a compressed artifact of a pain the customer has already half-diagnosed, and the diagnosis is often wrong. The gap shows up constantly:

They ask for a dashboard; they need a decision made faster.
They ask to export to Excel; they need to stop reconciling two systems by hand at midnight.
They ask for a faster report; they need to trust the number without re-checking it.

The FDE's first job is archaeology: dig past the request to the pain underneath it.

This is why the role is not consulting. The Pragmatic Engineer draws the line cleanly — consultants make "one-off recommendations," whereas FDEs work with customers long-term and own the outcome. You cannot hand a diagnosis to someone else and leave; you live inside it. The discovery work is concrete and unglamorous: sitting with the people who do the job, mapping their actual process, watching where value leaks. Palantir's engineers describe spending real time "talking to customers, who know the subject matter best."

And the ground truth keeps moving. As OpenAI's Colin Jarvis put it (via The Pragmatic Engineer), what the customer describes in scoping "doesn't match the data/system reality on the ground." So archaeology is not a phase you finish before building. It runs the whole engagement, and every demo is a fresh excavation.

Modeling the Domain Into a Shared Model — The Core Act

Here is the move that defines the whole job, and the one the skill list cannot teach. Once you know the real pain, you have to turn the customer's messy reality into an explicit model — the actual nouns and verbs of their business, the entities and the relationships between them — that both sides can point at and argue over. Palantir describes the daily work as "designing, writing and testing workflows"; underneath every workflow is a model of what the customer's world is.

The model is the contract. It sits exactly between "what they need" and "what you build," and it is the thing that makes both legible. When you and the customer disagree, you should be able to walk to the model and point: this entity, this relationship, this is where our understanding diverges. Without it, you are trading opinions. With it, you are debugging a shared artifact. This is also, not coincidentally, the split Palantir formalized into two roles — a Deployment Strategist who owns the problem and the model, and an FDSE who owns the software — though at OpenAI and Anthropic the single FDE now carries both.

Getting this model right is the highest-leverage thing an FDE does, and it is deep enough to deserve its own treatment. The next post in this series is about making the model formal — turning it into an ontology the software can reason over — and the one after that is about retrieving over that model with Graph RAG. For now, hold onto the principle: the model comes before the code, and a wrong model implemented beautifully is still wrong.

Integrating Into Messy, Airgapped, Legacy Environments

This is where the knowledge map from the prep post gets spent — but the craft is different from greenfield engineering, because the environment fights you in specific, repeatable ways:

Closed networks. Airgapped segments, private registries, and corporate proxies are the default, not the exception.
Data that lies. The real data lives in a legacy system nobody fully understands, and it never matches the documentation.
Scale you inherit. A Palantir engineer sums up the shape of the problem as, roughly, how to build and maintain a terabyte-scale pipeline feeding a workflow the business cannot afford to have go down.
A gate on every step. The customer's security team is a gate you pass, not an obstacle you route around — and a real limit on how fast you can iterate.

The craft here is reconciliation: holding your clean domain model in one hand and the actual dirty bytes in the other, and closing the gap without pretending either is wrong. A useful discipline, borrowed from how good FDEs work, is to prototype against synthetic data first — prove the shape of the solution — and only then wire it to the real source, where the surprises live. The model from the previous section is what makes this survivable: when the bytes contradict your understanding, you have an explicit thing to correct rather than a vague feeling that something is off.

Demos, Stakeholders, and Setting Expectations

A demo is not a sales artifact. For an FDE it is the primary feedback instrument — the fastest, cheapest way to discover that your requirement archaeology was wrong. Palantir describes the good version as a "rapid cycle between creating solutions and seeing them in action," iterating hand-in-hand with the customer. The demo that changes the customer's mind, or reveals that you misunderstood theirs, has earned its keep even if you throw the code away. The mechanics of that disposable-prototype approach are their own topic, covered in the throwaway-prototypes playbook.

Two craft points are easy to get wrong. First, the room is not one stakeholder — it is several, often divided, each measuring success differently. Part of the job is holding that room: naming the disagreement out loud and driving it to a decision instead of quietly building for whoever spoke loudest. Second, resist the too-polished demo. A demo that looks finished creates a promise you have not earned yet; showing the seams — what is real, what is faked, what is left — is what keeps expectations honest and keeps trust intact when the hard part arrives.

Knowing When to Say No — Avoiding the Over-Build

"One customer, many capabilities" is a description, not a license. It becomes a trap the moment you try to build every capability the customer asks for. Because you are embedded, because you want them to succeed, because saying yes feels like service — over-building is the FDE's default failure mode. Every feature you add is one you will have to maintain in an environment you will eventually leave.

The discipline is to build only what moves the customer's actual goal, and to say no to the rest — clearly, early, with the reason attached. The Pragmatic Engineer names this directly: the FDE is a bridge between customer success and product, and the bridge has to prioritize and say no to competing demands. Anthropic's FDE posting points the same way from another angle: the mandate is to "codify repeatable deployment patterns" and feed insights back to product — that is, prefer what generalizes over the one-off bespoke thing, precisely because the bespoke thing does not survive your departure.

How Success Is Actually Measured — Adoption, Not Lines Shipped

None of the moves above are scored on output. The Pragmatic Engineer is explicit that FDEs "measure success in terms of impact on the customer's goal" — fewer defective products coming off the assembly line, not lines of code deployed. Palantir's engineers describe the reward the same way: seeing first-hand the impact the software had on the decisions the client was making. The metric points at the customer's world, not your commit log.

The brutal, clarifying version of this is a single question: did they keep using it after you left? A beautiful system nobody opens is a failure, and a hardcoded prototype that becomes load-bearing in someone's daily work is a success. That question reframes everything upstream — the archaeology, the shared model, the demos, the discipline to say no all exist to serve adoption. There is a second axis, too, at product companies: what you learned inside the customer becomes the product. Anthropic literally asks its FDEs to contribute those patterns back to Product and Engineering. The best FDEs make themselves a sensor for the roadmap, not just a delivery mechanism.

The Honest Part — Being the Bridge

The hard part of this job is not technical. It is that you belong fully to neither side. You carry the customer's frustration back to your company and your product's limits forward to the customer, and you stand in the gap while both are still true. Ambiguity is the baseline, not the exception — Anthropic's posting asks bluntly for people who "operate autonomously, thrive under ambiguity," and every FDE posting says some version of the same thing.

Then there is the physical reality: travel of roughly 25% at Palantir, 25–50% at Anthropic, on the customer's timeline, inside their security perimeter, often as the single name they will call when it breaks. This energizes some people and quietly drains others, and it is worth knowing which one you are before you sign up. The craft is genuinely rare and it compounds fast — but it is paid for in a kind of homelessness between two organizations that the skill list never mentions.

Closing

The knowledge map makes you competent. The craft — digging for the real need, modeling the domain into something both sides can point at, integrating into a hostile environment, using demos as feedback, saying no, and optimizing relentlessly for adoption — is what makes you trusted. The first is a checklist; the second is judgment, and it only comes from doing the work in front of a customer who is watching.

If you are building the foundation, the knowledge map and its checklist tool are where to start. From here, the series goes deeper into the single highest-leverage move above: the next post makes the domain model formal as an ontology, and the one after that retrieves over it with Graph RAG. The code was never the hard part. Deciding what the customer's world actually is — that is the craft.