Delta and Echo: why Palantir splits deployment into two roles, and how one FDE can play both

In your first week at a customer site, you will often get three conflicting requests in the very first meeting. The head of operations wants a dashboard, finance wants an Excel export, and the IT team has a single instruction: don’t touch the database. Part of you wants to open your laptop and start coding; part of you wants to ask ten more questions.

Palantir does not make one person carry both of those pulls. It splits deployment work into two separate roles, each with its own name: Echo and Delta.

If your team has not put an Echo beside you, you will be both Echo and Delta. In that case, the people who do well are the ones who know which mode they are in.

Two people, two different kinds of strength

According to descriptions of Palantir’s model, Echo is an analyst who sits with the customer and has genuine domain expertise. Echo handles discovery for the use case, drives adoption and manages the customer relationship. Echoes often come from the customer’s own industry, and according to one outside analysis, the person in the Echo role (also called a Deployment Strategist) is usually not a software engineer.

Delta is Palantir’s internal name for the Forward Deployed Engineer. This is an execution-focused engineer who takes the problem from Echo and builds a working prototype as fast as possible. According to the same outside analysis, Deltas go through the same technical interview loop as the engineers and architects who work on the core product.

They are not “second-tier engineers” sent out to the field.

Delta differs from the product engineer (Dev) in scope. Dev builds one capability for many customers; Delta builds many capabilities for one customer. The two roles also differ in how they work. Echo’s job is discovery: listening, observing and building a picture of how the customer actually operates.

For Delta, the key skill is writing code that can ship today, even while requirements are still changing and information is incomplete.

The value is in the handoff

There is a blunt line about how the two roles depend on each other: an Echo team without Deltas can only do relationship management and delivers no product. The reverse is easy to picture too. Delta without Echo codes quickly, but for a problem the customer does not actually have.

When you play both roles yourself, that brief usually lives only in your head, and that is exactly where it breaks. You think you understand the customer, when in fact you have only heard the loudest person in the meeting.

Example: late dispatches at a cold-storage warehouse

Imagine you are deploying for a cold-storage company. The initial request is to “build a dashboard to track late orders”. In Echo mode, you say nothing about dashboards yet. You go to the warehouse and sit next to the shift supervisor, and the conversation might go like this.

You: Were any orders late this morning?

Shift supervisor: Three. The truck had arrived but the goods hadn’t left the freezer room.

You: How did you find out?

Shift supervisor: The driver called. I opened the dispatch team’s Excel file and checked whether anyone had started picking that order.

You: If you’d known 30 minutes earlier, what would you have done differently?

Shift supervisor: I’d have pulled people from another area to pick it in advance.

At this point the problem has changed. The customer is not missing a dashboard. What they lack is an early warning when an order is close to its truck arrival time and nobody has started picking it. You turn that into a brief:

HANDOFF BRIEF — Cold storage, morning shift
1. User: shift supervisor, on the warehouse floor, phone only
2. Bottleneck: truck has arrived, goods have not left the freezer room
3. How they cope today: driver calls, supervisor checks the dispatch Excel file
4. Decision they want to make sooner: move staff over to pick the order
5. Minimum prototype and constraints:
   alert when an order is <30 minutes from truck time and nobody is picking it;
   read-only, never write to IT's database

Now you switch to Delta mode. The brief has fixed the user, the timing and the constraints, so you do not need a polished interface. A job that reads the dispatch file every five minutes and sends a message to the shift supervisor is enough to test during a single shift.

The brief also takes finance’s Excel export request out of this round, and you note it down for the next one.

Playing both roles: concrete steps

The first step is to separate your time. Set aside blocks in the day purely for observing and asking questions, and forbid yourself from proposing solutions during them. In Echo mode, the best questions are about where users get stuck and how they currently work around it, not about features.

The second step is to write the brief down before you code, even if the only reader is you. If you cannot fill in “the decision they want to make sooner”, you have not finished Echo’s job. Once every item is filled in, give yourself a short deadline for the prototype, because Delta has to ship while information is still missing.

The third step is to take the prototype back to the warehouse floor and return to Echo mode. Check whether users actually use it; that is the adoption work Palantir assigns to Echo. Then update the brief for the next round.

Three common traps

The most common trap for people with a technical background is skipping Echo. You hear “dashboard” and build a dashboard, then find out two weeks later that the main user stands on the warehouse floor and never opens a computer. The opposite trap is staying in Echo mode too long: meeting after meeting, excellent relationships, nothing shipped.

The third trap is harder to see: doing Delta work with a Dev mindset. You start generalising the alert for every warehouse and every order type, when Delta’s job is to solve many problems for this one customer.

The advice here is to note the places you see potential for reuse and leave them for the product side, rather than generalising on your own in the middle of a deployment.

Showing both roles on your CV

When you read a job description, check whether the company is hiring a separate “Deployment Strategist” or wants an FDE who also handles discovery. If it is the latter, don’t just list your stack on your CV. Write along this line: whom you observed, what problem the brief pinned down, what you shipped and after how many days. Written that way, recruiters will see that you can do both Echo’s and Delta’s work.

Palantir needs two people for this because each mode demands a different kind of attention. If you have to do both, the thing to practise is recognising which hat you are wearing before you walk into the meeting room.