Forward Deployed Engineering · Part 2 of 4

Part 1 asked what a Forward Deployed Engineer is. This one asks what they actually do all week.

Where We Left Off

Part 1 defined the role: an engineer who goes to where the problem is, works out what is really wrong, builds the fix, and puts it into live use.

That leaves an obvious question. If the job is not simply writing code to a specification, what fills the working day?

The short answer is that an FDE sits at the meeting point of two things: close to the customer, and close to the technology. Neither on its own is the job. This article walks through what that looks like in practice — the eight-stage cycle the work follows, a realistic day, the skills that matter, the technology stack, and a learning path if you want to get there.

The core idea A software engineer builds software. A Forward Deployed Engineer builds and deploys a solution around a real customer problem — and stays accountable for whether it worked.

The Work Follows a Cycle

Every engagement, whatever the industry, moves through roughly the same eight stages. It is worth seeing the whole shape before looking at any one part.

Figure 1 — The eight stages, and the loop that connects the end back to the beginning.

Notice that it is a loop, not a line. What happens after deployment feeds straight back into understanding the problem better. Most engineering processes stop at stage 7.

The Eight Responsibilities, One at a Time

The most common misconception about this role is that it is a software engineering job with more meetings. In practice an FDE changes hats several times a week. One day is interviewing users and mapping a workflow. The next is writing Python, wiring up an API, testing an LLM workflow, deploying a container — then presenting results to an executive.

1. Understand the real business problem

Customers describe symptoms. The FDE’s first job is to find the cause underneath. That means asking a small set of unglamorous questions before touching any technology:

● How does this process actually work today?

● Where do people lose the most time?

● Where do errors creep in?

● What data already exists, and who is allowed to see it?

● How will we know whether the solution worked?

In practice A retailer says customers are abandoning their carts. The answer may not be a new discount engine. The real cause could be a slow checkout, unexpected shipping charges, payment failures, or a confusing final step. Building the discount engine first would have solved nothing.

2. Work directly with customers

FDEs spend real hours with the people who do the work. Workshops, watching the workflow, demonstrating prototypes, collecting reactions, and translating what they hear into engineering decisions.

In practice A hospital says it wants AI to help doctors. Before deciding anything, the FDE watches how doctors search records, how nurses update information, and where the minutes actually go. Only then does the shape of the assistant become obvious.

3. Translate business language into technical design

Stakeholders do not describe problems in terms of APIs, retrieval layers or authentication. Turning an outcome into an implementable architecture is a distinct skill, and it is one of the things the role is really paid for.

In practice “We need faster customer support” translates into an assistant connected to an approved knowledge base, a retrieval layer, an LLM, the CRM APIs, authentication, analytics, and a clear path to escalate to a human.

4. Design a solution that fits — not the most impressive one

A good FDE decides where AI belongs and, just as often, where it does not. Traditional application logic, an LLM, retrieval, an agentic workflow, deterministic business rules — or some combination. The questions that settle it:

● Does this need a language model at all, or would ordinary logic be more reliable?

● Retrieval from approved documents, or direct prompting?

● Which existing systems must this connect to?

● Where must a human approve before anything happens?

● What security and compliance controls apply?

In practice For an internal policy assistant, retrieval is usually the better answer than training a new model — because every answer has to be grounded in the organisation’s own approved documents, and be traceable back to them.

5. Build a rapid prototype

A small working thing teaches more in a week than requirement discussions teach in a month. People cannot tell you what they want in the abstract, but they can react instantly to something in front of them.

In practice For a legal-document assistant, an early prototype might handle upload, summarisation, question answering and citations. What the lawyers complain about after ten minutes of use is what decides the production scope.

6. Integrate with what already exists

Real companies already run CRMs, ERPs, databases, identity platforms, ticketing systems, document stores and custom applications built over twenty years. The new solution has to live inside that, not beside it.

In practice An employee asks an HR assistant about their leave balance. Answering needs two different things at once: the policy text retrieved from documents, and the live balance fetched from the HR system.

7. Deploy and operate it

A successful demo is not the finish line. Something that works for ten users must be hardened before thousands depend on it — reliability, permissions, cost control, logging, monitoring, and sensible behaviour when things fail.

In practice A prototype serving ten pilot users has none of the problems that appear at three thousand: permission edge cases, cost per query, what happens when the model is slow, and who gets paged at 2 a.m.

8. Measure whether it worked

A system can be technically healthy and still be a failure. The FDE connects technical performance back to a business number — time saved, cost reduced, quality improved, adoption, satisfaction, revenue.

In practice If a support assistant answers correctly but customers keep calling agents because they do not trust it, the technical implementation is not a success. Accuracy was never the binding constraint.

A Day in the Life

There is no fixed schedule, because the work changes with the stage of the engagement. But a representative day shows how the role mixes conversation, design, engineering and delivery.

Figure 2 — A representative working day, colour-coded by the kind of work.

Coding matters, and it is a single block in that day. Discovery, communication, architecture, testing, deployment and feedback take up the rest — and they are not overhead around the job. They are the job.

The Skills, in Three Bands

It helps to group the skills rather than list them. There are three bands, and they are not equally common.

Figure 3 — Three bands of skill. Most engineers are strong in the first.

The Technology Stack

The stack is best understood as layers rather than a list, because each layer only works if the one beneath it is solid.

Figure 4 — The stack in layers, foundation first.

The exact tools vary by company and project, and they will change. The durable skill is not memorising a framework list — it is understanding the concepts well enough to pick an appropriate tool for the customer’s environment, including the environments that will not let you install anything new.

A Learning Roadmap

If you are working toward this role, the order matters. Adding AI on top of shaky engineering fundamentals produces demos that cannot be deployed.

Figure 5 — Four phases, in order.

The single most effective way through this is project-driven: learn a concept, apply it to a realistic business scenario, deploy it, get feedback, improve it. That loop is a small version of the actual job.

One Engagement, End to End

Suppose a company says: “Our employees waste too much time searching internal policies.” Here is how that request travels through the eight stages.

The Mindset That Ties It Together

Almost everything above follows from one habit: where you start.

Do not begin with: “Which AI framework should I use?” Begin with: “What is the customer trying to improve, and what is the simplest reliable thing that proves it can be improved?”

Part 2 in Five Lines

● An FDE is far more than a developer — the work runs from discovering the real problem to measuring whether the solution changed anything.

● The work follows a repeating eight-stage cycle, and the cycle does not end at deployment.

● Technical breadth across engineering, data, cloud and AI is the entry requirement, not the differentiator.

● Communication, curiosity, business thinking and comfort with ambiguity are what turn an engineer into a trusted customer-facing problem solver.

● The fastest way to learn it is project-driven: build, deploy, get feedback, improve — the same loop as the job itself.

Coming Next

Part 3 moves from responsibilities and skills into real-world application: healthcare, banking, manufacturing and retail use cases; the tools that recur across engagements; the business-domain knowledge that matters; and the career paths that grow out of this role.

For more in-depth technical insights and articles, feel free to explore:

Ebasiq

GirishBlogBox

  • Substack: Girish BlogBlox – Thought-provoking articles and personal reflections.

Ganitham Guru

  • Substack: Ganitham Guru – Explore the beauty of Vedic mathematics, Ancient Mathematics, Modern Mathematics and beyond.