Forward Deployed Engineering: Start Here

#A Day at the Customer

Imagine a tailor who sells ready-made shirts. A shop owner says: "Your shirts do not fit my customers." A normal salesperson would offer a different size chart. A tailor who comes and stands in the shop for a week sees something else: the owner's customers are mostly short and broad, and none of the sizes were ever made for them. The fix is not a chart. It is a new pattern, cut and tried in that shop, on those customers.

A typical day mixes four kinds of work.

• Listening. Sitting with the people who do the job today, and watching what they really do.
• Measuring. Counting how long things take and how often they go wrong, so that "better" can be checked later.
• Building. Writing and wiring the actual software, often small and quick at first.
• Reporting. Telling the customer, plainly and often, what works, what does not, and what happens next.

None of these is a job title on its own. The FDE does all four, and stays responsible for the result.

A word about names. Companies use different titles for this kind of work, such as forward deployed engineer, forward deployed AI engineer or solutions engineer, and the same title can mean different things at different companies. The mix of jobs changes over time. As of October 2026, verify with the current job posting, because the posting is the only honest definition of that company's role.

In one sentence: a forward deployed engineer goes to the customer, works inside their world, and builds and owns the working fix there.

#One Customer Problem, Traced by Hand

Now a made-up customer, so that we can count. All the numbers in this section are invented for the exercise. They are not real figures about any company.

Thirty of 50 is 60 percent. So "where is my order" is the biggest single group in this sample. The FDE also watches one support agent for an hour. To answer an order question, the agent opens three different systems, copies an order number between them, and types a reply. This takes about 6 minutes each time. The real problem is not "we have no AI". It is "an agent spends 6 minutes copying between three systems to answer the same question".

The first run gets 41 of 50 right. That is 41 / 50 = 82 percent. Below the target of 90. Reading the 9 wrong ones, the FDE finds 5 had the order number only inside a photo, and 4 were orders shipped in two parts, where the draft talked about only one part. The FDE adds a rule for split shipments and runs the same 50 again: 45 of 50 are right. That is 45 / 50 = 90 percent. It meets the target. The photo cases remain, and the FDE writes them down as a known limit: those go to a person.

The FDE does not announce the 16 hours as a promise. It is a sum made from the pilot numbers, so the next job is to check it against real days, not just trust it.

Do: Follow the boxes left to right and say, for each one, what Harbor Parts actually did. Then find the number each box produced: 30 of 50, order emails, 6 minutes, 90 percent, 960 minutes.

Notice: The stated ask is the first box and not the last. Two boxes (baseline and build and test) create the numbers that the last box is judged by, and the target was fixed before the test, not after.

Why: A fix chosen from the ask alone would be a guess. Each step replaces a guess with something counted, so the customer can see for themselves whether the work helped.

In one sentence: you trace a customer problem by looking at real cases, choosing one workflow, measuring today, testing on past cases against a target set in advance, and running a small pilot.

#What an FDE Owns, and What They Do Not

Look back at the trace and ask: who was responsible for each part?

Two ideas come out of the table.

First, the FDE owns the outcome, not just the code. If agents do not use the tool, the FDE has not finished, even though the software works. This is what separates the role from a consultant, who writes a report, or a sales engineer, who shows a demo.

Second, the FDE does not own everything. The shipping system belongs to the customer's IT team. The FDE needs their permission and help to read it, and has to ask early. In real engagements, waiting for access is one of the most common causes of lost time. Asking for it in week one, in writing, is a skill of its own.

There are also things you learn that belong to your own company, not the customer. In the trace, 5 of the 9 first mistakes were order numbers inside photos. If many customers send photos, the product should read them. A good FDE writes that down and tells their own product team. This is called feeding the product, and it is how one customer's problem makes the product better for everyone.

Here is how the steps you traced map onto the rest of this track.

In one sentence: the FDE owns the outcome for the customer, depends on the customer's own teams for access, and carries what they learn back to their own product.

#Where to Go Next

You can now describe what an FDE does on an ordinary day and trace a customer problem from a vague ask to a measured pilot.

• Next: The Engineer Who Ships Where the Customer Lives goes deeper on where the role came from and how it differs from a consultant, a sales engineer and a solutions architect.
• Then: The Engagement Lifecycle shows the five phases of a full engagement and what can go wrong in each.
• Tests like the one you traced: Evaluation at Scale in the ML engineering track takes the idea of a fixed list of test cases much further.
• Code first: if you want to build the tool in the trace, begin with Python Setup.

This track has levels. This is the start, Level 0. After it come the role and the lifecycle, then discovery and scoping, then building and data, then deployment and the pilot, then feeding the product and becoming one.

In one sentence: read the role lesson next, then follow the engagement in order.

#Key Takeaways

• A forward deployed engineer goes to the customer, works inside their world, and builds and owns working software there
• The stated ask is a starting point, so look at real cases before choosing what to build
• Pick one workflow, measure a baseline, and agree a target before testing
• Test on a fixed list of past cases, read the wrong ones, fix, and run the same list again
• Own the outcome, not just the code, and carry what you learn back to your own product

#Quick Check