Section A · Orient

The Role, Decoded

What "Forward Deployed Engineer — Data Engineering" actually means at an enterprise contract-intelligence / document-AI platform, what the JD signals, and where you sit between the product and the customer.

The platform space

The product category is enterprise contract intelligence and spend analytics. The customer is a Fortune 1000 finance, procurement, or legal team sitting on:

Tens of thousands of contracts (master service agreements, statements of work, supplier agreements, NDAs, leases).
Millions of invoices, purchase orders, and supplier catalog records.
Existing systems of record (ERP, CLM, procurement suites, BI) that don't talk to each other cleanly.
Pain points the executive team can name in one sentence: "we don't know what we're contractually obligated to," "we're being overbilled and can't prove it," "we can't see total supplier spend across the org."

The platform's pitch is: turn the unstructured document pile into a queryable, analytics-ready data layer, with accuracy guarantees, without forcing the customer to staff an internal AI team. Hybrid AI architecture — NLP, computer vision, neural networks, and human-in-the-loop review — backed by SLAs on data accuracy.

Three things that make this product different from a generic CLM (contract lifecycle management) tool:

Data, not workflow. Legacy CLM is "where does the contract live and who signs it." This space is "what is in the contract, and what does it imply for spend, risk, and renewal."
Non-templated documents. The system has to handle whatever ugly PDF or Word doc the customer's procurement team has accumulated over 20 years. Document variance is the hard part.
SLA-backed accuracy. The product isn't a model API; it's a managed outcome with contractual quality commitments.

What the role is

"Forward Deployed Engineer — Data Engineering" combines two roles you've probably seen separately:

Forward Deployed Engineer (FDE) — the Palantir-originated role of "engineer who embeds with the customer, scopes ambiguity, ships the first useful thing fast." Now standard at frontier-AI companies (Anthropic, OpenAI, Scale) and applied-AI platforms.
Data Engineer — owns the pipelines that move and transform data, the data model, the warehouse loading, and the integration with downstream consumers.

Put together, the role is: the engineer who lands on a customer site, figures out their data shape, builds the pipelines that get their corpus into the platform, co-designs the data model for their specific document patterns, iterates on extraction quality, and wires platform outputs into whatever the customer wants to do with them.

The work has three modes that interleave week to week:

Discovery mode. First two weeks at a customer. Read their contracts, talk to their data team, learn their ERP, understand the actual question they're trying to answer.
Build mode. Stand up ingestion, configure extraction for their document patterns, get the first end-to-end slice running in a staging environment.
Polish / scale mode. Hit the SLA, expand coverage to more document types, integrate with the customer's BI / warehouse, hand off where appropriate to a customer success motion.

The implicit org placement

FDE-DE typically reports into a Forward Deployed or Solutions Engineering org, not into core platform engineering. Day-to-day partnership is with:

Platform engineering — when extraction quality needs platform-level work (new model, new layout class, new connector).
Customer success / account exec — for relationship, expansion, contract scope.
Customer's data / IT team — your daily interface.
Customer's procurement / finance / legal leads — your business-side interface.

What a week actually looks like

Real week from an FDE-DE at a contract-intelligence platform (composite — not any specific person):

