May 2026 · 6 min read · Part 4 · The New Org Model
The Operating Model AI Is Building Toward
Three roles, three contracts, one coherent system: someone who owns the data layer end to end, someone who deploys capability directly into the business, and someone who governs what gets built and where. Most enterprises have none of them clearly defined.
Three roles. One builds data products from source to semantic layer. One deploys engineering capability forward into the business. One holds the map and decides where effort should land. Individually, each solves a real problem. Together, they form an operating model for how AI-era technology organizations actually deliver value.
The interesting question is not what each role does in isolation. It is what happens at the seams between them.
The Comparison
| Dimension | Data Product Engineer | Forward Deployed Engineer | Domain Product Manager |
|---|---|---|---|
| Accountability | Dataset quality, completeness, and usability from source to semantic layer | Deployed solutions that solve specific business problems | Domain technology vision and build-vs-configure decisions |
| Primary output | Data products: pipelines, models, semantic definitions, agent-ready interfaces | Production applications, AI agents, workflow systems | Roadmaps, architecture decisions, integration maps |
| Position in stack | Bottom to middle: raw data through consumption layer | Middle to top: consumes data products, builds user-facing systems | Across: sees the full stack and decides where investment goes |
| Relationship to business | Indirect. Serves consumers through well-defined data contracts | Direct. Embedded in business context, building with the problem holder | Strategic. Owns the domain’s technology direction |
| Success metric | Time to useful dataset. Consumer satisfaction with data products | Business outcomes from deployed solutions | Reduction in redundant builds. Platform utilization. Coherent ecosystem |
| Failure mode | Builds technically correct datasets nobody consumes | Builds in isolation, duplicates existing capability | Becomes a governance bottleneck that slows delivery |
The Handshake
Where these roles interact cleanly, there is a defined contract and a clear boundary.
DPE to FDE: The DPE builds a semantic model. The FDE consumes it to build an agent or application. The contract is the semantic layer: well-defined metrics, documented entities, queryable interfaces. The FDE should never need to understand how the pipeline works. They need to trust that the data product is reliable, well-defined, and current. If the DPE has done their job, the FDE treats the semantic layer like an API: call it, get answers, build on top.
PM to FDE: The PM defines what should be built and where it should live. The FDE builds it. The contract is the decision: this is a real gap, it does not exist in our platforms, it should be a custom build, here is the scope, here is how it integrates with the existing ecosystem. The FDE should never need to audit whether their project duplicates an existing platform capability. That is the PM’s job, completed before engineering begins.
PM to DPE: The PM identifies what data products the domain needs. The DPE builds them. The contract is the integration map: these systems need to talk to each other, this data needs to flow from here to there, this semantic model needs to exist so that FDEs and agents can consume it. The PM sees the full picture. The DPE executes the data layer that makes it work.
When the handshakes are clean, each role amplifies the others. The PM prevents wasted work. The DPE provides the foundation. The FDE delivers the value. No duplication, no collisions, no orphaned projects.
The Career Path
The traditional data career ladder is vertical: associate data engineer, data engineer, senior data engineer, staff. Same work, more complexity, more scope. The ceiling is either management or architecture, neither of which is the actual work anymore.
DPE to FDE is a different kind of progression. It is not a promotion within the same discipline. It is a graduation from mastering the data layer to deploying capability on top of it. A DPE who understands source systems, transformation logic, semantic models, and agent interfaces has exactly the context an FDE needs. They know what the data can and cannot do. They know where the contracts are strong and where they are fragile. They carry the full picture of the foundation with them when they move forward into the business.
This is not the same as an FDE who “also does data work.” An FDE who came up through the DPE path builds differently. They do not treat the semantic layer as a black box. They know its internals, its limits, its assumptions. When something breaks at the data layer, they diagnose it instead of filing a ticket. When they need a new data product, they can spec it precisely because they have built them before.
The progression is intentional, not accidental. You are not losing a DPE when they become an FDE. You are gaining an FDE who carries context that externally hired FDEs spend months acquiring.
The Succession Problem
When your best DPEs graduate forward, the data products still need owners. Pipelines still run. Semantic models still evolve. New consumers still appear. The BAU does not disappear because the person who built it moved on.
This is a real tension and it deserves its own treatment. For now, the short answer: the DPE role is not a waystation. Some DPEs will stay DPEs because the work suits them, because they prefer building foundations over deploying forward, because the craft of data products is deep enough to sustain a full career. The progression to FDE is available, not mandatory.
But the staffing model has to account for it. If every senior DPE becomes an FDE, your data product team is permanently junior. That is a problem.
The Blur That Remains
With the DPE-to-FDE path defined, most of the role confusion resolves. But one area stays genuinely ambiguous: the PM’s boundary with both.
PM absorbing technical decisions. A PM with deep platform knowledge starts specifying not just “what” but “how.” They design the integration architecture, not just identify the need. They make data modeling decisions that should belong to the DPE. They scope FDE projects so tightly that the FDE becomes an implementer rather than an engineer solving a problem.
This is the PM’s failure mode: governance becomes micromanagement. The fix is in the contract. The PM decides what should exist and where it should live. The DPE decides how to build the data product. The FDE decides how to build the solution. “What” and “where” belong to the PM. “How” does not.
FDE bypassing the PM. An FDE embedded deep in a business function starts seeing opportunities directly. They do not wait for the PM to identify gaps. They build. This is productive when the FDE has good judgment about what is already covered by existing platforms. It is destructive when they do not, and you end up with a custom build that duplicates licensed capability.
The resolution is trust calibration. FDEs who consistently make good build-vs-configure decisions earn more autonomy. New FDEs route through the PM until they demonstrate platform awareness.
Designing for Today, Building People for Tomorrow
The right answer now is three roles with clear contracts. DPE builds the data layer. FDE consumes it to build solutions. PM governs what gets built and where. Clean boundaries, defined interfaces, an intentional career path from DPE to FDE for those who are ready.
But the ecosystem is not static. As agents get more capable, the amount of work each role does manually compresses. DPEs spend less time writing pipelines and more time defining contracts. FDEs spend less time building applications and more time directing agents that build them. PMs spend less time mapping platforms and more time making judgment calls about where AI should and should not operate autonomously.
The roles do not disappear. They elevate. The work shifts from building to directing, from implementing to deciding, from coding to governing. The humans in these roles become more valuable as the systems around them get smarter, because the judgment layer is the last thing to automate.
Design your org chart for today’s complexity. Hire people who will outgrow it.