What Does an FDE Actually Do?

Managerial activities are characterized by brevity, variety, and discontinuity. — Henry Mintzberg, "The Manager's Job: Folklore and Fact"

Hangzhou, 11:30 p.m. An FDE's WeChat lights up: a customer calling to say the weekly-report bot has stopped sending messages. He remotes into the system, checks everything, finds nothing wrong — and finally sends someone to the site the next day, who discovers that someone had simply switched the machine off.¹

That same week in Silicon Valley, another FDE watches ten customer systems light up with alerts at once: an upstream Cloudflare outage, no contingency plan, an all-night firefight.

Same job, two very different nights. This chapter strips off the job-title filter and pulls the role's real rhythm, task mix, and emotional texture out of four real samples: two Silicon Valley playbooks (running many customers at once, or embedding deep with one), a brand-new hire in Japan, and an ordinary day on the Chinese side in Hangzhou.

I. Two Rhythms: Many Customers in Parallel vs. Deep On-Site

The first sample comes from Silicon Valley: an engineer with twelve years of experience who moved into a forward-deployed role in the last two years. He posted his own "week in the life": ten active customers, roughly fifty hours a week, meetings and actual building splitting the time about evenly, plus unplanned firefighting on top — the Cloudflare outage that opened this chapter was all ten of his customers' systems alarming at once.²

Worth reading line by line is the task mix: pushing forward multiple customer builds in parallel, presales calls, firefighting, weekly reports. Not one line reads "research algorithms." Someone in the comments asked him how the job differs from a traditional software engineer's. His answer was blunt — in some ways it's more satisfying, because the solution is his, start to finish.²

The second sample runs at a completely different rhythm, also American: the Baseten FDE from Chapter 1's time-budget breakdown (roughly three-quarters engineering and model optimization) moves into a support role once delivery wraps, staying with the same customer.³

Set them side by side: one is many-customers-in-parallel (ten customers, high-frequency switching, presales included too), the other is deep-on-site (a handful of customers, a bigger engineering share, staying on to run things after delivery). Same title, but the material conditions, the rhythm, and where the effort concentrates all differ — Chapter 18 already showed this is a function of market structure. The fact worth holding onto here: before asking what "an FDE's day" looks like, first ask which kind of FDE.

II. A New Hire's First Days Aren't Spent Writing Algorithms

The third sample comes from a new hire in Japan, two months into the job, whose account corrects the most common misconception. She had imagined this as "fighting alone on the customer's site." Two months in, the reality looks different: the project has just gone live, and the team is in the phase of waiting for customers to actually pick it up. Her days go to sorting out requirements, sometimes writing code, and following through until what the customer actually wanted becomes real.⁴

Two details carry the most weight. First, part of her job is sitting with the customer's admin to configure production permissions and authentication — a new FDE's starting point isn't algorithms, it's plumbing into the system (all of Chapter 10). Second, her working principle: rather than write the perfect spec, build a prototype the customer can actually try, watch how they react, and correct course on the spot — which is exactly the new-hire version of Chapter 7's Minimum Viable Deployment.⁴

III. Assembling a Week

Three samples, each weighted differently — put together, they form one composite weekly structure: Monday, on-site or planning meetings, aligning on this week's goals and risks; midweek, building and integration — writing code, wiring up permissions, running evals (the daily grind of Part Three); Friday, the customer's weekly report and eval review, letting the data do the talking (Chapters 12 and 13).

But that ideal cycle is only half the picture. The other half is production incidents that show up whenever they want (the midnight WeChat message, the outage upstream), requests shoved in at the last minute (the demo the boss suddenly wants, a customer calling an impromptu meeting), and the relationship maintenance that holds it all together — in the Chinese sample, that last item isn't a lubricant, it's a load-bearing wall. The ratio between these two halves largely decides which version of this job you end up experiencing (see Figure 23-1).

Figure 23-1: An FDE's working rhythm swings between on-site presence, engineering delivery, feeding lessons back internally, and ongoing support.

IV. A Day in China

