Forward deployed engineering, Part 10: Talking to executives and proving the outcome

In Part 9 we made the Acme Consumer Brands router faster and gave its cost a number and an owner. The agents work, the tests pass, and planners use the system every week. From an engineer’s point of view, the job looks done.

It is not done until one more conversation goes well. Acme’s chief operating officer (COO) is the executive sponsor of the engagement: the senior person who asked for it, funds it and can unblock it. At the final steering meeting, the COO will not ask about agents, tokens or mTLS. The question will be simpler and harder: “Was this worth it, and what happens now?”

This part is about answering that question with evidence. It covers the difference between outputs and outcomes, how to describe a technical problem in business terms, how to set a baseline and outcome metrics before the build, what a steering update contains, how to manage scope, and how to close an engagement properly. It ends with a recap of the whole series.

If you prefer to watch first, here is the heart of this part as a short animated explainer.

Video: how a forward deployed engineer proves an engagement was worth it to executives, in three minutes. The narration is a synthetic voice; the script and animation are mine.

Where does this show up in an FDE job description?

This is the part of the job that public postings describe in the most detail. Four examples, as of 20 October 2026:

Microsoft’s Principal Forward Deployed Engineer posting asks the engineer to “establish the problem statement, the baseline, the agreed success measures and the plan”, and then to “Validate: prove the outcome with measurement the customer agrees with, not with a demo.”
The same posting says “Deliver unwelcome answers well”, and asks for clear communication of “findings, tradeoffs, risks and progress” to audiences that include executives.
OpenAI’s Forward Deployed Engineer posting (London) says success is measured “through production adoption, measurable workflow impact, and eval-driven feedback”, and asks the engineer to “make trade-offs between scope, speed, and quality; adjust plans to protect delivery.”
Google Cloud’s Forward Deployed Engineer, Gen AI posting describes production-grade agentic workflows “that drive measurable Return on Investment (ROI).”

Notice the words they share: baseline, measurable, agreed, outcome. None of them says demo.

What do I need to know first?

Here are the terms this part uses, each with a plain explanation:

Stakeholder: anyone affected by the engagement or able to affect it. At Acme that includes the COO, the heads of marketing and supply, the data platform team, security and the planners.
Output: something the team produced, such as a deployed agent or a passing test suite.
Outcome: a change in how the business works because of that output, such as planners getting an answer in minutes instead of days.
Baseline: the value of a measure before the change. Without it, nobody can say what improved.
Leading and lagging indicators: a leading indicator moves early and predicts success (weekly active users). A lagging indicator moves later and confirms it (fewer stockouts).
ROI (return on investment): the value an investment produced, compared with what it cost.
Steering group: the small group of senior stakeholders who meet regularly to review progress and make decisions the working team cannot make alone.
RAG status: a red, amber or green rating for how a workstream is going. In project reports, RAG means this traffic-light rating, not retrieval-augmented generation from Part 4.
RAID log: a running list of Risks, Assumptions, Issues and Dependencies, each with an owner.
Close-out review: the formal end of an engagement, where both sides compare the outcome with the baseline, confirm the handover and agree what happens next.

What do executives actually want to know?

An executive sponsor has many projects and little time. In my experience, every update to them is really answering three questions: Is it working? Is it worth it? What do you need from me? Engineers tend to answer a different question, what did we do?, because that is what fills their week.

The difference is between activity, output, outcome and impact:

activity, output, outcome and impact: workshops and tests are activity and output; executives care about the outcome (planners answer cross-team questions in minutes) and the impact (fewer stockouts and less wasted campaign spend)

Workshops held and tickets closed are activity. A deployed router with 149 passing tests is an output, and the working team should hear about it. The sponsor cares about the next two steps: the outcome (a planner can answer a cross-team question in minutes) and the impact (stockouts spotted earlier, less campaign money spent promoting products that are not on the shelf). Report upwards from the outcome, and keep the outputs ready for the follow-up question.

How do I turn a technical blocker into business impact?

Every engagement hits blockers, and some of them are deeply technical. In Part 8, the router’s calls to the specialist agents failed with a 401, because Agent Identity tokens are bound to a client certificate and our first client did not present one. That sentence is accurate, and it means nothing to a COO.

