The FDE 30/70 Myth: Turning Field Knowledge into Production AI

The FDE 30/70 Myth: Turning Field Knowledge into Production AI

“Forward Deployed Engineering is 30% technology and 70% business.”

It is a memorable line. It warns engineers that enterprise AI cannot be delivered by writing prompts and connecting an API while ignoring the actual workflow.

But it is not a universal staffing formula.

In one week, an FDE may spend most of the time interviewing operators and tracing exceptions. In another, the same person may be writing production code, debugging identity failures, building evaluations, or recovering a deployment. The mix changes by project stage, company, risk, and platform maturity.

The more useful idea behind the slogan is this:

FDE value does not come from owning a particular percentage of business work. It comes from translating field reality into a system that can be tested, operated, adopted, and reused.

That translation is the scarce capability.

OpenAI’s current FDE description spans discovery, technical scoping, system design, build, production rollout, adoption, measurable workflow impact, and eval-driven feedback. Palantir has similarly described its Forward Deployed Software Engineers as responsible for technical outcomes at a customer, sometimes contributing field-derived improvements back to the core product.

Neither description separates the role into a fixed 30/70 ratio. Both describe an end-to-end responsibility loop.

Why enterprise AI fails between the demo and the workflow

A generic model can produce an impressive answer with a clean example. A production workflow is surrounded by details that the demonstration does not contain:

• who is allowed to take the action;
• which system contains the authoritative record;
• which exceptions require human review;
• which rules change by region, customer, contract, or product;
• what an acceptable answer looks like;
• what a harmful error costs;
• and what should happen when the model, tool, data source, or downstream system fails.

This knowledge is rarely stored in one requirements document.

It lives in operator habits, escalation messages, spreadsheets, policy interpretations, approval paths, customer promises, and workarounds built over years. People may know how to perform the job without being able to explain every rule in advance.

That is why the common enterprise request—

“Use AI to automate this process.”

—is not yet an engineering requirement.

The work begins by discovering what “this process” actually is.

The real FDE artifact is a translation chain

An FDE engagement should progressively convert ambiguous knowledge into increasingly testable artifacts:

field observation
→ workflow and exception map
→ domain objects and rules
→ testable requirements
→ representative evaluation cases
→ permissions, integrations, and human controls
→ production and adoption metrics
→ reusable product patterns

Each step removes a different kind of uncertainty.

Without this chain, teams argue about impressions. With it, they can make release and investment decisions.

Four transformations an FDE must complete

1. Turn a complaint into a bounded outcome

Customers often begin with a symptom:

• search takes too long;
• analysts repeat the same work;
• service quality varies;
• approvals are slow;
• knowledge disappears when experienced staff leave.

The FDE must identify the user, moment, current behavior, baseline, desired result, constraints, and decision owner.

A stronger problem statement looks like this:

For [target user] performing [specific workflow],
reduce [measured delay or failure]
from [baseline] to [target],
without exceeding [risk, cost, or quality boundary],
as verified by [evidence and owner].

This prevents “build an AI assistant” from becoming the project objective.

2. Turn tacit rules into executable boundaries

Observation matters because interviews alone reveal what people remember to say, not always what they actually do.

The FDE should trace:

• actors and handoffs;
• systems and sources of truth;
• normal paths and exception paths;
• decisions and evidence;
• manual corrections;
• approvals and escalations;
• prohibited actions;
• and what happens after failure.

The goal is not to document every fact in the enterprise. It is to identify the minimum set of domain objects, relationships, rules, and actions that the target workflow needs.

For example, “customer,” “case,” and “recommendation” are not enough. Production design may also need account status, consent, jurisdiction, policy version, evidence source, reviewer, action state, and expiration.

3. Turn subjective quality into evaluation

“Looks good” is not a production threshold.

The FDE must work with domain experts to construct representative cases:

• common cases;
• high-value cases;
• edge cases;
• ambiguous cases;
• prohibited or adversarial cases;
• stale or conflicting data;
• and upstream or downstream failure.

Each case needs an expected behavior or scoring rubric. Some tasks permit exact answers; others require expert judgment across dimensions such as factuality, completeness, policy compliance, usefulness, tone, or appropriate abstention.

The evaluation design should distinguish:

1. model or task quality—did the system produce an acceptable result?
2. system behavior—did tools, retrieval, permissions, and fallbacks work?
3. workflow outcome—did the user complete the job better?
4. risk behavior—did the system remain within allowed boundaries?

Google Cloud’s production GenAI guidance similarly emphasizes task-specific evaluation data, early stabilization of metrics, end-to-end testing, versioning, monitoring, and continuous evaluation. The specific tooling may vary; the discipline does not.

4. Turn one successful deployment into organizational leverage

A customer result is valuable. A repeated way to produce the result is more valuable.

After delivery, the FDE should separate four layers:

Not everything should become a core feature. Some patterns belong in configuration, services, documentation, or training. Productization means choosing the correct reuse boundary—not moving every field request into the platform.

What “70% business” should actually mean

Business understanding is not attending more meetings or learning industry vocabulary.

It means being able to answer:

• Which decision or action creates value?
• Who owns it?
• What evidence supports it?
• Which exceptions change the path?
• What is the cost of delay, error, or unnecessary review?
• Which incentives might block adoption?
• Which constraints are negotiable?
• What must remain under human authority?
• How will the result be measured after launch?

An FDE who cannot answer these questions may build the wrong system quickly.