Monday morning: customer kickoff call, review last week's extraction-quality report, agree on this week's coverage targets.
Monday afternoon: pair with the customer's data team to debug why their Coupa export is missing PO line items.
Tuesday: build a new ingestion connector for a vendor catalog format the customer has 800 of.
Wednesday: write the SQL that rolls up obligations by supplier and posts results to their Snowflake. The customer's data analyst will reuse this — make it readable.
Thursday: extraction quality on a specific document class is below SLA. Triage with the platform team (it's a layout regression on rotated PDFs), put a temporary HITL workflow in place, file the platform bug.
Friday: status doc to customer leadership. What shipped, what's open, what would unblock more progress. Ship by noon.

If the description above sounds appealing, you're calibrated for FDE. If "I'd rather just build the platform than talk to a customer" sounds appealing, this isn't your role.

The stack, decoded

FDE-DE JDs at platforms in this space typically name:

JD phrase	What it means
"Strong Python and SQL"	Daily-use languages. Python for ingestion/cleaning scripts; SQL for the data layer and for talking to customer analysts.
"ETL / pipelines at production scale"	You'll inherit or build dbt-style transformations, batch ingestion DAGs, sometimes Spark for big customers.
"Snowflake / BigQuery / Databricks"	The customer's warehouse is where your output lives. Know the major ones; pick whatever they have.
"Experience with unstructured / document data"	OCR, layout-aware models, NER. You're not training these from scratch — you're wiring extraction outputs into structured stores and surfacing failures.
"Customer-facing experience" / "consulting background a plus"	The FDE half. You'll be in customer rooms weekly. If you have Palantir / Accenture / Deloitte / Big Four data-consulting experience, surface it.
"Comfort with ambiguity"	Standard JD phrase. The real signal: can you produce a defensible scope from a half-formed customer ask within days, not weeks?
"Travel as needed" or "willing to be on-site"	Enterprise customers sometimes want bodies in rooms, especially for kickoff. Not a deal-breaker but mentioned in most FDE JDs.

JD signals to read

"Drive customer outcomes" / "translate platform capabilities into business value." This is the FDE tell. The role is judged on what the customer can do with the data, not on how clean your DAG is.
"SLA" / "data accuracy" / "audit-ready intelligence." Quality is a first-class deliverable. Expect a round that asks about extraction quality measurement.
"Highly customized, non-templated documents." The customer's data is messy and varies by customer. Pipelines that work for one customer often break for the next. Comfort with that is the bar.
"Innovate faster" / "10% cost reduction" / "supplier intelligence." Sales-side language but it tells you what the customer is buying. Internalize it for the founder round.
Tools list excluding workflow tools. If the JD names dbt, Snowflake, Airflow but doesn't mention Salesforce or ticketing systems, the role is more data-heavy than customer-success-heavy.

FDE-DE vs adjacent roles

Role	Key difference
Senior Data Engineer (internal)	Builds shared platform; doesn't sit with customers. FDE-DE is customer-facing every week.
Solutions Engineer (pre-sales)	Demos, scopes deals, hands off to delivery. FDE-DE owns the delivery, not the sale.
Customer Success Engineer	Mostly relationship + light technical. FDE-DE is mostly technical with relationship as a deliverable.
Implementation consultant (Big Four)	Configures a product. FDE-DE writes code, owns pipelines, ships changes. More engineering than configuration.
Applied ML engineer	Owns model improvements. FDE-DE consumes model output and shapes it for customer use; model improvement is platform team's job.

What to ask them

"Walk me through a recent deployment — what was the customer ask, what was the first thing shipped, what took longest?"
"How is the FDE function sized today, and what's the ratio of FDE-DE to platform engineers?"
"What's the longest a customer deployment has run? What does 'done' look like?"
"How do FDEs hand work back to platform when something is structurally broken?"
"What's the most common reason a deployment slips, in your experience?"
"What's the difference between a great FDE and a good one, in your shop?"
"What does the trajectory look like — does FDE-DE move into platform engineering, into leading other FDEs, into a vertical lead role?"

Strong ones for a senior call:

"What's the SLA you stand behind today, and where does it bend?"
"What's the analytical problem you've helped a customer solve that surprised you?"

✓ Check yourself

Answer from memory before opening each one.

A job description asks for strong Python and SQL, names an accuracy SLA and audit-ready data, and lists dbt, Snowflake and Airflow but no sales or ticketing tool. What does that combination say about how you will be judged and what the week looks like?

Show answer
It says the role leans toward data work over account work, and that quality is a deliverable. You are judged on what the customer can do with the data, so expect a round on how you measure extraction quality. See JD signals to read. Quality measurement is the subject of Quality and Evaluation.
A legacy contract lifecycle tool and this platform both store contracts. What is the difference in what they sell, and how does it change what you build first for a new customer?

Show answer
A legacy tool answers where a contract lives and who signs it. This platform answers what is in the contract and what that means for spend, risk and renewal. So the first build is a path that turns the customer's document pile into queryable, accuracy-backed data, not a workflow setup. See the platform space.
A friend says the role is a senior data engineer who also joins customer calls. Give two things that make that description wrong.

Show answer
The FDE-DE owns delivery of a customer outcome, not only the pipelines, and treats the relationship as a deliverable. The role also consumes model output and shapes it for the customer; improving the model belongs to the platform team. A pre-sales engineer, by contrast, hands off after the sale, and an implementation consultant configures a product instead of writing code. See FDE-DE vs adjacent roles.
On Thursday, extraction quality on rotated PDFs falls below the SLA. Which parts of the response are yours, and which belong to platform engineering?

Show answer
You triage, set up a temporary human review flow so the customer stays above the line, and file the bug with evidence. The layout fix itself is platform work. You contain the damage and keep the customer informed while platform repairs the cause. See what a week actually looks like.
A customer's procurement lead asks you in a call to add two more document types to the scope. What do you do, and which colleague owns the next step?

Show answer
Do not agree on the call. Scope and contract terms belong to the account executive or customer success manager, so you note the ask, size the technical effort, and route it through them. The role is technical, but scope changes carry commercial weight. See what the role is.

Takeaway

The product sells a queryable data layer with an accuracy guarantee, not a place to store contracts.
The FDE-DE joins the embedded engineer from the Palantir model with a data engineer, and owns pipelines, data model and warehouse loading at the customer.
Work cycles through discovery, build and polish, and a normal week mixes customer calls with code.
You sit between the customer's data and business teams and the platform team, and you consume model output rather than improve models.
Words such as SLA, accuracy and audit-ready mean quality is a deliverable; outcome language means you are judged on what the customer can do with the data.

Next is how to present your own background honestly against the two halves of this role. → Positioning From Scratch