I translate every blocker in four steps, from the technical fact to the decision:

translating a technical blocker for an executive: start from the technical fact, say what users cannot do, say what that means for the business, and end with the decision or help you need, or say that none is needed

Technical fact. What is wrong, in one sentence. Keep it for the follow-up.
User impact. What people cannot do. “Supply questions come back as ‘no data’, so planners cannot use the pilot.”
Business impact. What that means for the reason the engagement exists. “We cannot yet answer what the stockouts cost the campaign. The pilot slips by a week.”
Decision or ask. What you need from them, or a clear statement that you need nothing. “No decision needed: the fix is tested and ships on Thursday.”

The fourth step is the one engineers most often leave out. An executive who hears about a problem with no ask assumes either that you need help and are not saying so, or that you are reporting something they cannot influence. Both waste their attention. If the answer is “nothing needed”, say so.

This is also how to deliver unwelcome answers well, the phrase from the Microsoft posting. Bad news delivered early, with its impact and a plan, builds trust. The same news discovered by the sponsor a week later destroys it.

How do I set a baseline and outcome metrics?

The time to agree how success will be measured is at the start, in the discovery brief from Part 2, and the time to measure the baseline is before the build changes anything. Once the new system is live, nobody remembers how long the old way really took.

For Acme, the engagement brief named four outcome metrics. For each one, we wrote down the baseline, the target and how it would be measured:

a baseline, a target and a measurement for each outcome metric, agreed before the build: time to a cross-team answer, share of answers correct, weekly active planners and cost per resolved question; all values illustrative

Time to a cross-team answer. Before the engagement, a question such as “what did last month’s stockouts cost the campaign?” meant an analyst exporting data from BigQuery and Databricks and reconciling them by hand. Time a sample of real requests before the build, and the same kind of questions after it.
Answers correct. This comes straight from the held-out eval set and gate in Part 10 of the agents series. The executive version is one number with a plain definition: “9 out of 10 answers matched what an analyst would have reported.” The engineering version is one line per metric from the gate, as in this illustrative run from the agents series:
```
route_correct           1.000 (min 1.0) ok
grounded                0.500 (min 1.0) FAIL
golden_numbers          0.900 (min 0.9) ok
GATE FAILED: ['grounded']
```
Weekly active planners. A leading indicator of adoption, from usage logs. A system nobody uses has no outcome, however accurate it is.
Cost per resolved question. From the cost report in Part 11 of the agents series, set against the cost of the old way.

This is what that cost report looks like for one illustrative question:

the cost report for one illustrative question: the writer on Pro costs most, thinking is a large share, and the total of USD 0.0537 becomes the cost per resolved question when every question is resolved

Part 11 of the agents series builds the report and explains each column.

All of these values are illustrative. Use the customer’s own numbers, and agree the definitions in writing. “Correct” and “active” mean different things to different people until someone writes them down.

An ROI estimate follows from the same numbers. A simple version is: value = hours saved per question × questions per month × the cost of an hour, compared with what the system costs to run. For example, if each cross-team question used to take an analyst four hours and the system answers 200 a month, that is 800 analyst hours a month to compare with the running cost. Those numbers are made up, and that is the point: present the formula and its inputs, and let the customer’s finance team supply the real values. An executive trusts a number they can check far more than a large number they cannot.

How do the technical numbers connect to the business ones?

Executives see the outcome measures. Engineers see latency, eval scores and error counts. A metric tree connects the two, so that when an outcome measure moves, you can explain why:

a metric tree: one business outcome at the top, three outcome measures under it (adoption, speed and trust), and under each the technical measures from earlier parts that explain why the outcome measure moved

At the top is the business outcome the engagement exists for. Under it are the three outcome measures: adoption, speed and trust. Under each one are the technical measures from earlier parts: time to first token and p95 latency from Part 9, the error and 401 counts from Part 8, and the eval pass rate from the agents series. If weekly active planners fall, the tree tells you where to look first: did answers get slower, or did they get less accurate?

What goes into a steering update?

An engagement usually runs on three rhythms. The working team talks every day and meets every week. A steering group meets every two weeks. The executive sponsor hears from you monthly, or straight away if something needs their decision:

the steering cadence: the working team meets every week, the steering group every two weeks and the executive sponsor monthly or by exception; status, risks and decisions needed travel up, and decisions, priorities and unblocking travel down

Status, risks and decisions needed travel up. Decisions, priorities and help clearing blockers travel down. Each level should hear only what it can act on.

The steering update itself should fit on one page. This is the template I use:

ACME AGENTS ENGAGEMENT: STEERING UPDATE, <date>

OVERALL        GREEN | AMBER | RED, and one sentence on why.

OUTCOMES       Metric           Baseline   Target    Now
               Time to answer   2 days     < 1 hour  ...
               Answers correct  n/a        90%       ...
               Active planners  0          30        ...

SINCE LAST     Two or three outcomes reached (not tasks done).

BLOCKERS       Each one as: impact, then plan, then owner and date.

DECISIONS      What we need from this group, with a deadline,
NEEDED         or "None this time."

RISKS          Top three from the RAID log, each with an owner.

NEXT           What the group should expect by the next meeting.

Three rules make it work. Lead with the overall status and the decisions, because some readers will stop after four lines. Use the same metrics every time, so that progress is visible. And never let the status jump from green to red. If something was at risk, it should have been amber in the previous update.

How do I manage scope and expectations?

Once the first agent works, requests arrive from every direction. Some are good ideas. Most of them, if accepted, would push back the date and weaken the outcome everyone agreed on. Scope creep is the slow growth of a project through small additions that nobody decided on as a whole.

I put every new request through the same two questions:

triaging a new request: if it does not move the agreed outcome, park it and say when you will look again; if it does but does not fit the time and risk budget, put it in the next phase; only if it does both, do it now and record the change

Does it move the agreed outcome? If not, park it. Write it down, thank the person and say when you will look at it again, usually at the close-out review.
Does it fit the time and risk budget? If it does, do it and record it as a change, so the steering group can see what was added. If it does not, put it in the next phase and write it in the follow-on brief.

For Acme, a request to forecast demand was a good idea for a different outcome, so it was parked. A request to let the agent run the supply replan without a planner approving it served the right outcome but carried real risk; the agents series deliberately put a human approval step in front of that action in Part 9. It went into the next phase, to revisit once the pilot had built trust.

Managing expectations about the model matters as much as managing scope. Say clearly, early and in writing what the system will not do. For Acme: it answers questions from the two data sources, it does not invent figures (the writer’s numbers are checked in code), and it will sometimes decline a question it cannot answer safely. An executive who was told that in week two is not surprised by it in week ten.

How do I close an engagement?

An engagement should end with a document, not with a last meeting that fades out. The close-out review covers five things:

the close-out review covers five things: outcomes against the baseline, what was handed over and to whom, open risks with owners, product feedback filed and its status, and lessons for the next engagement

Outcomes. Each metric against its baseline and target, with the definitions used.
Handover. The code, the runbook from Part 7, the named owners on the customer’s side, and the training done. The published router and its staged rollout are described in Part 12 of the agents series.
Open risks. Each one with an owner and a date.
Product feedback. Every report filed during the engagement (Part 8) and its status. This is the “feedback loop” all three postings describe, made visible to the customer.
Lessons. What to repeat and what to change next time, on both sides.

Ask the executive sponsor and the customer’s technical owner to sign it off. That signature is what turns a working system into an agreed outcome, and it is the reference point if anyone asks a year later what the engagement achieved.

Try it: translate three blockers

You do not need any tools for this exercise. Rewrite each technical statement below as the four boxes from the translation diagram: technical fact, user impact, business impact, and decision or ask.

“The security team has not approved the egress rule for the Databricks workspace yet.”
“The held-out eval pass rate dropped from 92 to 81 per cent after the model upgrade, so the gate blocked the release.”
“p95 latency is 19 seconds because the writer’s thinking level is set to high.”

Then write a one-page steering update, using the template above, for a week in which the second statement happened. Decide whether the overall status is green, amber or red, and write the one sentence that explains it. (My answer: amber, because the gate did its job, the old version is still live, and the only decision needed is whether to wait for a fix or keep the previous model.)

What can go wrong

