IT Operating Models, Explained Without the Theater

Ask ten consultants to define an IT operating model and you get ten slides full of boxes and swim lanes. None of it answers the real question: how does work flow through this organization, and who is accountable when it does not?

An operating model is the set of decisions that determines how ideas turn into outcomes, how teams interact, and where accountability actually sits. Most of the pain companies feel is not about going from good to great. It is about going from 1980s-style IT delivery, designed for waterfall projects and change control boards, to modern delivery that assumes frequent releases and fast feedback. That transition is harder than most transformation programs admit.

The goal is not a perfect org chart. The goal is flow.

What an Operating Model Really Is

McKinsey describes an operating model as the combination of structure, governance, and ways of working that enable execution (Source: McKinsey, Organizing for the Future, 2018). In practice, operating models show up in measurable ways:

How long it takes to ship a meaningful change
How many handoffs exist between an idea and a decision
How often priorities change mid-cycle
How often incidents happen and how fast teams recover
Whether leaders trust the metrics they are being shown

None of these are org chart questions. They are questions about behavior, incentives, and accountability. Organizations can redraw the org chart without changing any of them.

Why They Feel So Hard

Two things make operating models difficult to change.

First, they accumulate history. Teams are added as problems arise. Roles are layered in as organizations grow. Committees multiply because no one has clear authority. The result is a structure built for a moment that no longer exists, maintained by people who have adapted their habits around it.

Second, they are redesigned on slides instead of through behavior. Leaders declare a “product model” but keep annual project funding, approval gates, and centralized prioritization. The announcement and the reality point in opposite directions. BCG notes that complexity and unclear accountability are persistent drivers of slow execution, and that most interventions address the wrong layer (Source: BCG, Simplifying IT Operating Models, 2020).

Declaring a new model does not change the model. Changing funding structures, decision rights, and team boundaries does.

The Real Shift from Old-School IT to Modern Delivery

Classic IT delivery was designed for slow change and rare releases. Risk was managed through approvals: change advisory boards, architecture reviews, long testing cycles. The model made sense when changes were infrequent and hard to reverse.

Modern delivery assumes the opposite. Change is constant. Releases are frequent. Risk is managed through automation, fast feedback, and the ability to detect and recover quickly from failures.

DORA research shows that high-performing engineering organizations deploy on demand with lead times under a day, while simultaneously maintaining strong reliability (Source: DORA, Accelerate State of DevOps Report, 2023). This is not a feature of their technology. It is a feature of their operating model. Small teams with clear ownership, automated pipelines, and the authority to make decisions without waiting for approval.

Jez Humble’s principle captures the underlying logic well: “If it hurts, do it more frequently, and bring the pain forward” (Source: Humble, Continuous Delivery). Infrequent releases are not safer. They bundle more risk into each event and reduce the organization’s ability to learn.

The Questions That Actually Matter

How is the organization structured?

The cleanest modern pattern is stream-aligned teams: small teams that own an outcome end to end, supported by platform teams that provide shared capabilities without creating bottlenecks (Source: Team Topologies, Key Concepts, 2025). The test is not whether the structure looks right on a diagram. The test is whether teams can make decisions and ship changes without waiting for another team to unblock them.

How does work get funded?

Project funding encourages batching. When teams must submit project requests to access budget, they are incentivized to ask for more than they need and to inflate scope. Persistent team funding, where a stable team has a recurring budget tied to outcomes rather than projects, supports continuous improvement and honest prioritization.

McKinsey highlights that modern agile enterprises fund stable teams rather than a rotating parade of projects (Source: McKinsey, Funding the Agile Enterprise, 2019). The funding model is not a finance question. It is an operating model question. It determines how teams behave.

Who sets priorities and how often?

Strong models have one clear prioritization forum with a visible tradeoff process. When multiple bodies set priorities, teams spend energy navigating competing demands rather than delivering. The goal is not more governance. It is governance that produces clearer decisions faster.

Where do decisions get made?

