# One deployment, four audiences: how FDEs work with a client's engineers, business teams and executives

> The CTO, the chief accountant, the CFO and the clerk at the screen all look at the same system, but each asks a different question. An FDE who can answer only one of them will never get the deployment past the demo.

Bản gốc: https://fdetimes.net/en/guides/fde-stakeholder-management-four-audiences/

Picture a Tuesday. At 9am you sit with the client's CTO going through the API of their ERP system. At lunch the CFO asks what the system will save the company. At 4pm an accounts clerk admits she has not opened the tool once all week.

This is not an exaggeration. In its Founding FDE job ad, Stilla writes that you might have a working session with a CTO in the morning and then present the business case to the CFO over lunch.

Palantir likewise describes its Forward Deployed Software Engineer as someone who manages relationships with every stakeholder, from users struggling with day-to-day work to the executives who make decisions.

For a developer used to taking tickets from a single product manager, this is the biggest shock of moving into an FDE role. Nobody stands in the middle translating for you any more. That translation is the skill to learn: one technical problem, many audiences, each needing a different answer.

## Each group is really asking a different question

The first step is to stop treating "the client" as one person. An FDE's client usually involves at least four roles, and each brings its own question into the room.

The engineering team, meaning the CTO or engineering leads, asks whether the system will run reliably in their infrastructure. MongoDB describes its Staff FDE as a "trusted technical partner" to the client's engineering leaders. In other words, you must talk to them as a peer, not as a salesperson.

The business team, the people who own the process, asks how the tool changes their daily work. Executives ask what it is worth. Frontline users ask the simplest question and the hardest to answer: what do they gain by changing how they work?

Paraform defines stakeholder management precisely at this point of tension: building relationships with executives while keeping the frontline team pointed in the same direction. Drop either end and the deployment fails at that end.

**Điểm mấu chốt:** A solution succeeds only when it is technically correct and the client actually uses it. Missing either one is still failure.

This is not a slogan. According to an overview of the history of the FDE role, Palantir paired people responsible for the technology with people responsible for the client precisely because of these two goals.

## Example: one trade-off, three presentations

Imagine you are deploying an agent that reads supplier invoices for the accounts department of a retail chain. One technical decision has to be made: should the agent approve invoices on its own when its confidence exceeds a threshold, or must every invoice go through a human reviewer?

A high threshold means fewer errors, but more invoices are pushed back for manual handling. A low threshold automates more, but the risk of wrong payments rises. That is the whole problem, but each audience needs to hear it differently:

| Audience | The question they are really asking | How the FDE presents it |
|---|---|---|
| CTO, engineering lead | Is it controllable and traceable? | Precision at each threshold on the real invoice set, how the audit log is written, how to roll back when the agent approves wrongly |
| Chief accountant (process owner) | How much will my team still check by hand? Who is accountable for mistakes? | How many invoices the team still reviews each day, how "suspicious" invoices are surfaced, who gives final approval |
| CFO | Is it worth the effort? | A metric agreed in advance, such as days to close the books at month-end, plus an acceptable level of risk |

Note that you are not bending the truth for anyone. All three get the same trade-off; only the unit of measurement changes. The piece on the history of the FDE role says FDEs must patiently explain technical trade-offs to non-technical people. "Patiently" matters here, because you will often be explaining it for the third time.

To stop the three conversations drifting in different directions, pull them into a single document. A one-page definition of success might look like this:

```
Vấn đề: Đóng sổ cuối tháng chậm vì nhập và đối chiếu hóa đơn thủ công
Quy trình hiện tại: (do chính nhân viên kế toán mô tả, không phải do quản lý kể lại)
Thước đo thành công: ... (con số mà CFO đã đồng ý)
Người quyết định: ...   Champion: ...   Người dùng cuối: ...
Trade-off đã chốt: ngưỡng tự duyệt = ..., lý do ..., người ký: ...
Ngoài phạm vi giai đoạn này: ...
```

In English, the fields read: Problem (month-end close is slow because invoices are entered and reconciled by hand); Current process (as described by the accounts staff themselves, not as recounted by a manager); Success metric (the number the CFO agreed to); Decision-maker, Champion, End users; Agreed trade-off (auto-approval threshold, rationale, signed off by); Out of scope for this phase.

## Five steps to do it yourself

