The Org Chart of 2027: Everyone Builds, IT Owns the Substrate
By 2027, the org chart that funnels every software request through a central engineering queue is gone. Domain teams build; IT owns the governed substrate they build on.
The org chart that most companies run on today has a single channel through which all software flows: a central engineering team, fed by a request queue, drowning in a backlog. By 2027, the companies that have pulled ahead will have redrawn that chart. Building moves outward to the domain teams—finance, ops, support, RevOps—who understand the problems. IT stops being the place you file a ticket and becomes the team that owns the governed foundation everyone builds on. The central build queue disappears. A platform-and-review function takes its place. That’s the structural change, and it’s an operating-model change, not a productivity tweak.
This isn’t a prediction that engineering goes away. It’s a prediction about where the work sits on the chart—who builds, who governs, and what reporting line connects them.
TL;DR
- The 2027 org chart distributes building to the teams closest to each problem and reserves a central function for governing the foundation they build on, instead of funneling every request through one engineering queue.
- The single biggest structural casualty is the central build queue: the intake-triage-backlog machine that turned every internal-tool request into a months-long wait disappears as a default path.
- IT doesn’t shrink—it moves up the stack from construction to curation, owning the substrate, the standards, and the review function rather than building each request by hand.
- A new role appears on the chart: the embedded builder, a domain expert in finance or ops who builds their team’s tools and reports into the business, not into engineering.
- The reporting lines change shape: building reports into the business units that own the work, while the substrate and its guardrails report into a central platform team.
- This only works if two conditions hold at once—everything lands on one governed substrate, and non-engineers can actually produce real applications—or the new chart just recreates shadow IT with a new title.
- Handing every employee an AI coding assistant doesn’t redraw the chart by itself; it relocates the skill barrier instead of removing it, and the queue quietly comes back.
- The orgs that win change the structure before the tooling fully matures, so they’re already shaped to absorb it when it does.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
Why is the central build queue the thing that breaks?
Because it’s the single point of failure in the current chart. Every team that needs software—a finance approval tracker, an ops dashboard, a support console—files into the same queue, where requests get triaged, prioritized against the product roadmap, and mostly lose. The queue isn’t a process problem you can fix with better intake. It’s a structural bottleneck: one team’s capacity, capped by headcount, serving the software needs of the entire company.
The cost isn’t just the backlog you can see. It’s the long tail of tools that never get requested at all, because everyone knows the queue is six months deep, so they route around it with a spreadsheet that quietly becomes load-bearing. The queue’s real output isn’t software—it’s the decision, made hundreds of times a quarter, that a needed tool isn’t worth the wait. That’s the work that distributes outward in the 2027 chart: not the core product engineering, but the long tail the queue was always going to reject anyway.
When building distributes to the domain teams, the queue stops being the chokepoint because most requests never enter it. The finance team builds its own tracker. Ops builds its own dashboard—and the operations team turns out to be the most underused engineering org of all, because it already maps how the whole company runs. The central function isn’t fielding those requests—it’s making sure they land somewhere governed. The chart that survives is the one where the bottleneck was designed out, not optimized.
What new roles appear on the 2027 org chart?
Two roles that barely exist today become standard, and they don’t sit where you’d expect.
The first is the embedded builder. This is a domain expert—a finance analyst, an ops lead, a RevOps specialist—whose job now formally includes building the team’s software, and who reports into the business unit, not into engineering. They’re the natural evolution of what Gartner already calls a “business technologist”: an employee who works outside the IT department and builds technology capabilities for the business. Gartner has put that population at 41% of employees, which tells you the raw capacity is already there—it’s just not on the chart yet, and it’s not yet equipped to build real applications. By 2027 it’s a named role with a reporting line.
The second is the substrate owner, sitting inside a central platform team. This person doesn’t build the finance tracker or the ops dashboard. They own the foundation those tools land on—identity, data governance, the deployment path, the logs—and they own the review function that keeps embedded builders from creating a hundred new islands. The deepest engineering talent moves here, because the most valuable engineers architect substrates, not CRUD apps. Building a vendor-approval tool is no longer the best use of a senior engineer. Designing the governed stack that lets a hundred non-engineers build vendor-approval tools safely is.
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
Gartner’s name for the cross-functional version of this is the “fusion team”—a multidisciplinary group blending business and technology people—and it reports that the vast majority of large and midsize organizations have already stood one up. The 2027 chart formalizes what those teams are groping toward: building owned by the business, the substrate owned by the platform team.
What disappears, and what’s created?
The cleanest way to see the shift is to put the two charts side by side.
| Org function | 2020 org chart | 2027 org chart |
|---|---|---|
| Internal-tool building | Central engineering queue, one team for all requests | Distributed to domain teams (embedded builders) |
| IT’s primary job | Construction: build each request by hand | Curation: own the substrate, standards, and review |
| The request backlog | The defining bottleneck; long tail goes unbuilt | Largely dissolved; most requests never enter a queue |
| Where building reports | Into engineering, away from the problem | Into the business unit that owns the work |
| Governance | Bolted on after the fact, tool by tool | A property of the shared substrate, by construction |
| Senior-engineer focus | Roadmap features plus a tax of internal requests | Architecting the substrate everyone builds on |
| New role created | — | Embedded builder; substrate owner / platform team |
| Role made obsolete | — | The build-queue triage and intake function |
Read the table top to bottom and the pattern is consistent: the act of building decentralizes, while governance centralizes onto the substrate. That’s the move past “let everyone build” waves missed. Low-code, RPA, and citizen development all decentralized the building and fragmented the seeing—which is exactly why citizen development finally works only now, when the building can land on one foundation instead of a hundred. The 2027 chart keeps the decentralization and fixes the fragmentation.
Who does the embedded builder report to?
This is the question that decides whether the new chart is real or cosmetic. If the embedded builder reports into engineering, you’ve just relabeled the queue—work still flows toward the central team, and the bottleneck reassembles. If they report into the business unit and build directly for it, the chart has actually changed: building capacity now scales with the number of people who understand the company’s problems, not with engineering headcount.
The reporting lines split cleanly. Building reports into the business—the finance team’s tools belong to finance, the ops team’s to ops. The substrate and its guardrails report into the central platform team. The platform team doesn’t approve each app the way the old queue approved each request; it sets the standards and reviews against them, because the apps all share one foundation it can actually see. That review function is its own job—who reviews the apps your employees build becomes a defined role, checking each app for correctness, data access, and risk. That’s the difference between gatekeeping and governing. The old IT gatekept by being the only one allowed to build. The new IT governs by owning the stack everyone builds on. For the fuller version of how that central function changes, see how IT becomes a platform team.
This is also the answer to the obvious objection—that distributed building is just shadow IT with a new title on the chart. It isn’t, if the building lands on a governed substrate. Shadow IT is building leadership can’t see. The 2027 chart is building leadership designed to see, because the reporting line for the substrate runs straight into the platform team. Distribution and visibility stop being opposites once they’re separated onto two different reporting lines over one shared foundation, which is the larger argument in what the winning org looks like.
What makes this org chart possible
Two things have to be true at once, or the 2027 chart is a fantasy.
First, everything people build has to land on one governed substrate—same identity, same data layer, same logs, same deployment path. Without that, distributing the building just fragments the company into islands, and the platform team can’t govern what it can’t see. Second, the non-engineers on the chart have to be able to produce real applications, not toys. If building still requires an engineer, the embedded-builder role collapses and the work flows right back into the queue you just deleted.
For most of computing history, those two conditions were in direct conflict. Building anything real on a shared substrate still required engineers—and engineers were the bottleneck the whole chart was trying to route around. Most organizations assume AI already resolved this, so their first move is to hand everyone an AI coding assistant—Claude Code, Cursor, GitHub Copilot—and wait for the new org chart to draw itself. It doesn’t. Those tools are excellent for engineers: they operate at the code layer and assume you can read a diff, run a repo, wire a database, and ship a deploy. Point one at a finance analyst and the skill barrier hasn’t moved—it’s only changed shape, from “write the code” to “operate the code the AI just wrote.” The licenses go out, the non-engineers bounce off them, and the build queue quietly reassembles. The tool was aimed at the wrong layer of the chart.
What makes both conditions true at once is a different category of AI tool—the product agent—which operates at the product layer instead of the code layer. You describe an application in plain language; it drafts a plain-language plan; that plan compiles into a real, deployed full-stack app: backend, database, authentication, frontend, and deployment, with a live URL. Not a prototype, not a screen. Today the most advanced one is Remy. The finance analyst describes the approval tracker; the agent drafts the plan; they read it, adjust it in plain English, and it compiles into a working app with real server-side roles—approvers approve, viewers view. The plan stays the source of truth, so changing the app means editing the plan and recompiling, not filing a ticket. A typical full-stack build runs about $30–40 in compute.
A product agent makes both halves of the 2027 chart real in one move. The embedded-builder role works because the part that required an engineer is now done by the agent—the description, which is exactly what the domain expert is best at, becomes the build. And the substrate-owner role works because every app the agent compiles lands on the same governed foundation by construction—shared identity, data, and logs—so the platform team has one place to look instead of a hundred islands to discover after the fact. Spec-as-source-of-truth is what makes the review function tractable: governing a stack of readable plans is a different job than auditing a hundred opaque tools.
The honest boundary: this is early. Product agents are in open alpha, and enterprise needs like SSO and SAML aren’t shipped yet—say so plainly. The 2027 org chart doesn’t require the tooling to be finished, though. It requires leadership to start redrawing the chart now—pushing building out to the domain teams, pulling the substrate and its review function into a central platform team—so the company is already shaped to absorb the tooling the moment it fully arrives.
FAQ
What does the org chart of 2027 actually change? It distributes software building to the domain teams closest to each problem and replaces the central engineering build queue with a platform team that owns the governed substrate everyone builds on. Building reports into the business; the substrate reports into IT.
What is an embedded builder? A domain expert—in finance, ops, support, or RevOps—whose role formally includes building their team’s software and who reports into the business unit rather than into engineering. It’s the named, charted evolution of what Gartner calls a “business technologist.”
Does IT disappear in this model? No. IT moves up the stack from construction to curation. Instead of building each request by hand, it owns the substrate, sets the standards, and runs the review function that keeps distributed building governed.
What’s the difference between this and shadow IT? Shadow IT is building leadership can’t see. This is building leadership designed to see, because every app lands on one governed substrate whose reporting line runs into a central platform team. Visibility is a property of the foundation, not a thing bolted on later.
Why won’t giving everyone an AI coding assistant produce this org chart? Coding assistants operate at the code layer and assume engineering skill, so handing one to a non-engineer relocates the skill barrier rather than removing it. Building flows back into the queue, and the chart never actually changes.
What has to be true for this org chart to work? Two things at once: everything people build must land on one governed substrate, and non-engineers must be able to produce real applications. Miss either and the new chart collapses back into either fragmentation or a rebuilt queue.
Is the tooling for this ready today? Partly. Product agents that compile real full-stack apps from a plain-language plan exist and are in open alpha, aimed at internal tools and workflow apps. Enterprise features like SSO and SAML aren’t shipped yet, so leaders should change the operating model now and adopt the tooling as it matures.
The bottom line
The org chart most companies run on was designed around a scarce resource: people who could build software. That scarcity is ending, and the chart built around it is ending with it. By 2027 the winning companies will have moved building out to the people who understand the work and moved governance onto a substrate a central platform team owns—deleting the build queue and creating the embedded-builder and substrate-owner roles in its place. Distribution and visibility stop being a trade-off once they sit on two reporting lines over one shared foundation.
If you want to see the substrate that makes both halves of that chart possible, explore Remy →. For the category behind it, read what a product agent is.