DORA shows that high-performing organizations push authority closer to the teams doing the work (Source: DORA, 2023). Autonomy with clear boundaries is speed. Autonomy without clear boundaries is chaos. The design question is not whether to decentralize. It is what decisions to decentralize and what guardrails to leave in place.

How do you measure success?

DORA’s four metrics, deployment frequency, lead time for changes, change failure rate, and time to restore service, are hard to game and strongly connected to actual delivery performance. They measure the system, not individual activity. Any operating model that cannot produce reliable answers to these four questions is running on intuition.

Real Examples Worth Knowing

Amazon

Amazon’s two-pizza team structure assigned single-threaded end-to-end ownership to small teams with clear accountability for outcomes (Source: AWS Executive Insights). The design priority was eliminating coordination overhead, not optimizing team size. Teams that can ship independently ship faster and take clearer accountability for results.

ING

ING’s agile transformation moved the organization from a traditional functional structure toward squad and tribe models inspired by digital-native companies (Source: McKinsey, ING’s Agile Transformation, 2017; BCG, HR’s Pioneering Role in Agile at ING, 2018). The redesign changed funding, governance, and ways of working at the same time. Changing only the org chart would not have produced the same results.

Spotify’s Warning

The Spotify model is widely cited and widely misapplied. Spotify itself noted that the diagram circulating in the industry does not reflect how they actually work (Source: Spotify Engineering, Spotify Engineering Culture Part 1, 2014). Copying an org chart from a company with different context, history, and incentives does not copy the operating model. The context is not portable.

Government Digital Services

Government digital service organizations have demonstrated that multidisciplinary teams with clear user outcome ownership can deliver better results than traditional IT departments, even inside large bureaucratic systems (Source: GOV.UK Service Manual, 2019). The enabling condition was not funding or technology. It was team design and decision rights.

Anti-Patterns That Keep Organizations Stuck

The project factory. Every initiative becomes a project with a start and end date. Teams form, deliver, and dissolve. No one accumulates ownership or expertise on a product. Quality and accountability both erode.

The approval maze. Changes that should take a day take weeks because they require sign-off from bodies that were designed for a different risk environment. The maze does not reduce risk. It delays learning.

The platform bottleneck. Platform teams that act as gatekeepers rather than enablers create the same problem as shared services: queues, prioritization conflicts, and teams waiting for other teams. Team Topologies frames platform teams as accelerators, and the test is whether developers treat the platform as a product they choose to use, not a tax they pay (Source: Team Topologies, Key Concepts, 2025).

Local optimization. Every team has its own scorecard and optimizes for it. Cross-team dependencies are nobody’s problem. The system slows down because the system-level outcomes are not owned.

A Simple Refresh

The operating model work does not have to begin with a large transformation program. A practical starting point:

Map how work flows from idea to production in one page. If it takes more than one page, the model is more complex than it needs to be.
Make ownership explicit. Every product, platform, and outcome should have one name attached to it.
Fix funding and prioritization before touching org charts. Changing the boxes without changing the incentives produces a different diagram and the same behavior.
Measure flow and reliability using DORA metrics from the start. Metrics that are not in place at the beginning of a transformation rarely appear during it.
Keep governance lightweight and decision-driven. The goal of governance is faster, clearer decisions. Any governance mechanism that does not produce them is overhead.

Key Takeaways

IT operating models fail in predictable ways: unclear ownership, project-based funding, approval processes designed for a slower era, and metrics that measure activity rather than outcomes. DORA research consistently shows that simpler product-oriented models outperform complex project-heavy models on speed, quality, and reliability.

The redesign question is not which boxes to move. It is which decisions to make differently, and what has to change in funding, accountability, and measurement to support those decisions.

How RLK Can Help

RLK Consulting works with technology leaders to diagnose and redesign IT operating models, with a focus on funding structure, team design, and decision rights rather than org chart aesthetics. The work starts with understanding how work actually flows and where it stalls, then builds a sequenced plan to change the things that have leverage. If your organization is operating on a model that was designed for a different era, contact us to discuss what a practical modernization looks like.