Here is a proposal that makes some leaders uncomfortable: get rid of the IT department.
To be clear, we are not suggesting that organizations get rid of technologists. Quite the opposite. Technology expertise has never been more important. We are suggesting that the traditional model—a centralized department that receives requests from the business, translates them into projects, and sends completed solutions back across the wall—has outlived its usefulness.
That model made sense when technology was scarce, specialized, and largely confined to back-office systems. It makes much less sense when nearly every customer experience, employee workflow, product, and growth strategy is inseparable from technology.
And the constraints that once justified centralization have changed. Low-code platforms, SaaS, APIs, and cloud services have made technology easier to create and change. AI is accelerating that shift, putting even more capability into the hands of people outside traditional technology roles. The ability to create and change technology has spread across the enterprise, but most organizational structures haven’t caught up.
The problem isn't that IT is bad at technology; it's that the teams responsible for improving the customer or employee experience often aren't empowered to change the technology shaping it.
The Structure Is the Problem
Most business and technology leaders recognize the pattern. The business identifies a need and submits a request. IT asks for requirements, estimates the work, and places it into their project backlog alongside dozens (or hundreds) of other priorities. The business grows frustrated with the pace. IT grows frustrated with vague requests, shifting priorities, and pressure to deliver without enough context. When the result disappoints, each side points the finger at the other.
This is not a people problem. It is a structural design problem.
A separate IT department institutionalizes handoffs. It creates competing incentives. Business leaders are measured on revenue, customer satisfaction, or operational performance, while technology teams are often measured on delivery, uptime, security, and cost. All of those measures matter, but when the people making technology decisions do not share accountability for the business outcome, tradeoffs become negotiations between departments instead of decisions within a team.
The predictable result is more governance, longer wait times, diluted ownership, and a culture of blame.
Not All Technology Should Live in the Same Place
Dissolving the traditional IT boundary does not mean distributing every technology capability across the enterprise. Some technology benefits enormously from centralization. The more useful distinction is between systems of record and systems of engagement.
Systems of record include core financial platforms, HR and payroll systems, and other authoritative sources of enterprise data. Enterprise foundations include infrastructure, identity, cybersecurity, shared data services, integration standards, and architecture. These capabilities need consistency, resilience, security, and enterprise-wide optimization. A strong central technology function should continue to own or govern them.
Systems of engagement are different. These are the tools and workflows customers and employees interact with every day: CRM, digital channels, service platforms, partner portals, sales enablement, and process automation. Their value depends on how well they solve a specific problem—and how quickly they can adapt as that problem changes. Their purpose is to continually improve the experience they support.
Systems of record and enterprise foundations benefit from centralization. Systems of engagement benefit from proximity to the experience they are designed to improve.
Put Technology Where the Experience Lives
For systems of engagement, the better model is a multidisciplinary experience team embedded in the business. A sales experience team might include sales operators, product owners, designers, analysts, architects, engineers, and change experts—all working toward the same priorities and measures. A customer service team might be organized around resolution time, customer effort, and satisfaction rather than a portfolio of disconnected technology projects.
These teams do not send requirements to IT. They own an experience, understand the people who experience it, and have the capability to improve it continuously. Funding follows the experience or business capability rather than a temporary project. Decision rights sit with the team closest to the work. Accountability is shared from idea through adoption and measurable outcome.
The central technology function still matters, but its job changes. Instead of controlling every decision, it establishes enterprise guardrails such as architecture standards, cybersecurity requirements, data governance, shared platforms, integration patterns, and visibility across the portfolio. This central function protects the enterprise, while the embedded teams improve the experience.
Moving the Boxes Is Not Transformation
There is an easy way to get this wrong: move developers and analysts into business units, update the org chart, and declare victory. If funding still sits in a centralized annual project process, decisions still require multiple governance approvals, enterprise functions can still overrule the team without clear boundaries, and leaders remain accountable only for their piece, the handoffs have simply been renamed.
A successful shift moves four things together: people, funding, decision rights, and accountability. It also replaces project-based governance with enterprise guardrails and experience-based portfolio management. Otherwise, the organization has not eliminated the divide between business and technology; it has simply created a collection of shadow IT teams.
What This Looks Like in Practice
One telecommunications company we worked with started by carving out partner onboarding—a narrow sliver of the customer journey—and creating a multidisciplinary team responsible for improving it.
The results were quick and dramatic: partner onboarding fell from 20 days to one hour.
The improvement did not come from a new tool alone. The team was given dedicated funding, decision-making authority, and shared measures of success. By bringing the necessary business and technology capabilities into one team, the company removed handoffs, shortened decision cycles, and created clear ownership of the full experience.
Technology releases for the team also moved from roughly once every four months to once every two weeks. After seeing the results, the company applied the model to sales, where proposal creation dropped from roughly three weeks to one day. What began as one sliver became a model the organization could replicate elsewhere.
The Point Is Better Experiences—and Better Outcomes
The goal is not decentralization for its own sake. The goal is better experiences that produce better outcomes. It is to put the people who understand the experience in the same team as the people who can change the technology, and create shared accountability for improving it.
So yes: get rid of the IT department. Keep the technologists. Strengthen the enterprise foundations. Then move technology capability as close as possible to the customers and employees whose experiences it exists to improve. Because in the modern enterprise, technology should be organized around the people and experiences it serves—not around the fact that it happens to be technology.
