For most of the last two decades, IT and the business operated as separate organizations that occasionally collaborated on projects. The model worked when application demand was modest and software releases were measured in years. It is breaking down everywhere now because the pace of change has outrun the project-handoff model that connected the two sides.
Gartner research shows that 84 percent of large and midsize companies have already set up multidisciplinary fusion teams that blend technology and business expertise around shared outcomes. The number is not surprising. It reflects what executive teams have been telling each other for years, which is that the old separation is no longer sustainable.
A fusion team is a cross-functional team that brings together IT professionals and business domain experts to deliver a specific outcome. The team is organized around the outcome, not around functional reporting lines. A fusion team built around employee experience will include HR specialists, IT engineers, an operations lead, and a data analyst, all reporting into a single team purpose.
The structure sounds straightforward. The execution is what separates fusion teams from cross-functional projects, which everyone has been doing for years.
The persistence matters most. Cross-functional projects break apart at the end of the project. Fusion teams keep going, which means the relationships, the institutional knowledge, and the product improvement compound over time.
Three factors explain why enterprises consistently see better outcomes from fusion teams than from traditional project structures.
The handoff cost disappears. In the old model, the business writes a requirements document, IT translates it into specifications, builds something, and hands it back. Each handoff loses context and adds time. In a fusion team, the people who understand the business problem sit alongside the people building the solution. The context never leaves the room.
The feedback loop tightens. When users have an issue with the application, the team that built it hears about it immediately. Fixes happen in days, not quarters. The product gets better continuously instead of waiting for the next major release.
The shared accountability changes behavior. Gartner reports that only 48 percent of digital initiatives meet or exceed business outcome targets, often because IT and the business each blame the other when results disappoint. Fusion teams force shared ownership, which produces better decisions all along the way.
Setting up a fusion team is more than putting people from different functions in the same room. Five elements determine whether the team produces durable results.
A typical fusion team has five to eight people. One business owner who has deep domain knowledge and clear accountability for the outcome. One technical lead who can architect the solution and govern the build. Two to four product builders, who may be IT engineers, business analysts, or trained citizen developers. One data specialist who handles reporting and analytics. Some teams add a change management or user research role for customer-facing products.
Each role has a clear remit. The business owner sets priorities and defines what success looks like. The technical lead makes architecture and governance decisions. Product builders own delivery. The data specialist owns measurement. Without clear roles, the team falls back into functional patterns and the fusion benefits evaporate.
Every member of the team is measured on the same OKRs, which are tied to the business outcome the team owns. This is the single most important structural decision. When the OKRs are shared, the team makes trade-offs together. When OKRs are split by function, the team makes trade-offs at each other's expense.
Fusion teams need a platform where both IT and business members can contribute. Traditional development environments exclude business users. Spreadsheets and standalone tools exclude IT governance. The platform has to support both audiences with the appropriate guardrails for each. This is one of the reasons enterprise low-code platforms have become central to fusion team models.
Fusion teams cannot operate without governance. Without it, you get shadow IT at speed. With it, business teams build what they need under IT controls, with audit trails, role-based access, and policy enforcement applied to every application by default.
Consider a mid-market financial services firm that needed a new customer onboarding portal. The traditional approach would have been: business writes requirements, IT estimates the build at six months, project gets approved for the next budget cycle, build starts, scope changes during the build, launch slips, the portal ships nine months later than promised.
The fusion team approach looks different. A team is assembled with one onboarding operations lead, one technical lead from IT, two builders, and one data analyst. They work together for six weeks. The operations lead defines the workflow as it should be. The technical lead handles the integrations with the core banking system and the document management platform. The builders configure the portal. The data analyst sets up the dashboards that will measure onboarding cycle time.
At the end of six weeks, the portal launches in production. Onboarding cycle time drops from 11 days to 4. The team stays together, owns the portal as a product, and keeps improving it. Six months later, the same team has shipped two more enhancements and started building a second portal for a different customer segment. The work has compounded in a way it never did under the old model.
Most enterprises do not become fusion-organized overnight. The transition typically starts with one or two pilot teams that prove the model before broader rollout.
Run the first team for at least 90 days before evaluating. Most fusion teams hit their stride somewhere between weeks six and twelve. Pulling the plug too early misses the moment when the model starts to pay off.
Kissflow is built for the way fusion teams actually work. Business team members can configure forms, workflows, and approvals through a visual interface, while IT keeps governance, audit trails, and policy enforcement applied to everything that gets built. The same environment supports both audiences without forcing either one to learn the other's tools.
AI in Kissflow generates application blueprints rather than disposable code. A blueprint is a structured description of what the application does, which both business and IT team members can read, change, and govern. This matters for fusion teams because the team is making decisions together about an asset they will own for years. Code-based applications make that hard. Blueprint-based applications make it natural.
In practice, Kissflow customers use the platform as the operating layer for fusion teams across customer onboarding, vendor management, employee experience, IT service requests, and dozens of other operational products. Each fusion team owns a product. The platform gives them a shared environment to build, run, and improve it together. The result is what most enterprises have been trying to achieve for years: business teams that move fast, IT that keeps control, and outcomes that compound over time.
What is a fusion team?
A fusion team is a cross-functional team that brings together IT professionals and business domain experts to deliver a specific business outcome. The team is organized around the outcome rather than around functional reporting lines, and members are accountable to shared OKRs.
How is a fusion team different from a cross-functional project team?
Cross-functional project teams disband at the end of the project. Fusion teams persist, evolving the product they own over time. Cross-functional teams have separate functional accountabilities. Fusion teams share OKRs. The persistence and shared accountability are what allow fusion teams to compound improvement year over year.
Who leads a fusion team?
Most fusion teams use a co-leadership model, with a business owner who handles priorities and outcomes and a technical lead who handles architecture and governance. The two share accountability for the team's results. Some organizations call this the two-in-a-box model.
Do fusion teams require low-code platforms?
Not strictly, but enterprise low-code platforms are increasingly the foundation for fusion teams because they give business and IT members a shared environment to build and run applications together. Without a shared platform, fusion teams tend to drift back into the old IT-business handoff pattern.
How many fusion teams should an enterprise have?
Start with one or two pilot teams. After 90 days, evaluate. Successful pilots typically expand to five to ten fusion teams over the next year, then scale further as the organization adapts its budgeting and reporting structures. There is no universal target. The right number depends on the size of the business and the number of products that justify dedicated team ownership.
What is the biggest reason fusion teams fail?
Functional managers reclaiming time from team members. The fusion model only works if team members are dedicated to the team, not splitting their time between the fusion team and their old functional work. When functional managers pull people back for other priorities, the team's outcome ownership breaks down.
How does governance work in a fusion team model?
Governance is built into the platform the team uses, not enforced as a separate process. Role-based access, audit trails, policy enforcement, and app lifecycle controls apply automatically to everything the fusion team builds. This is why platform choice matters so much in the fusion team model.