But business fluency does not compensate for weak engineering. If the solution handles sensitive data, calls enterprise tools, writes records, or supports an important decision, production-grade software practices remain mandatory.

The point is integration, not dilution:

business context without engineering
= recommendation that may never run

engineering without business context
= system that may run without creating value

FDE
= field evidence translated into a reliable operating system

The field discovery pack

Before committing to a large build, an FDE should be able to produce a compact discovery pack.

1. Outcome brief

• target users and workflow;
• baseline and desired result;
• economic or operational importance;
• sponsor and acceptance owner;
• explicit non-goals.

2. Current-state workflow map

• actors, steps, systems, decisions, handoffs;
• normal, exception, and escalation paths;
• sources of truth and data owners;
• delays, rework, and manual controls.

3. Constraint and risk register

• data sensitivity and retention;
• identity and permissions;
• legal, contractual, and policy boundaries;
• unacceptable errors;
• human oversight;
• failure, fallback, and rollback.

4. Evaluation plan

• representative cases and edge cases;
• quality rubric;
• baseline;
• release threshold;
• reviewers and disagreement process;
• production feedback loop.

5. Delivery and adoption plan

• smallest credible release;
• integration sequence;
• training and workflow change;
• operating owner;
• production, adoption, and business metrics.

6. Productization hypothesis

• what appears reusable;
• what must remain configurable;
• which assumptions require another deployment;
• who receives the asset after the engagement.

This pack is more valuable than a generic solution deck because every section can be tested.

Four common translation failures

Building from the stated request

The customer asks for a chatbot, so the team builds a chatbot. No one confirms whether the real bottleneck is retrieval, decision support, data quality, approval latency, or system action.

Encoding the happy path only

The demo covers clean inputs and one successful outcome. Production users encounter missing data, conflicting policy, duplicate actions, permission gaps, and uncertain cases.

Measuring the model instead of the workflow

Answer quality improves, but review time increases. Users copy the output into another system manually. The project reports model accuracy while the business outcome remains unchanged.

Productizing too early

One customer’s terminology and workaround are promoted into the core product before a repeatable pattern exists. The platform becomes a collection of disguised customizations.

Is there really a 12-month golden window?

There is a genuine market signal: organizations are moving from model experimentation toward production deployment, and current FDE roles emphasize adoption, evaluations, workflow impact, and product feedback.

But no public standard establishes a universal 12-month window after which the opportunity disappears.

Career timing should be based on capability compounding, not countdown marketing. A candidate who spends the next months completing one credible production-shaped project may be better positioned than someone who rapidly memorizes role vocabulary.

The durable opportunity is broader:

• model capability is becoming easier to access;
• business context remains organization-specific;
• production integration remains difficult;
• trustworthy evaluation requires domain evidence;
• and reusable field learning remains scarce.

Those conditions create demand for people who can cross boundaries.

What compensation actually signals—and what it does not

High compensation can indicate that companies value the combination of engineering depth, customer trust, ambiguity management, travel, and outcome ownership.

It does not establish a universal FDE salary.

For one concrete reference, the OpenAI San Francisco FDE posting checked on July 30, 2026 lists $162,000–$280,000 in base compensation plus equity. Total compensation can differ materially because of level, location, equity valuation, company, and offer structure. A broad claim that FDEs generally earn $500,000–$1 million per year should therefore not be treated as a market-wide benchmark.

Compensation is the result of scarce capability and company economics—not a substitute for understanding the work.

A practical path for aspiring FDEs

Step 1: Choose a workflow, not an app idea

Pick a real process with users, cases, exceptions, and a measurable result.

Step 2: Conduct field discovery

Interview at least the process owner and frontline users. Observe real work where possible. Build the discovery pack.

Step 3: Create an evidence-driven prototype

Use representative cases. Define the evaluation before polishing the interface. Record failures and disagreements.

Step 4: Add one production boundary

Implement identity, permission-aware retrieval, a real integration, human approval, monitoring, or rollback. Show that you understand the difference between a demo and an operating system.

Step 5: Measure workflow change

Compare the new process with the baseline. Include review effort, adoption, overrides, cost, and failure handling—not only model quality.

Step 6: Write the productization memo

Explain what should be reused, configured, redesigned, or discarded. This demonstrates the reverse-product-management loop that distinguishes strong field engineering.

Final takeaway

The 30/70 formula is useful only if it changes an engineer’s attention.

It should direct attention away from isolated model capability and toward the complete operating context: users, decisions, exceptions, evidence, systems, permissions, incentives, risks, adoption, and reuse.

The best FDE is not the person who spends exactly 70% of the week discussing business.

It is the person who can walk into an ambiguous workflow and progressively make it explicit:

pain becomes an outcome
experience becomes a rule
rules become tests
tests become controls
controls become a production system
production evidence becomes product learning

That is how AI moves from an impressive example into real work.

And that is why business-literate engineers—and engineering-literate business problem solvers—will remain scarce long after today’s role labels change.

References and further reading

• OpenAI: Forward Deployed Engineer—San Francisco
• Palantir: Dev versus Delta—Demystifying Engineering Roles
• Palantir: A Day in the Life of a Forward Deployed Software Engineer
• NIST: AI Risk Management Framework Core
• NIST: AI RMF Playbook
• Google Cloud: Deploy and Operate Generative AI Applications
• Google Cloud: Generative AI Evaluation Service Overview