No baseline. Without a “before” number, every outcome is an opinion.
Reporting outputs as outcomes. “We deployed three agents” is not an answer to “was it worth it?”.
A blocker with no ask. The sponsor cannot help with a problem you only described.
Green, green, green, red. Problems that appear without warning cost more trust than the problems themselves.
Metrics nobody agreed. If “correct” was never defined, the customer can reasonably say the target was not met.
Saying yes to every request. The date moves, and the outcome everyone agreed on gets weaker.
An engagement that fades out. With no close-out review, nobody owns the open risks, and the product feedback is lost.

What I would do now

Write down, today, the outcome your current engagement exists for, in one sentence an executive would recognise.
Agree three or four outcome metrics with the customer, and measure each baseline before you build anything else.
Rewrite your latest status update so it starts with the overall status and the decisions needed.
Start a RAID log, and give every entry an owner.
Book the close-out review now, so the end date is real.

What did we learn?

Executives want to know whether it is working, whether it is worth it and what you need from them, so report from the outcome upwards and keep the outputs ready for follow-up questions.
Translate a technical blocker in four steps: the technical fact, what users cannot do, what that means for the business, and the decision or help you need, or that none is needed.
Agree outcome metrics and measure their baselines before the build, because without a before number every outcome is an opinion.
A metric tree links the business outcome to adoption, speed and trust, and each of those to the technical measures that explain why it moved.
A one-page steering update leads with the overall status and the decisions needed, uses the same metrics every time and never jumps from green to red.
Every new request goes through two questions, whether it moves the agreed outcome and whether it fits the time and risk budget, and the engagement ends with a signed close-out review.

What comes next?

This is the last part of the series. Over ten parts, we followed one forward deployed engineer through one engagement with Acme Consumer Brands, from the first conversation to the close-out review. The companion series, Production-ready agents, is the build that sits inside it:

the whole series on one engagement: embed (Part 1), discover (Part 2), design inside the estate with data and integrations (Parts 3 to 5), build (Parts 6 and 7), run (Parts 8 and 9) and prove the outcome (Part 10); the production-ready agents series is the build inside the middle stages

Forward deployed engineering, from the basics: the overview, the running example and how the two series fit together.
Part 1: What a forward deployed engineer actually does: where the role came from, how it differs from neighbouring roles, and how an engagement runs.
Part 2: Discovery, from a business problem to something you can build: problem statements, success metrics, choosing the first use case and the one-page brief.
Part 3: Designing inside someone else’s estate: data location, identity, network paths, compliance and the week-one questions.
Part 4: Data readiness and RAG from zero: from documents to grounded, cited answers, and why answers go wrong.
Part 5: Enterprise integrations, APIs, connectors and identity: connecting to the systems a company already runs.
Part 6: Agent frameworks compared: ADK, LangGraph, CrewAI and AutoGen, the common patterns, and how to choose.
Part 7: Prototype in days, production in weeks: the throwaway prototype, the hardening checklist and the handover.
Part 8: Debugging in the field: reproducing, isolating and reporting problems in an estate you do not control.
Part 9: LLM-native performance, latency, tokens and cost: measuring and improving what users wait for and what the business pays.
Part 10: Talking to executives and proving the outcome: this part.

If you want the build itself, start with the Production-ready agents series, and for a real integration worked end to end, read Let people ask your lakehouse questions.

My view, after many engagements with partners: the technical work is what gets a forward deployed engineer into the room, and the outcome, measured against a baseline the customer agreed, is what gets them invited back.

Sources

Built In: Principal Forward Deployed Engineer, Microsoft (public copy of the posting; the listing closed on 6 October 2026)
OpenAI: Forward Deployed Engineer, London (public posting, checked 20 October 2026)
Google Careers: Forward Deployed Engineer, Gen AI, Google Cloud (public posting, checked 20 October 2026)
Google re:Work: Set goals with OKRs (goals with measurable key results)
Google SRE book: Service level objectives (defining a measure before setting a target)
Google SRE book: Postmortem culture (blameless written reviews)

Opinions are my own. Every fact in this post comes from the public documentation linked above. Acme Consumer Brands and its data are fictional, and all metrics, dates and values in the examples are illustrative.