Echo and Delta: Two Halves of One Craft

Many people who have run their own startup assume that taking a Forward Deployed Engineer (FDE) job means giving up something. The reasoning goes like this: a founder owns the company, makes the decisions, and builds the product, so a role working inside a customer's organization must be a smaller version of that life. This belief is the most common misconception about the role. Correcting it reveals what the FDE role actually asks for, and it shows why the skills a founder has already built are the ones the role depends on.

The founder's experience has a particular shape. A founder rarely has a complete plan. They sell before they feel fully ready, ship before the work is polished, and spend time with customers whose needs do not match what they have built. They also make decisions with a small team when the answers are not clear. Put those experiences side by side with the demands of an FDE and the overlap is large. The same ambiguity, customer contact, and pressure to ship that define early startup life also define the FDE job.

The source also makes a claim about mindset that is worth holding onto. The temperament a person brings tends to determine whether they succeed in the role more than any single technical skill does. Specific tools can be learned. A willingness to work with ambiguity, to face customers directly, and to ship under pressure is harder to acquire quickly. For someone deciding whether the FDE path fits them, this means the question is less 'Do I know this framework?' and more 'Am I comfortable operating where the answers are not yet clear?'

The source describes a founder who did not feel the FDE role was a step down. The platform the role provided was, in his words, the platform he had been trying to build for himself. It offered direct access to enterprise customers, a working product to deploy, and a team of senior engineers to draw on. The trade was real: instead of holding common stock in his own company, he received an equity grant in someone else's company. The source notes that this trade was easy at the prices the market was paying.

Once the founder's skills are recognized as the right ones, the next question is what the FDE actually does with them. The source frames the job as two halves of one craft. The first half is called Echo. Echo covers understanding the customer's domain, identifying what is broken, and managing the relationship. The second half is called Delta. Delta covers building working systems and deploying software.

A useful way to hold the distinction: Echo is about knowing the customer's world and maintaining the relationship with the people in it. Delta is about turning what is understood into software that runs. The two halves are different, but the FDE role is one craft because both are needed on the same engagement.

The original structure at Palantir, as the source describes it, kept these two halves as separate people. The Echo was an embedded analyst with deep domain knowledge, such as a former military officer on a defense project, a former clinician on a healthcare project, or a former trader on a financial project. The Delta was the engineer who took the problem the Echo had identified and built a working system for it on a short timeline. The source argues the separation was deliberate, because the people who excelled at one half rarely excelled at the other.

Most AI startups today do not staff an Echo team. Instead, a single FDE does both halves at once. The source gives two reasons. Small teams often cannot afford to separate the roles. In addition, many AI customers have little history with the kind of system being deployed, so there is less established domain practice to become expert in. The source expects this consolidation to work in the short term, but as teams grow, some form of the Echo function tends to return. Teams that try to scale without it often find their FDEs stretched across customer relationships, domain learning, and engineering, and the quality of the engineering suffers.

The source's most useful point is not about who sits in which seat. It is that the FDE role contains two fundamentally different kinds of work, and an FDE must choose deliberately which kind they are doing at any moment. Discovery is the work that Echo was originally for: listening, observing, asking questions, and building a model of the customer's reality. Build is the work Delta was for: writing code, integrating systems, deploying software, and debugging.

Trace the state in the diagram. An FDE starts a stretch of work in one mode, Discovery or Build, and the mode they are in determines what they are doing. Moving to the other mode is a change of activity, not just a change of task. The source says the two kinds of work use different mental modes, different artifacts, and different rhythms, so moving between them is not free. The source also says an FDE must switch between them deliberately to keep an engagement moving. The source does not list specific signals that should trigger a switch, so the decision rests on the FDE's judgment about where the engagement stands.