Step one is to map the four roles with real names, in the first week. Step two is to run discovery with both sides. Stilla requires its FDEs to work with both the engineering team and business stakeholders to learn exactly what the client wants. If you only ask the CTO, you end up with an elegant architecture sitting on a process you do not understand.

Step three is to map the process and agree the metric before writing code. Paraform describes this as running discovery sessions, mapping the organisation's workflows and defining what success looks like before implementation. Paraform calls this value scoping: identifying measurable outcomes that prove the deployment is worthwhile before committing engineering resources.

Step four is to use working sessions instead of slides. Stilla writes that FDEs lead hands-on working sessions with business stakeholders and executives to align on goals. Open their real data and tune the threshold in front of them. A decision they settle themselves lasts far longer than one you propose by email.

Step five is to look after adoption. Stilla describes this work bluntly: coach the champions, then track down each stuck user until their use case works. This usually requires being there in person, which is why MongoDB states that candidates must be willing to travel to client sites up to 30% of the time.

## The mistakes that quietly kill deployments

The most common mistake is talking only to people like yourself. Developers tend to feel comfortable sitting with the CTO and avoid the meeting with the accounts department. The result is a system that works correctly and that nobody uses.

The second mistake is the opposite: clinging only to executives. A director's signature does not mean you have users. That is why Paraform builds keeping the frontline team aligned into its very definition of stakeholder management. The logic is plain: after go-live, the people opening the tool every day are them, not the director.

The third mistake is leaving the success metric undefined. If the CFO has not agreed a number before you start coding, at the review you will be judged on a different one. The fourth mistake is using jargon with non-technical people.

"Precision 0.97" means nothing to a chief accountant; "your team will still review about this many invoices a day" does.

There is a subtler mistake too: misreading your own role. Paraform distinguishes the deployment strategist, who acts as a product manager for the client's problem, from the FDE, who handles technical execution. If your team has someone in the strategist role, coordinate with them rather than competing for the work. If not, you have to do that part yourself.

## Putting this skill on your CV and into interviews

When reading an FDE job description, look for phrases such as "executives", "business stakeholders", "champions" or "on-site". They tell you how much of your time will be spent outside the editor. If a job labelled FDE barely mentions them, ask directly in the interview how much you will be meeting clients.

On your CV, do not just write "built a reconciliation module". Write which department you worked with, what metric you agreed with them, and how many people actually used the tool. Many developers in Vietnam who work in outsourcing or on internal banking projects have sat with business clients without ever counting it as experience.

## This week's exercise

Take your team's most recent technical decision, whether choosing a cache, changing a data sync schedule or setting some threshold. Write three explanations, each no longer than three sentences, for the three audiences in the table above. Then ask a non-technical person to read the one written for executives.

If they come back with "so in the end, is it good or bad?", you know which part to rewrite.

Code makes the system work correctly. Whether each person on the client side keeps using it depends on how you work with them.

**Thử ngay tuần này:**

- Pick a project you are working on and fill in the four stakeholder roles with real names. For any role you have never spoken to directly, book a 30-minute meeting.
- Take your team's most recent technical trade-off and write three explanations, for the engineering lead, the process owner and the executive. Each no longer than 3 sentences.
- Rewrite one line on your CV from 'built feature X' to 'agreed metric Z with department Y, brought N users onto the tool'.

## Nguồn

- [Founding Forward Deployed Engineer @ Stilla | General Catalyst Job Board](https://jobs.generalcatalyst.com/companies/stilla-2/jobs/88903037-founding-forward-deployed-engineer)

- [Palantir Technologies - Forward Deployed Software Engineer (London, United Kingdom)](https://jobs.lever.co/palantir/5168e8fd-fec1-4fea-b7a1-81bdaea65850)

- [Staff Forward Deployed Engineer (MongoDB, via AlleyCorp Job Board)](https://jobs.alleycorp.com/companies/mongodb/jobs/88345358-staff-forward-deployed-engineer)

- [Forward-Deployed Engineer vs. Deployment Strategist: What's the Difference? (May 2026)](https://www.paraform.com/insights/forward-deployed-engineer-vs-deployment-strategist)

- [The Rise of the Forward Deployed Engineer: History, Myths, and Why It's Back](https://cloud-authority.com/the-rise-of-the-forward-deployed-engineer-history-myths-and-why-it-s-back.md)