Picture this: after an AI event, an old colleague and I end up at a bar. He has spent years moving between consulting, engineering, and delivery, and has recently noticed that everyone seems to be talking about FDE.
“So,” he says, “how many ways are there to spell FDE?”
“One,” I reply. “It only has three letters.”
“Exactly. One way to spell it. Several ways to do the job—and at least three ways to get it wrong.”
He pulls a paper napkin across the table and draws a cross in the middle.
The horizontal axis represents AI technical capability, from low to high. The vertical axis represents business operating capability, also from low to high.
Then he takes a coin from the table and places it near the center.
“That is an FDE?” I ask.
“That is where an FDE begins.”
Not in the top-right corner. Not as an all-knowing AI hero. Just somewhere in the middle: technically capable enough to build, and operationally aware enough to understand what is worth building.
“That doesn’t sound like a very high bar,” I say, a little surprised.
He takes a sip of his extra cold Guinness. “The middle is the entry point, not the destination.”
The center is only the starting point
The bar-napkin map looks roughly like this:
He taps the coin again and starts with the center.
A Forward Deployed Engineer works inside a client's operating environment. The job is to define the problem with the people who live with it, build the system, and move a capability to an operable, testable, and handoff-ready state.
Someone who can discuss the business but cannot build is missing the Engineer part. Someone who can write excellent code but never enters the client's real workflow is missing much of what Forward Deployed is meant to convey.
An FDE therefore needs both business and technical capability from the beginning. This is not a formal scoring system, and “the center” does not mean exactly 50 out of 100 on each axis. It simply means that neither side can be a critical weakness.
You need to understand a real business process. You also need to be able to turn it into a working, testable workflow.
That may sound like a modest threshold. In practice, finding people who can do both is already harder than it looks.
And again: it is only the starting point.
Four directions from the same starting point
From the center, the role can move in four directions.
“What happens next?” I ask.
He taps the coin. “That depends on which way it moves.”
Lower left: the contractor
If neither business nor technical capability keeps growing, the work can slide toward the lower-left corner.
The client specifies a task. The task gets completed. Hours are billed and tickets are closed. Whether the work solved the right problem—or left behind anything the client can operate—is someone else's concern.
There is nothing inherently wrong with contract work. Companies often need clearly scoped professional capacity. But an FDE who only follows instructions, never helps define the problem, takes no responsibility for outcomes and leaves no usable capability behind becomes difficult to distinguish from low-value staff augmentation.
The title changed. The timesheet did not.
Lower right: the programmer
This person knows the model rankings, the latest frameworks and every new tool before the rest of the team has finished reading the release notes.
But they may not know why customers return a product, why procurement requires a second review, or why the sales team quietly refuses to use the new system.
They can build an impressive demo. They may still be solving the wrong problem.
Programmers and technical specialists remain essential. But as AI takes on more routine coding and configuration work, it becomes harder to differentiate through those activities alone. Moving far to the right while never moving upward does not create an FDE. It creates a strong technical contributor who still depends on someone else to connect the work to business results.
Upper left: the business specialist
This person has years of industry experience and plenty of good ideas. The arrows in the presentation deck are particularly confident.
Then implementation begins.
Questions about data dependencies, system integration, evaluation and operating constraints are handed from one team to another. The idea may be sound, but the person who proposed it cannot test it without waiting for several other people.
Business specialists and consultants create real value. But if they cannot turn an idea into something that can be tested, their ability to move the work forward remains limited—and increasingly dependent on others.
Upper right: the operator
“This is where an FDE should be heading,” my colleague says, drawing an arrow toward the upper-right.
The person understands models, data, workflows and security boundaries. They also understand business objectives, operating processes, accountability and return on investment.
They can frame the problem, build the first working version, integrate it into an existing system, test it with real users and hand it over to the client's own team.
“So the upper-right is where the real FDE lives?” I ask.
“Careful,” he says. “Knowing a little business and a little technology is enough to remain near the center. Moving toward the upper-right requires something more: the ability to operate on both sides.”
On the business side, that means clarifying the problem, process, ownership and value. On the technical side, it means building the solution, connecting it to the operating environment and producing evidence that it works.
On the provider side, the title may be FDE
At a technology company or service provider, this person may be called a Forward Deployed Engineer. They connect the business problem, engineering work, user acceptance, and handoff into one line of delivery.
Inside the client organization, the title may be completely different: AI product lead, digital transformation lead, operations leader—or simply the business manager who took responsibility for getting the first workflow into production.
The titles differ, but the capability profile is similar. These people understand how the company operates and makes money. They can also judge where AI is useful, how it should be implemented and which risks need to be controlled.
If someone moves further into the upper-right, gains the authority to coordinate across functions, allocate resources, establish governance and own the outcome of AI transformation, you might call this role a CAITO—Chief AI Transformation Officer.
That title is not awarded for knowing a few models. It requires the capabilities in the upper-right quadrant, organizational authority, and responsibility for change.
Before placing your coin in the upper-right corner
My colleague picks up the coin and places it firmly in the upper-right corner.
“Naturally,” he says, “this is where I am.”
So I ask him two uncomfortable questions.
When did you last build and ship a working AI workflow?
When did you last sit with the people who actually use it?
He pauses, then quietly moves the coin back toward the center.
“Strategic repositioning,” he says.
Fair enough. If both answers are vague, your coin may be closer to the center than you think.
Mine too.
By then, the Guinness is nearly gone. Perhaps we all need a pint now and then to reconsider where our coin really sits.
The title matters less than the direction of travel.