Turn the lens back to China — the material conditions here run on an entirely different base. That midnight phone call from the opening — the weekly-report bot gone silent, traced back to someone casually switching off the computer — is a product of that base; Chapter 18's time budget of sixty percent spent untangling the business and maintaining relationships shows up, day to day, as exactly this rhythm.¹ The same account has an even more absurd detail: a customer showed up with a computer still running Windows XP to install the deployment package — and this was 2026.¹

The real fork in the road sits here: the "on-site prototyping" FDE the community describes spends most of a day anchored to one customer, building and revising a prototype — a narrow radius of responsibility, but deep and hard to detach from; the Silicon Valley many-customers type has a wide radius and a high switching cost.⁵ Same word, "a day" — completely different contents packed inside it. This is exactly Chapter 18's structural difference, playing out on an individual calendar.

V. A Ceiling That's Widening

Come back to the two numbers from Section I: ten customers, fifty hours. What lets one person carry ten at once isn't just individual capability — there's a factor now shifting underneath it: tool leverage. One Silicon Valley practitioner offered a directional read: tools like transcription and internal enterprise search could, in the short term, push how many projects a single FDE can carry at once from two or three up to five or six; over the longer term, the role will split — one end handling the hardest problems as high-end FDEs, the other serving small and mid-sized customers, sometimes never setting foot on-site, as remote FDEs.⁶

This lines up with Chapter 5's "execution-layer devaluation" argument: the same tools pushing up the output ceiling of "a day" are also stretching the role into different tiers. "A day" isn't a constant — it's a variable that tools are actively rewriting.

VI. The Honest Truth About How It Feels

Start with the upside. Back to that Silicon Valley engineer from Section I: end-to-end ownership — seeing the problem yourself, solving it yourself, hearing back from the customer yourself — is, for a twelve-year engineer who just switched roles, the most direct payoff.²

The downside runs two layers deep. The first sits on the client side: misconceptions about what AI can do, mismatched tech stacks, code that can't be delivered end to end, no security guarantees — endless rework, all of it landing on the front-line team.⁷ The second layer travels down the responsibility chain to the vendor side: the client's round-the-clock grind becomes the FDE's midnight WeChat pings, the system that's down and needs saving, the exhaustion of switching between customers all day long.

Same job — heaven for one person, hell for another. Only two variables draw the line: tolerance for ambiguity, and the need for ownership. People who can absorb interruption, live with vagueness, and genuinely need "this thing to be mine from start to finish" thrive in this work; people without those traits are worn down by it, continuously. These two variables are the last gate in next chapter's capability model.

VII. Thinking About This Path? Try Three Things First

You don't have to quit your job to find out. To test your own fit, try running these three scenarios where you already work:

Deliver something real for an internal user. Find a cross-departmental internal-tool need and carry it from requirements interviews through to running it live in production — feel what it's like to deliver when "the user is sitting right next to you."

Sit through one full customer engagement. From presales to post-sale, count how many "problems that aren't actually technical problems" show up in a single meeting.

Take over a system that's already live, and run it for a month. Even if it's just being on call — every alert after go-live, every "why doesn't this work anymore," is the daily texture of this job.

Run all three, and on both variables — tolerance for ambiguity, and the need for ownership — you'll get a more accurate answer than any personality test could give you.

The real texture of a day and a week is settled now. Who can handle it, and handle it well — the next chapter starts with the capability model.

---

Footnotes

1. Turning Point (破局点), Episode 31: "FDE, Chinese Style" ↩ ↩² ↩³

2. Hacker News, "A Week in the Life of a Forward Deployed Engineer" (10 customers, 50 hours) ↩ ↩² ↩³

3. Baseten, "What I Learned as a Forward-Deployed Engineer Working at an AI Startup" (Het Trivedi) ↩

4. "I Thought FDE Meant Fighting Alone at the Customer Site" — What Two Months on the Job Actually Looks Like ↩ ↩²

5. "Anyone Out There Actually Doing FDE Work?" (linux.do thread) ↩

6. Silicon Valley 101, Episode 240: "The Hottest New Job in Silicon Valley — FDE" ↩

7. "AI Job Sense: Stop the Agent Rat Race" ↩