FDE and its five neighbours

Six jobs touch an AI deployment between the first demo and the renewal, and from the outside they look alike: all six talk to customers, and most of them write or read code. They differ in what they own and in what they are measured on, and the measure predicts what a person does in a bad week better than any job title does. The table below is shared word for word with the PM course, which owns the wording of the PM and FDE columns; this course owns the other four.

The table

Expand

Six roles against seven rows: what each owns, its horizon, unit of work, what success is, its relationship to code, customer time and what it writes; the FDE column is shaded and its Success cell, live, in use and renewed, is the one the lesson reads first100%−+FitSVG (opens in a new tab)CloseEsc

Pinch to zoom · drag to panScroll to zoom · drag or arrow keys to pan · 0 fits · Esc closes

The PM course reads the first two columns and the argument between them about what generalises. This lesson reads the other four against the FDE.

Read it by the Success row

A measure decides what its holder does in the week it is at risk, and the six measures pull in six directions.

The sales engineer's success is quota attached: in a bad week the demo is rewritten to answer the buyer's objection, and nothing after signature counts. The solutions engineer's is deals closed and time to value. They carry the technical win through evaluation and onboarding, but the code is a proof of concept built to close and then thrown away, and the Customer time cell ends in "then hands over".

The consultant's is the deliverable accepted and hours billed. Under a statement of work a new request is a change order with more hours on it, which is the correct response for that column and the wrong one for the FDE's. The product engineer's is shipped and used, across customers they meet "little; through the PM". The PM's is an outcome metric moving across customers, which no single deployment can prove.

The FDE's cell is the only one that depends on one named customer doing two things after the engineer's work is done: using it, and then renewing. The sales engineer's and the consultant's measures complete on a date the role controls, the signature or the acceptance; the PM's and the product engineer's are spread across many customers. That one dependency explains the rest of the FDE column. The Owns cell ends in "customer evals" because "using it" has to be measured on the customer's own cases to mean anything, and the Writes cell includes a runbook because "using it" has to survive the engineer leaving; the week in the role spends a full day on the eval for this reason.

One request, six correct answers

Wednesday, week 7 of the 8-week claims-triage pilot at the regional insurer: 1,200 claims a working day, 28 handlers, a definition of done that needs the median triage time down from 11 minutes to 7.7. Since Tuesday the in-screen clause panel has been live in assisted mode for motor and property on two of the four teams. The VP of Claims asks for one more thing: when a handler opens the policy PDF, highlight the governing clause inside it. Each column has its own correct answer:

• Sales engineer. Before signature this was an objection, and the answer was a demo of a highlighted clause in the ten minutes the buyer gave. After signature it is not in the column.
• Solutions engineer. Two days of proof of concept on twenty claims shows it can be done, and the onboarding plan records it; the code is thrown away.
• Consultant. A change request: scoped in days against the statement of work, priced, approved, billed.
• Product engineer. Nothing yet. If the PM puts it on the roadmap it becomes a feature for every customer, a merged change over a few sprints.
• PM. A row on the prioritisation sheet with reach, impact, confidence and effort, which one customer's ask rarely tops.
• FDE. Whether it moves the number.

The FDE's answer is arithmetic. Assume handlers still open the PDF on one claim in five now that the panel shows the clause, and highlighting saves 20 seconds of scanning on each. That is 0.2 × 20 s = 4 seconds per claim, about 1,600 seconds a day on the 400 claims the two teams handle. The definition of done needs 11 − 7.7 = 3.3 minutes, 198 seconds, off the median. The highlight is worth about 2% of the gap, and building it costs an estimated 4 of the 8 working days left. So the answer is "not yet", with the date it will be revisited and the evidence that would change it: if the panel's retrieval hit rate falls below 90%, handlers open the PDF more often, the one-in-five becomes one-in-two, and the highlight is worth 2.5 times as much. The request goes in the week's field note, which is how it reaches the PM.

The same request produced six right answers because each column is right about its own measure. The mistake is answering from the wrong column: an FDE who quotes it as a change order is acting as a consultant, and one who builds it because the VP asked is acting as a sales engineer after the signature.

Where the columns blur

Three neighbours share enough of the FDE's week to be confused with it, and one cell resolves each confusion.

Solutions engineer: the Code cell. Both build something on the customer's data early. A proof of concept that closes is finished when the deal is; a system running in the customer's environment is finished when the customer's own on-call can run it. The test, for a job ad or for your own week, is what happens to the code after onboarding.

Consultant: the signature line. Both work on site against a scoped document. The scoping doc looks like a statement of work, and the difference is what is signed: a statement of work is signed against a deliverable, a scoping doc against a definition of done with a number in each line. A consultant who delivers every item with the number unmoved has succeeded. An FDE in the same position has not.

Product engineer: the repo. Both write production code. The FDE's runs in one customer's environment and is written for that customer; the product engineer's is merged into the product for all of them. The bridge is the field note, and over several deployments the field notes are why the work at each new customer shrinks.

A title is the least reliable cell on the page. Two companies can advertise the same work under two of these names, so read the job against the rows instead.

In an interview

"How is this different from a solutions engineer?" and "why this and not product engineering?" come up in the hiring-manager conversation and again in the behavioural round. What is being tested is whether you know what you will be measured on and have chosen it. Answer with the row, not an adjective: "a solutions engineer is measured on deals closed and hands over after onboarding; I want to be measured on whether one customer is live, using it and renewing, which is why I own their eval and write the runbook." In the role, the customer notices which column you are working from by how you answer a week-7 request: with a price, with a demo, or with the number.

The mistake that loses points is describing the FDE as a more technical solutions engineer, or as a consultant the vendor employs. Both answers move the finish line to the signature or to the deliverable, and the interviewer hears a candidate who will leave the customer before it is live.

Check yourself

1. Two job ads describe the same work, one titled solutions engineer and one forward-deployed engineer. You get one question to each hiring manager. What do you ask, and which answer means the FDE column?

"At six months, what is this person measured on, and what happens to the code they wrote after the customer signs?" Deals closed and a proof of concept handed to someone else at onboarding is the solutions engineer column, whatever the title says. A named customer live and renewing, with the code running in their environment until a handover the engineer writes, is the FDE column. Two of seven rows decide it: Success and Code.

2. Week 8. The insurer's procurement lead asks you to quote the clause-highlighting request as a change order, in days and price, so it can be approved. Do you quote it?

No. A quote turns an outcome into a deliverable, which is the consultant's column. Answer with the definition of done: the highlight is worth about 4 seconds a claim against 198 needed, so it is "not yet", dated, in the field note. If the arithmetic said it moved the median by a minute, you would build it inside the pilot without a quote, because the pilot fee pays for the outcome. Any commercial question goes to the account team, not to you.

3. A product engineer with five years of experience asks which two rows change most if they move to the FDE column, and what to practise first. Decide.

Customer time and Success. Customer time goes from "little; through the PM" to embedded, days at a time, so practise discovery: an on-site interview that leaves with three statements a reviewer can mark true or false. Success goes from shipped and used to live, used and renewed, so practise building an eval from the customer's cases before the integration exists. The Code row changes least, which is why it is the wrong place to spend the preparation time.