Process Archaeology: The FDE Bottleneck You Can't Hire Around
May 26, 2026
Forward Deployed Engineering is having its moment. Y Combinator's job board went from zero FDE postings to over a hundred in eighteen months. OpenAI, Anthropic, Databricks, Scale, Salesforce — every lab and platform with enterprise ambition is staffing up. The Financial Times reported an 800% jump in FDE hiring interest since the start of 2026. Palantir's playbook, originally written in Kandahar and Tarin Kowt, has been rediscovered as the answer to enterprise AI's last-mile problem.
The discourse around the role is detailed, well-articulated, and mostly wrong about how the days actually go.
Read the blogs and you'll come away thinking an FDE is a senior software engineer with empathy — someone who sits at the customer site, opens an IDE, builds custom integrations, and ships a v0 in ten days. Some of that happens. But if you shadow an FDE for a week, what you'll see is a person spending the majority of their time doing something that doesn't look like engineering at all: figuring out how the customer's business actually works, and — harder — which parts of it are worth touching.
Not the slide-deck version. Not the wiki version. The real one — the one that lives in the heads of seven different people across four time zones, half of whom haven't talked to each other in a year, and at least two of whom will give you contradictory answers about the same process.
This is the work I want to talk about. Because it's where the FDE economics actually live, and almost nobody is costing it correctly.
The Hidden 60%
If you back out what an FDE does in a typical engagement, you find roughly three buckets.
The first, maybe 20% of the time, is the work you imagined when you wrote the job description: writing integration code, wiring up RAG pipelines, configuring agents, building evals, shipping the v0. This is what shows up in the demo.
The second, maybe 20%, is enterprise plumbing: SSO, network policies, security review, data residency, getting your container approved by the customer's platform team. Painful, but tractable — there's a playbook.
The third, which is the actual majority — 50 to 60% in most engagements I've seen across mid-market and enterprise — is what I'll call process archaeology. It's the work of reconstructing the customer's operation in enough detail and fidelity that an AI system can be designed around it without breaking in production, and then deciding which slice of that operation is actually worth designing around in the first place.
This is what process archaeology actually looks like, broken into its sub-tasks:
Finding the right people to interview. The org chart lies. The person with the title that sounds relevant ("Director of Operations") often doesn't know how the work gets done. The person who does know is a senior analyst on a different team, has been there nine years, and isn't on anyone's onboarding list. Finding them takes a week of meetings, half of which exist only to surface the question "wait, you should really be talking to Mei."
Scheduling the interviews. Once you know who to talk to, you need an hour of their time. They are busy. Their calendar is run by an EA who is suspicious of you. You will lose four working days waiting for slots.
Conducting the interviews. This is its own craft. You're trying to extract a process, but the interviewee describes their work as a list of things they do today rather than a sequence with inputs, outputs, branching conditions, and exceptions. You have to keep pulling them back. You have to know enough about their domain — procurement, claims adjudication, KYC review, whatever — to ask the right second question. And you have to do this in a register that builds trust, because the moment they think you're auditing them, the information stops flowing.
Reconciling contradictions. Person A says approvals go through Finance. Person B says approvals are routed through the regional GM in 70% of cases and Finance is a backstop. Person C, the GM, says she signs everything but only reviews the ones above . All three are telling you the truth as they experience it. The actual process is the union of all three with conditional branches none of them named.
Capturing exceptions. Every business process has a documented happy path and an undocumented exception map that is roughly 4x larger. The exceptions are where the value is, because they're where the work actually concentrates and where automation breaks. They are also nobody's favorite thing to talk about, because surfacing them is implicitly an admission that the wiki is wrong.
Deciding what's actually worth doing. The 3–10 conversations don't surface one workflow waiting to be automated. They surface five or six, in various states of pain and opportunity. Which one do you go after first? Which has enough volume to matter? Which has a clean enough boundary that an agent won't get stuck on the third edge case? Which one will the customer actually defend if the CFO asks for headcount reductions? Which is a tarpit dressed as an opportunity — high apparent ROI, but the kind of process where the last 20% of edge cases will eat eight months of engineering? These are calls the FDE has to make, often in the first two weeks, and they determine whether the engagement compounds into a $1M expansion or stalls in a $50k pilot. No rubric tells you the answer. The FDE's pattern matching — across domains, across customers, across what previously worked and previously failed — is the rubric.
Encoding what you learned. Once you've extracted, reconciled, validated, and prioritized, you need to turn it into something your team and the customer's stakeholders can actually build against — a design doc that captures the workflow plus the integration plan, a workflow map that the business sponsor will sign off on, and an eval suite that codifies the edge cases. The eval suite is usually the hardest of the three. Every exception you surfaced during discovery has to become a test case, or you will watch it break in production three weeks after go-live. That's not the discovery cost. That's just the cost of writing down what you found well enough that engineering can build against it without losing fidelity.
Add it up. A modest engagement — say, deploying an agent across a single business function — typically involves 3–10 stakeholder conversations of 45–90 minutes each. The interviews themselves are the cheap part. What they generate is the work: roughly 1–2 hours of post-processing per interview (note cleanup, workflow extraction, flagging what contradicted yesterday's source), plus cross-interview reconciliation that scales worse than linearly with the number of sources, plus the time to draft a coherent workflow representation, enumerate the exception map, codify it into eval cases, and write the design doc that engineering can build against. Call it 25–60 hours of non-interview work for a function of modest complexity — more for anything resembling a real enterprise process. And an unknown amount of back-and-forth that nobody tracks because it lives inside Slack threads and 1:1s. Two to four weeks of FDE time before a single line of integration code gets written.
This is the part that doesn't show up in the FDE blog posts. It's also the part that determines whether the engineering ever lands.
Why This Scales Worse Than Engineering
Here's the uncomfortable thing about the current FDE moment: model capability is increasing, but model capability isn't the constraint on enterprise deployment. Discovery is. And discovery is hard to scale for two distinct reasons that most function leads quietly conflate.
The first is the labor problem. Two years ago, a single FDE might spend 40% of their time wrestling with integration code — the API didn't exist, the SDK was thin, the auth flow was undocumented. Today, with a competent agent framework and the right toolchain, that same integration is a fraction of the work. Engineering productivity inside the FDE function is improving, fast. Discovery productivity is not. The hours required to find the right person, reconcile contradictory accounts, and codify the exception map into an eval suite haven't moved. As the engineering portion of FDE work compresses, the discovery portion becomes a larger fraction of the cost base. The bottleneck binds harder, not softer.
The second is the judgment problem, and it's the one your scaling plan probably isn't accounting for. Process archaeology isn't only labor-intensive — it's judgment-intensive. Almost every meaningful decision during discovery has no rubric. Which of the surfaced workflows to go after. Which exceptions matter enough to capture in evals versus defer. Which stakeholder is giving you the political version versus the operational version. Whether this workflow is a candidate for full automation, augmentation, or just better internal tooling. Whether the customer's stated priority is what they'll actually defend internally when the headcount conversation comes up. The answers depend on the FDE's domain experience, pattern matching across previous engagements, and political read on the customer. That blend is what people mean when they say "good FDE." You hire it; you don't train it on the job quickly.
Which means an FDE function is staking its scaling not just on hours of senior labor but on access to a specific blend of judgment that the open market doesn't price efficiently. Per Aspera describes the archetype as engineer-meets-domain-expert-meets-consultant — rare in any one of those traits, vanishingly rare in all three. Palantir's Echo & Delta split works because it acknowledges that one human can't reliably hold both poles, and built the org around the seam. Most companies trying to staff FDE functions today are quietly hoping they can find unicorns at scale. They can't, and the math is unforgiving: every engagement is gated on a person whose judgment is doing the heavy lifting, and that person's judgment lives in their head rather than in your systems.
What you end up with is a function whose throughput is bounded by your most senior people, whose patterns walk out the door when those people leave, and whose newer hires keep rediscovering the same lessons one engagement at a time. That's not scaling. That's running a services shop with a tech-company P&L. The Palantir economics, where revenue per FDE rises over time as field patterns get paved into the platform, were never about the engineering pattern getting reused. They were about the judgment pattern getting reused — what a senior FDE knows about which workflows to touch, which exceptions to chase, and which stakeholder signals predict pilot stall, becoming an asset that the system holds rather than the individual.
Written by:
Limesync Cofounder