May 2026 · 5 min read · Part 2 · The New Org Model
The Engineer in the Room
Central AI teams produce proof-of-concepts that never deploy. Business teams submit requests that sit in backlogs for quarters. The problem is not capability. It is distance. Here is the structural fix.
Every enterprise has the same problem with AI: the people who can build it are too far from the people who need it. Central AI teams produce proof-of-concepts that never deploy. Business teams submit requests that sit in backlogs for quarters. The distance between capability and problem is measured in prioritization meetings, requirement documents, and months of lost time.
The Forward Deployed Engineer closes that distance.
The Center Cannot Hold
Centralized engineering teams made sense when the work was infrastructure. Build the platform, maintain the systems, serve requests from the business. The operating model was a service desk with better tooling.
AI does not work this way. AI solutions are context-dependent in a way that platform infrastructure is not. A recommendation engine for supply chain and a forecasting model for finance share almost nothing except the underlying framework. The business logic, the data inputs, the success criteria, the edge cases: all of it is domain-specific. Building it from the center means constant translation. Business stakeholder explains the problem to a product manager, product manager writes a spec, engineer builds to spec, result misses the point because three layers of translation stripped the nuance.
The failure mode is not incompetence. It is distance. The engineers are good. The problems are real. But the space between them converts every project into a game of telephone.
What a Forward Deployed Engineer Is
An FDE is a production-grade engineer who operates with direct exposure to the business problem they are solving. They sit at the top of the Engineering and IT organization, where AI capability should live, but they work forward: embedded in the context of specific business functions, building solutions with the problem holder in the room.
This positioning is deliberate. The FDE maintains technical authority because they report into Engineering. They are not staff augmentation absorbed into a business unit. They are not consultants passing through. They are engineers with a permanent mandate to deploy capability where it creates value.
What they build is production software. Not prototypes, not dashboards, not “let me show you what’s possible” demos that die after the meeting. Deployed, maintained, iterated-on systems that solve real operational problems.
What It Is Not
The FDE is not a solutions architect drawing diagrams. Not a business analyst who learned Python. Not a data scientist running experiments in notebooks. These are all valuable roles, but they are not this.
The distinction is in what ships. A solutions architect designs a system someone else builds. A business analyst defines requirements someone else implements. An FDE does both: scopes the problem through direct business exposure, then builds and deploys the solution. The feedback loop is one person, not a chain of handoffs between roles.
This is also not a rotation program where engineers spend six months “learning the business” before returning to the center. The FDE role is permanent. The deployment is the job, not a temporary assignment.
Why AI Lives Here
AI capability belongs where the FDE sits: at the intersection of engineering depth and business context. This is not an ideological position. It is a practical observation about what makes AI projects succeed or fail.
Central AI teams build horizontally. They optimize for reusability, shared platforms, common frameworks. This makes sense for infrastructure. It fails for AI because the value of an AI solution is almost entirely in its specificity. A generic forecasting model is worth less than a forecasting model tuned to your supply chain’s specific demand patterns, supplier constraints, and seasonal behaviors.
The FDE builds vertically. Deep into one problem, one domain, one set of business constraints. They consume the data products that DPEs build (the semantic models, the curated datasets, the well-defined metrics) and turn them into deployed intelligence. The data product is the input. The FDE’s output is a system that acts on it.
The Operating Model
FDEs need structure to stay effective. Without it, they become captive to the business unit they serve, losing technical edge and turning into specialized application developers.
The model that works: FDEs report into a central engineering leader but are deployed against specific business domains. They participate in engineering practices (code review, architecture discussions, technical community) while spending the majority of their time embedded in business context. They have dual accountability: technical quality to engineering leadership, business impact to the domain they serve.
You keep them sharp by keeping them connected. Regular technical forums where FDEs share patterns across domains. Shared tooling and platform support from the central team. Career progression that rewards both technical sophistication and business impact, not one at the expense of the other.
The hiring profile is rare but recognizable: strong engineers who are genuinely curious about business problems. People who get bored building systems in isolation but frustrated by purely advisory roles. They want to build, and they want what they build to matter to someone specific.
The Shift
This is a structural change in how engineering organizations relate to the business. The old model was: business requests, engineering delivers. The new model is: engineering deploys forward, builds in context, iterates with the problem holder.
It requires trust from the business (these engineers are here to help, not to impose technical solutions). It requires trust from engineering leadership (these engineers are still ours, still held to our standards, even when they are physically and mentally embedded elsewhere).
The future of AI in the enterprise is not a center of excellence producing artifacts that the business struggles to adopt. It is engineers who are excellent, deployed where their excellence creates direct, measurable value.