By the end of 2026, developers outside formal IT departments are expected to account for at least 80% of the user base for low-code tools, up from 60% in 2021. Gartner has projected that citizen developers will build 80% of all tech products in this period. The numbers describe a structural shift in how enterprise application development happens — and they explain why the organizations that get the operating model right capture significant advantages while the ones that don't accumulate platform sprawl, shadow IT exposure, and governance debt at unprecedented speed.

The deeper signal isn't that citizen development is rising. It's that the enterprises succeeding at scale have stopped treating citizen development as a separate IT-adjacent activity and started treating it as a core operating model question. The framework that works is fusion teams — and the difference between organizations that scale fusion teams effectively and those that don't is almost entirely about design, not technology.

What Fusion Teams Actually Solve

The traditional model of enterprise application development has a structural bottleneck: IT capacity. With infrastructure, security, data governance, and a growing AI workload competing for attention, IT teams cannot meet every application request. Backlogs grow. Business problems wait. The applications that get built are the ones IT prioritizes — often not the ones with the highest business value, just the ones with the loudest sponsors or the clearest budget paths.

Citizen development addresses this by allowing business users to build applications themselves using low-code platforms. The problem is that pure citizen development, left ungoverned, produces predictable failure modes: applications that don't meet non-functional requirements (security, reliability, performance, scalability), duplicated logic across departments, data silos, and integration gaps with enterprise systems. Forty-two percent of IT managers cite shadow IT as a major challenge with low-code adoption. The same survey research finds most organizations lack adequate governance over how citizen-built applications and users access information.

Fusion teams resolve the tension. A fusion team is a cross-functional working unit that combines citizen developers (business domain experts who understand the problem), professional developers (who handle complexity, integration, and architectural decisions), and IT specialists (who provide governance, security, and platform oversight). All three groups work from a shared backlog inside the same low-code platform. The citizen developer prototypes the workflow. The professional developer extends it with custom logic where complexity requires it. The IT specialist enforces the governance guardrails that keep the result production-worthy.

The Operating Model Mechanics

The fusion teams that work in practice share a specific operating model. First, they run on shared sprint backlogs. McKinsey research on developer velocity found that companies empowering citizen developers score 33% higher on innovation than bottom-quartile peers — but only when business technologists and professional developers work from a single sprint backlog rather than parallel tracks. The mistake is segregating them. The win is integrating them inside the same agile cadence.

Second, sprint length compresses. Classic scrum runs two to four weeks. Fusion teams running low-code platforms typically operate on one- to two-week sprints because the build time itself compresses. The discipline cost is tighter backlog refinement — with shorter cycles, ambiguity in user stories shows up immediately, and teams that don't invest in upfront clarity stall fast.

Third, IT owns the platform; business owns the build. Microsoft's fusion development framework separates concerns cleanly. IT owns platform controls, data access rules, integration policies, environment management, and security baselines. Business owns the application logic, workflow design, and user experience. The platform is the contract between them — IT enforces governance through the platform itself rather than through approval queues.

The Center of Excellence Connection

The fusion teams model only scales when the platform underneath it is governed correctly. This is where the Power Platform Center of Excellence comes in. A CoE provides the platform infrastructure that makes fusion teams possible at enterprise scale: maker onboarding processes, environment strategy, DLP policies that tier connector access rather than blocking it broadly, application lifecycle management, and usage telemetry that surfaces governance issues before they become incidents.

Organizations with mature CoEs achieve 25-30% faster time-to-production for approved solutions compared to ad-hoc development. The CoE doesn't slow citizen development down. It makes more citizen development possible because the paths are clear and the guardrails don't require anyone to stop and ask permission at every step. The pattern that distinguishes effective Power Platform CoEs from bureaucratic ones is exactly the same pattern that distinguishes effective fusion teams from chaotic citizen development — governance designed as enablement rather than control.

What Goes Wrong Without the Structure

The organizations that try to scale citizen development without fusion team structure encounter predictable problems. Application sprawl: hundreds of low-code applications built without inventory, ownership, or lifecycle management, each becoming a maintenance liability over time. Integration debt: citizen-built applications that work in isolation but can't talk to enterprise systems, requiring rework when the next dependency emerges. Security blind spots: applications built with default permissions, accessing sensitive data without DLP enforcement, creating audit findings that take months to remediate.

The compounding cost is significant. A citizen-built application that worked for a department of twelve people often can't scale to the broader organization without substantial rebuild — not because the platform can't handle the load, but because the architectural decisions made during initial development weren't designed for scale. Fusion teams prevent that failure mode by bringing professional developers into the build at the moment complexity warrants it, not after the application has spent months accumulating technical debt.

What Enterprise Leaders Should Be Doing

Three priorities deserve attention for organizations building fusion team capability. First, audit current low-code application inventory and ownership. Most organizations cannot produce a complete inventory, and the inventory itself usually reveals where ungoverned development has accumulated risk. Second, invest in the CoE infrastructure that makes fusion teams possible: environment strategy, DLP tiers, maker onboarding, ALM tooling. Without that foundation, fusion teams become governance theater rather than operational leverage. Third, redesign the operating model around shared sprint backlogs. The structural difference between scaled and stalled fusion programs is whether business and IT work from the same backlog or parallel tracks.

At BabyBots, Power Platform engagements that produce durable results consistently follow this sequence — platform governance first, fusion team operating model next, citizen development at scale only when the foundation is in place. The economics of citizen development in 2026 favor organizations that move with the structural shift. The cost of getting it wrong isn't measured in slower adoption. It's measured in the rebuild work required when ungoverned citizen development hits the inevitable wall.