# Why, what, how: split an FDE engagement into three questions before writing code

> Databricks ties each FDE engagement to OKRs shared with the customer before anything gets built. A one-page brief split into three layers lets you pin down the "what" the same way.

Bản gốc: https://fdetimes.net/en/guides/fde-engagement-why-what-how/

Monday morning, customer kickoff. The vice-president of operations opens with a familiar line: "We need an AI agent to answer our customers." You are the FDE in the room, and your first instinct is probably to work out which model to use, where the data will come from and what infrastructure to deploy on.

That instinct points the right way but arrives too early. The customer's sentence is only one answer to the "how" question, and nobody in the room has yet answered the two questions that come before it: why anything needs to change, and what kind of change would count as success.

The skill to build here is splitting every engagement into three questions: why, what and how. You need to know which one you answer, which ones you answer with other people, and you should not write the first line of code while the first two are still blank.

## How do the three questions differ?

"Why" is the business reason: what the customer is losing, or what opportunity it is missing. "What" is the measurable result, the number both sides agree to use when judging the project. "How" is the system you build: pipelines, models, agents, integrations, and how it all runs after go-live.

The three layers need to be kept apart because each fails in its own way. Get the "why" wrong and you polish something nobody needs. Get the "what" wrong and the project never ends, because nobody knows what done looks like. Get the "how" wrong and at least you can see the errors in the logs.

Why/what/how is not any company's official terminology, just a way of dividing the work so it is easier to think about. Even so, the way Databricks describes the Forward Deployed Engineering organisation it launched in June 2026 shows this logic quite clearly.

## Databricks locks the "what" with OKRs

In its launch post, Databricks says customer requests have shifted from pipelines and migrations to business problems. The stated mission is to accelerate business outcomes for customers with AI.

Pulse 2.0 describes the same trend: customers are moving away from build-and-hand-over consulting towards engineering teams that work inside their organisations and are accountable for measurable results. That is the "why" of the whole model.

The "what" is spelled out directly: engagements are anchored to the customer's business outcomes through shared OKRs. Before that, Databricks' professional services arm had already replaced rigid SOWs with OKR-based work and continuous collaboration with customers.

Jason Martin, the VP in charge of FDE at Databricks, told an Insight Partners event that this work cannot revolve around hours and headcount; it has to revolve around outcomes.

The "how" belongs to the FDE. According to Databricks, the FDE's job is to take the platform in its raw form and turn it into a business solution running for real in the customer's environment. When the platform cannot yet do what the customer needs, FDEs work directly with R&D to extend it.

So who answers the "why" and the "what"? Not the FDE alone. Insight Partners' write-up of the event describes pre-sales and post-sales at Databricks as now merged into a single workstream. The company's job posting for a Manager, FDE asks the hire to work with Account Executives, Engagement Managers and Field Engineering leadership to position and deliver programmes.

Partners add breadth of expertise, but Databricks does not say they own the "why" or the "what".

**Điểm mấu chốt:** The FDE does not necessarily own the "why" and the "what", but must be able to read them, and must refuse to build the "how" while those two layers are still empty.

## Example: "we need a chatbot"

Go back to the kickoff, this time set at a hypothetical consumer-electronics retailer in Vietnam. You do not push back on the agent idea. You ask your way upward.

"What is causing you the biggest headache in customer service right now?" Suppose the answer is that the call centre is overwhelmed every promotion season, and customers wait so long they abandon their orders. That is the "why". The next question: "If this project has succeeded six months from now, which number on the dashboard will you look at?" The answer becomes the "what".

After the meeting, you write a one-page brief like this and send it to both the customer and the Account Executive:

| Layer | Content (hypothetical) | Who confirms |
|---|---|---|
| Why | The call centre is overwhelmed during promotions; customers abandon orders because of the wait | VP of operations |
| What (Objective) | Customers get fast answers without adding call-centre staff | Customer + AE/Engagement Manager |
| What (Key Results) | Median wait time falls by X%; Y% of order questions are resolved automatically; the rate of customers escalating to a human does not rise | Signed by both sides |
| How | An agent that reads the order system, hands off to a human when unsure, with an eval set built from call-centre logs | FDE |

Note three things. The figures X and Y are deliberately left blank, because the customer has to fill them in, not you. The "How" row mentions an eval set, because a Key Result only means something if you can measure it. And once the "what" is written, the "how" may no longer be a chatbot.

The most effective approach might turn out to be sending automatic order-status messages.

## Doing it yourself in five steps

Step one: write down the customer's request verbatim and label it. It is almost always a "how". Step two: ask your way up to the "why" with questions about pain and the cost of keeping things as they are, not about technology.

Step three: turn the "why" into one Objective with two or three Key Results that have measures and deadlines. Step four: decide who signs off on each layer. If your organisation has AEs or Engagement Managers, bring them in now rather than waiting for a dispute.

Step five: start designing the "how" only once the "what" has been signed. While building, if you find the platform lacks a capability you need, log it as a request to the product team. Do not quietly patch around it.

## Common mistakes

The most common mistake is writing the "what" as an output: "deploy the agent", "complete the migration". That is work you do, not a result the customer receives. A simple test: if the project can be "done" while the customer is no better off, you have written an output.

The second mistake is leaving the "why" in one person's head, usually whoever sold the contract. When that person moves on, the team no longer knows what it is optimising for. The third is treating collaboration with the sales team as someone else's job.

As the CTO of Consumer & Community Banking at JPMorgan Chase put it, they do not need more consultants; they need engineers who can build things that do not yet exist. But to build the right thing, engineers still have to understand why people need it.

## Does your CV speak to the "what"?

For a developer looking to move into an FDE role, this skill shows most clearly in the CV and in interviews. When reading a job description, look for phrases such as "business outcomes", "OKR" and "partner with Account Executives". They signal that the company expects you to hold a conversation at all three layers.

Every project on your CV should have an "in order to achieve..." clause following the "built..." clause. In interviews, when asked about a past project, tell it in the order why, what, how, rather than opening with the tech stack.

This week's exercise: take the biggest ticket you are working on and try writing three lines for it: why, what and how. If the "what" line takes more than ten minutes and still has no number in it, your next move is to go and ask whoever assigned the ticket, not to write code.

**Thử ngay tuần này:**

- Take the project you are working on and rewrite it on one page across the three layers of why/what/how, then mark which boxes you are guessing at rather than having had confirmed by the customer.
- Rewrite the 'what' as one Objective with two or three measurable Key Results, then send it to your customer contact or PM and ask whether they agree to judge the project by them.
- Change one CV bullet from 'built pipeline X' to 'built pipeline X to achieve result Y'. If you cannot name Y, that is a sign you have not yet grasped the 'what'.

## Nguồn

- [Databricks Launches Forward Deployed Engineering Organization To Accelerate AI Outcomes](https://pulse2.com/databricks-launches-forward-deployed-engineering-organization-to-accelerate-ai-outcomes/)

- [Forward Deployed Engineering: Delivering Business Outcomes with AI](https://www.databricks.com/blog/forward-deployed-engineering-delivering-business-outcomes-ai)

- [Demystifying the forward deployed engineer](https://www.insightpartners.com/ideas/demystifying-forward-deployed-engineers/)

- [Manager, Forward Deployed Engineering - Databricks](https://www.databricks.com/company/careers/professional-services-operations/manager-forward-deployed-engineering-8445817002)

- [Agile and Flexible Services Deployment with OKR Centric Delivery](https://www.databricks.com/blog/agile-and-flexible-services-deployment-okr-centric-delivery)