# An FDE's day runs on the customer's standup, not just your company's

> Strong FDEs triage whatever the customer sent the night before, then walk into the customer's standup ready to settle the most valuable work of the day.

Original: https://fdetimes.net/en/guides/fde-workday-customer-standup-triage/

Picture this: it is 8:40 on a Monday morning and you have just sat down at a desk in the customer's office. The customer's Slack has four messages sent on Sunday evening, and their Jira has a new ticket. At 9:00 the customer's engineering team holds its standup; your own company's standup does not start until 10:00.

Engineers used to product work tend to treat the 9:00 meeting as "the customer's thing" and the 10:00 meeting as the real job. FDEs think the other way round: Paraform observes that most forward deployed engineers work on the customer's schedule rather than their own company's.

FDE Academy likewise writes that FDEs embedded with a customer team attend the customer's standup too, and that this is the meeting where the day's priorities actually become clear.

If you are a developer looking to move into an FDE role, this may be the hardest habit to change, because it reverses how you decide what to do first. Sitting through the right meetings is not enough. What needs practice is three small habits: triaging before standup, hearing the blockers during standup, and turning what the customer says into tasks.

## The gap to fill lives in the customer's calendar

PostHog defines an FDE as someone placed in a customer's team to close the gap between what the product can do and what the customer actually needs, sometimes working directly from the customer's office. That gap rarely shows up in your company's backlog.

It usually surfaces at the customer's standup, for example when a data engineer complains that a pipeline is stalled because nobody has granted read access to a table.

You also spend more time at the customer than you might expect. A Palantir posting for a Forward Deployed Software Engineer on its US government side requires candidates to be on the customer's site 4-5 days a week, and describes the job as working directly with customers, often on site, to understand and solve their problems.

PostHog says its FDEs spend a lot of time in meetings, do much of their work directly with customers and often travel 20-50% of the time. When most of your week happens inside the customer's building, their rhythm becomes yours.

The sample week Paraform describes makes this plain. On Monday the FDE attends the customer's standup and sets the week's priorities around whatever is blocking them; only on Tuesday do they focus on building in the customer's environment, on real data and within the customer's deployment constraints.

**Key point:** The customer's standup is not where you report. It is where you find the most valuable work of the day.

## Before 9:00: arrive with answers

FDE Academy notes that customers often report problems asynchronously, so these need to be triaged before the workday begins, and it treats triage as the skill that most clearly shows which FDEs are strong. If you look after several accounts at once, this gets harder, because you have to decide for yourself which one needs attention first.

The aim of triage is that when you walk into standup you can say "I've looked at it, here's the hypothesis, here's the ETA" instead of asking "what happened?". Below is a hypothetical example with a logistics customer, starting with the most urgent item:

```
TRIAGE — Monday, before customer standup (9:00)
Sources: customer Slack (4), customer Jira (1)

[P0] This morning's inventory report is empty
  Impact: operations team can't confirm orders this morning
  Hypothesis: last night's ETL job failed reading the new table
  Next: check job logs, give ETA in standup
```

The other two items are lighter, plus one question that needs a customer decision:

```
[P1] Wants a "source warehouse" column added to the dashboard
  Impact: more convenient, but doesn't block anyone
  Next: ask in standup who uses it and what decision it informs
[P2] Asking how to export CSV
  Next: send the docs link, no need to raise in standup

Needs customer decision: who approves read access to the new table?
```

The ranking rests on three questions: is anyone blocked, who is blocked, and whose decision is needed to unblock them. The order in which messages arrived, or how urgent the sender sounds, is not a ranking criterion.

## In standup: translate what the customer says into tasks

According to Blockchain Council, when meeting customers an FDE's job is to turn requests like "we need better visibility into risk" into concrete technical tasks. Standup is where such sentences turn up most often, usually tucked between two progress updates, and they are easy to miss.

Continuing the hypothetical example above, the exchange might go like this:

```
Head of operations: This week operations needs better visibility into late-delivery risk. FDE: Where are you tracking risk today? Head of operations: An Excel file, someone updates it by hand on Friday afternoons. FDE: If you saw it earlier, what would you do differently: switch vehicles, warn the customer, or switch warehouses? Head of operations: Switch the dispatch warehouse.

FDE: How much warning do you need to switch warehouses in time? Head of operations: At least 24 hours.

→ Task: alert on orders at risk of being late at least 24 hours ahead, grouped by warehouse
→ Recipient: shift lead at each warehouse
→ Done when: shift leads receive the alert before the order cut-off
```

The whole exchange takes about a minute. You do not design the solution in standup; you ask just enough to know who will act, what they will do and how much warning they need. The rest is for a 15-minute conversation straight afterwards, followed by sending the task back in writing for the customer to confirm.

## The internal standup still matters, but its role changes

Putting the customer's schedule first does not mean skipping your company's standup. In the internal meeting you bring back the customer's blockers and state clearly what you need from the product or platform team.

Blockchain Council describes the FDE's working rhythm as a loop of triage, discovery, build, test, train, document, then repeat. Applied to a single day, the loop starts with the triage note before 9:00, moves to discovery during standup, and only then gets to opening the editor.

You can practise this sequence in your current job. Each morning, read every request that came in since the previous evening and write a three-level triage. In the meeting, raise P0 first with a hypothesis and an ETA, then listen for vague statements and keep asking until you know who will do what differently.

After the meeting, send the tasks in writing. At the end of the day, check whether what you worked on matched the morning's blockers.

## Five common mistakes

The first is attending the customer's standup as an audience member: listening, taking notes, but taking on nothing. The customer will quickly see you as an outsider. The second is bringing your company's agenda into the customer's meeting, for example reporting internal sprint progress when they only want to know when the inventory report will run again.

The third is triaging in the order messages arrived, or by whoever chases hardest. The fourth is debugging during standup, stretching a 15-minute meeting to 45 minutes and wasting the whole customer team's time.

The fifth is the hardest to spot: understanding the request in your head but not writing it back for the customer to confirm, only to discover on Friday that the two sides understood it differently.

## How to show this on your CV

When reading FDE job descriptions, look for phrases such as "on-site", "% travel" or "embedded with customer teams". They tell you whose calendar you will be living on. The number of days on the customer's site listed in a JD is the quickest way to picture a real working week in that role.

On your CV, instead of writing "collaborated with stakeholders", be specific: which customer team or internal users you met with daily, what kinds of requests you triaged, and which feature a vague request turned into because of you. Expect to be questioned in depth on exactly that story, so pick one you can tell in full detail.

Anyone can attend a meeting. What is worth practising is leaving the customer's meeting with exactly the right work in hand.

**Try this week:**

- On three mornings this week, before your first standup, spend 15 minutes writing a P0/P1/P2 triage note for the messages and tickets that arrived since the previous evening.
- Pick a recent vague request from a product owner or customer, go back with the question chain 'where do you look at this today, what would you do differently if you saw it earlier, how much warning do you need', then write it up as a task with done criteria.
- Rewrite one line on your CV to state specifically how you have worked at the pace of users or customers: whose meetings you attended, what you triaged, and what came of it.

## Sources

- [What is a forward deployed engineer? A complete guide (Paraform)](https://www.paraform.com/insights/what-is-a-forward-deployed-engineer)

- [A Day in the Life of a Forward Deployed Engineer: What the Work Actually Looks Like (FDE Academy)](https://fde.academy/blog/day-in-the-life-of-a-forward-deployed-engineer)

- [A Day in the Life of a Forward Deployed Engineer: Real-World Tasks and Challenges (Blockchain Council)](https://www.blockchain-council.org/ai/day-in-the-life-forward-deployed-engineer/)

- [WTF is a forward deployed engineer? (and why everyone is hiring them) (PostHog)](https://posthog.com/blog/forward-deployed-engineer.md)

- [Forward Deployed Software Engineer - US Government (Palantir, Lever)](https://jobs.lever.co/palantir/18a21bae-84ff-4f08-904b-10eb7511f65f)