What an FDE is
FDE stands for Forward Deployed Engineer. The military sense of “forward” is the point. This person does not sit at headquarters shipping a generic product. They sit inside the customer’s company, in its data, meetings, and stalls, and they write code there.
Palantir coined the name. Inside Palantir the work often splits in two. A Forward Deployed Software Engineer (FDSE) builds and deploys on the customer’s systems. A Deployment Strategist scopes the problem and lines up stakeholders. In Korea the title FDE often binds both jobs to one person.
Toss, AWS, Microsoft, Google, and OpenAI hire for this seat when they need their own product living inside a customer. The title is not the reason. Leave the customer’s building and the real problem disappears. A consumer product can be studied with surveys and screens. A B2B problem is invisible until someone is inside the firm, watching where a decision actually stops.
SI overlaps by about 80 percent
SI means system integration: connecting the systems a customer already runs, or building the system they asked for and handing it over. Korea has a long SI industry. Going on site, taking requirements, building, and sitting through acceptance is already a known flow.
An FDE also goes on site, hears a request, attaches a solution, and makes it run. Hype Check EP.3 estimates the overlap at about 80 percent. That is a judgment after unfolding the work, not a measured statistic. Abroad, people ask whether this is a rebrand of solutions architect, consultant, or SI engineer. The question is fair. If you only watch someone embed, build, and leave, the shape looks the same.
Renaming a job posting FDE does not change the work by itself. If the person still implements the screen list the customer wrote down, they are doing SI. The split is not the title. It is who writes the requirements, and when.
The other 20 percent is who writes the requirements
An RFP is a Request For Proposal: the document where a customer writes “build this.” Classic SI starts development after that document is already detailed. Screens, features, dates, and acceptance tests are already on the page. The engineer’s job is closer to implementing and shipping that page.
The person who writes it is often not the operator. A consulting firm takes the customer’s words and makes them concrete. The firm’s job is to put the customer’s vision into a document. Customers do not fully know their own problem. They over-read something that is not a bottleneck, or they skip the real one. Once that locked page reaches development, the engineer has no hours left to go back and rediscover the work. They fit a structure that is already planned.
An FDE reverses the order. They do not wait for a finished requirements pack. The first job is observation, not development. They watch which data people look at, in what order they work, and where a decision stalls. When someone asks for a dashboard, they do not draw the dashboard. They ask what the screen is for. On site, the problem may not be a missing dashboard. It may be that two departments read the same metric differently. Then the thing to build is the definition, not the screen.
| Item | SI | FDE |
|---|---|---|
| Source of requirements | Customer or consulting RFP | Problem written after field observation |
| Week-one output | Screen and feature list | Field notes |
| When build hours lock | Before kickoff | After the problem is rewritten |
| What the field leaves behind | Handover, then done | Data structure and decision patterns |
Four lines to put in the contract
The title is not enough. The company has to write, in the customer contract, that this is the order of work. The FDE also has to stop thinking of themselves as the person who implements what the customer said. If only one side moves, the site falls back to RFP implementation.
The four lines below are a working draft for a proposal or a Statement of Work. They are not legal advice. The one change that matters is this: the week-one deliverable is a field note, not a screen.
Without that clause the customer asks for a screen in week one, and the vendor has no ground to refuse once hours are locked. With it, “please build a dashboard” is the start of a question, not an acceptance.
Article n (Discovery week)
1. The deliverable for the first five business days is a field note, not software.
2. The feature list the client provided is a hypothesis. At the end of discovery week both parties rewrite the problem. Build hours and screen specs stay unlocked until then.
3. If a requested screen disagrees with field observation, the vendor may and must revise the problem before implementation starts.
4. Data structures, decision patterns, and metric definitions found in discovery week are kept as the client's internal documents, separate from the shipped software.Week one, Monday to Friday
A clause with no field rhythm does nothing. Use the five days like this. You do not need a development environment. You need a notebook and permission to follow one job for a day.
Monday: do not take a screen list. Follow one job through a day. Write who opens which screen, where they enter a number, whom they ask, and where they stop. Tuesday: pick one number that shows up in meetings — revenue, stock, wait time. Ask two or more departments how they read it. Wednesday: pick one stalled decision. Write one line on whether it is worth solving. Do not build a screen.
Thursday: write a minimum hypothesis from that problem only. “Team A and team B compute the same name differently. Aligning the name will shorten the meeting.” That is a hypothesis. Do not lock build hours yet. Friday: rewrite the problem with the customer. The build scope opens here. If Friday’s problem matches the customer’s first feature list, the list was never a hypothesis. It is allowed to differ. The difference is the week’s result.
Where a field-written problem became a number
Palantir’s public cases show how this order differs from delivering a spec. The figures below come from the hospital and from Palantir Impact, not from auto-captions.
Tampa General Hospital has used Palantir Foundry since 2021. A hospital release dated 5 June 2024 says patient-placement time fell 83 percent and post-anesthesia care unit (PACU) holds fell 28 percent. This was not a finished “disaster-response screen spec.” Patient data, staff, and beds lived in separate systems, so placement decisions ran late.
Panasonic Energy of North America pulled outage know-how out of veteran technicians’ heads, personal notes, and old work logs into a floor tool called Ask Atom. Tara Meisinger, a maintenance manager quoted on Palantir Impact, says a three-to-six-month learning curve fell to a few weeks. That is not what happens when you dump documents into a chatbot. Sensors, repair tickets, and unstructured files had to be joined before a new technician could reach the same question.
In 2015 Airbus used Foundry to put A350 schedules, crews, parts, and defects on one screen. Palantir Impact says A350 delivery accelerated 33 percent. In 2017 that structure grew into Skywise, an aviation-industry platform. The pattern is a sharp factory bottleneck first, then a platform. The FDE moat is not the shipped screen. It is the data structure and the decision pattern that come back into the company.
Cheaper implementation ships a wrong RFP faster
Generative AI did not kill SI. What changed is the cost of writing code and drawing screens. If the requirements are already exact, an in-house AI team can build the same screen with fewer people than before. That work is not what an outside FDE is for.
The work that gets more expensive is defining the problem. What the customer actually struggles with is often not a missing screen. It is not knowing what to automate. Implement a wrong problem with AI and the wrong screens multiply faster. That is slop. Volume of code is not the result.
So a company that runs FDEs has to name the order in the customer contract, and the FDE has to be able to ask for the intent under the requested screen. One person owns scoping through deploy, so the load is heavy. That load is also why the seat pays. The name does not matter. Development itself is moving closer to proposing a problem, building it, and persuading people it is the right one.
What to do today
Open the contract or statement of work for a project that is running or about to start. If week one lists a screen, a feature list, or a prototype, change that line to a field note. Paste the four-line draft. The point, before legal review, is whether the customer will agree to that order.
Pick one number that comes up in this week’s meetings — revenue, stock, wait, defect rate, any metric that shares a name. Ask two or more departments how they compute it. If the readings split, that split is this week’s problem. If they do not, pick the next number.
A discovery week still opens when the customer has already sent an RFP. You are not throwing the document away. Write “hypothesis” next to the feature list and rewrite the same list five days later. What remains is the real scope.