IT Operating Models, Explained - Without the Theater
- Ryan King
- 5 days ago
- 8 min read
Ask ten consultants to define an IT operating model and you will get ten slides full of boxes, swim lanes, and invented vocabulary. None of it answers the only question leaders actually care about.
How does work flow through this organization.
An operating model is not a diagram. It is not a target-state PowerPoint. It is the set of decisions that determines how ideas turn into outcomes, how teams interact, and where accountability actually sits. When it works, execution feels smooth. When it fails, everything slows down and no one is quite sure why.
Most of the pain is not going from good to great. It is going from old-school, 1980s-style IT delivery to modern delivery. From projects to products. From handoffs to ownership. From approvals to flow.
This article strips operating models down to what matters, shows the few decisions that truly shape them, and uses real examples to prove it does not need to be complicated.
TL;DR
An IT operating model is simply how work flows through your organization. Most operating model failures come from unclear ownership, misaligned funding, and structures built for a different era of IT. Research from DORA and others shows that simpler, product-oriented models outperform complex, project-heavy models on speed, quality, and reliability. Real-world transformations at organizations like ING and modern product organizations like Amazon show the same pattern: long-lived teams with clear ownership and clear measures move faster and break less. The goal is not a perfect org chart. The goal is flow.
(Sources: DORA, Accelerate State of DevOps Report, 2023; McKinsey, ING’s Agile Transformation, 2017; AWS Executive Insights, Amazon’s Two Pizza Teams)
What an Operating Model Really Is
Here is the simplest definition that holds up: An IT operating model is how work flows from idea to production and who is accountable at each step.
If you cannot explain your operating model in plain language, it is probably not working.
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). That is correct, but abstract. In practice, operating models show up in very tangible ways:
Operating models are not theory. They are lived experience.
Why Operating Models Feel So Hard
Operating models become overcomplicated for predictable reasons.
They accumulate history
Teams are added. Roles are layered. Committees multiply. No one wants to remove a governance step that was created after a painful incident five years ago. The organization carries every scar forward.
They are redesigned on slides instead of through behavior
Leaders declare a “product model” but keep annual project funding, project success metrics, and project approval gates. The labels change. The system does not.
They are treated like a one-time redesign
In reality, an operating model should evolve as strategy, scale, and architecture change.
BCG notes that complexity and unclear accountability are persistent drivers of slow execution and employee frustration in technology organizations (Source: BCG, Simplifying IT Operating Models, 2020).
The Real Shift: From Old School IT to Modern Delivery
This is the part most organizations underestimate.
Classic IT delivery was designed for a world where:
Systems changed slowly
Releases were rare
Risk was managed through approvals and process
Work was organized as projects handed from team to team
Modern delivery assumes the opposite:
Systems change constantly
Releases are frequent
Risk is managed through automation, testing, and fast feedback
Teams own services end to end
DORA’s research shows that high performers can deploy on demand, with lead times under a day, and still maintain strong reliability outcomes (Source: DORA, Accelerate State of DevOps Report, 2023). That level of performance is almost impossible in a handoff-heavy operating model.
This is why the hardest operating model leap is not better to best. It is old to modern.
What the Research Says: Flow Beats Control
DORA’s work is powerful because it connects technology delivery performance to broader organizational performance, and it measures delivery performance in a simple way: deployment frequency, lead time for changes, change failure rate, and time to restore service (Source: Google Cloud, Announcing the 2023 State of DevOps Report, 2023).
Those metrics do not improve because people work harder. They improve when work flows.
As Jez Humble famously wrote, “If it hurts, do it more frequently, and bring the pain forward” (Source: Humble, Continuous Delivery).
That principle is not just technical. It is operating model design. When you ship more frequently, you are forced to simplify handoffs, reduce batch size, and clarify ownership. The operating model either adapts or breaks.
The Questions That Actually Matter
When leaders refresh an operating model, a small number of decisions do most of the work.
1. Are you organized by product, platform, or application?
This is one of the most consequential choices.
Organizing by application can create clear ownership, but it often duplicates effort and slows cross-team work.
Organizing by platform can increase reuse and consistency, but it can also become a bottleneck if the platform team acts like a gatekeeper.
Organizing by product or value stream aligns teams to outcomes, not components, but it requires strong prioritization and clear accountability.
The cleanest modern pattern is a mix: stream-aligned teams supported by platform teams. Team Topologies is useful here because it gives simple language for team types without inventing a new religion (Source: Team Topologies, Key Concepts, 2025; Martin Fowler, Team Topologies, 2023).
2. How does work get funded?
Funding is the operating model. Most organizations just do not realize it.
Project funding encourages batching, long planning cycles, and defensive scope control. Persistent team funding supports continuous improvement and faster response to change.
McKinsey highlights that modern agile enterprises fund stable teams and products rather than a rotating parade of projects (Source: McKinsey, Funding the Agile Enterprise, 2019).
If teams must rejustify their existence every quarter, they will optimize for optics, not outcomes.
3. Who sets priorities and how often?
Operating models fail when prioritization is unclear, or when prioritization happens far away from the teams doing the work.
Strong models have:
One clear prioritization forum
A clear cadence
A visible tradeoff process
The board and executive team should never have to guess what the top three priorities are this quarter.
HBR has repeatedly noted that unclear prioritization mechanisms are a core driver of execution failure (Source: HBR, Why Strategy Execution Unravels, 2016).
4. Where do decisions get made?
Most operating model slowdown is decision latency.
Teams wait for approvals. Committees meet monthly. Exceptions require escalation. Leaders step into details because they do not trust the system.
DORA’s research shows that high performers push authority closer to the teams doing the work, reducing handoffs and delays (Source: DORA, 2023).
Autonomy without clarity is chaos. Autonomy with clear boundaries is speed.
5. How do you measure success?
Metrics complete the operating model.
If teams are measured on utilization, they will maximize busyness. If they are measured on outcomes, they will optimize flow and customer impact.
DORA’s four metrics are common because they are hard to game and strongly connected to delivery performance (Source: Google Cloud, 2023; DORA, 2023).
Real Examples: What Modern Operating Models Look Like
Amazon and the logic of end-to-end ownership
Amazon popularized the idea of small teams with clear ownership. In AWS language, two-pizza teams have “single-threaded ownership” over a specific product or service and “own and run their service end-to-end” (Source: AWS Executive Insights, Amazon’s Two Pizza Teams).
That phrase matters. End to end ownership collapses handoffs. It makes accountability real. It forces teams to care about outcomes, not just output.
ING and the shift from traditional structure to agile ways of working
ING’s agile transformation is one of the best documented examples of a large, traditional organization shifting its operating model. Their leaders describe moving from a traditional organization to an agile model inspired by digital natives and adopting new structures to improve speed and customer centricity (Source: McKinsey, ING’s Agile Transformation, 2017).
The signal here is not the labels. It is the intent: break work into smaller units, clarify ownership, and make it easier to prioritize and deliver continuously.
BCG also notes ING’s transformation as a paragon of agile ways of working and ties it to improved time to market and customer-centric behavior (Source: BCG, HR’s Pioneering Role in Agile at ING, 2018).
Spotify and a crucial caveat most companies miss
The Spotify model became famous, but Spotify itself warned people not to treat it as a copy-paste blueprint. Their own engineering blog emphasized that their “journey is in progress” and that there is variation across squads (Source: Spotify Engineering, Spotify Engineering Culture Part 1, 2014).
This is a useful lesson for operating models. The point is not squads and tribes. The point is clarity of ownership, autonomy with alignment, and fast feedback.
Government digital services and multidisciplinary teams
Modern operating models are not just a private-sector story. Government digital service standards explicitly emphasize multidisciplinary teams and keeping decision makers close to the work so teams can respond quickly to what they learn (Source: GOV.UK Service Manual, Service Standard Point 6, 2019).
This is operating model design in plain English: put the right skills together, keep accountability close, and reduce the distance between learning and action.
The Anti-Patterns That Keep Organizations Stuck in 1980s IT
If you see these, you are not dealing with a tooling problem. You are dealing with an operating model problem.
The project factory
Work is approved in large batches, broken into phases, and handed across silos. Success is measured by delivering the project, not improving the service.
The approval maze
The organization manages risk through checkpoints instead of through engineering hygiene. Every failure adds a new gate.
The platform bottleneck
A platform team exists, but it is treated like a ticket queue. Teams cannot move without waiting.
Team Topologies explicitly frames platform teams as accelerators for stream-aligned teams, not as gatekeepers (Source: Team Topologies, Key Concepts, 2025).
Local optimization
Every team has its own scorecard. No one owns the end-to-end outcome. Leaders wonder why the organization cannot move as one.
A Simple Way to Refresh Your Operating Model
If you want a clean approach that does not turn into consulting theater, do this.
Step 1: Map flow in one page
Pick one important change. Track it from request to production. Count handoffs. Count wait states. Count how many approvals it needed.
This exercise usually exposes more truth than a month of workshops.
Step 2: Make ownership explicit
For your top services and platforms, write down one name for who owns each outcome. Not who manages a team. Who owns the outcome.
Step 3: Fix funding and prioritization before you touch org charts
If you do not change how work is funded and prioritized, reorganizations will not stick (Source: McKinsey, Funding the Agile Enterprise, 2019).
Step 4: Measure flow and reliability
Adopt delivery performance measures that reflect flow and operational health. Use DORA metrics if you want a proven baseline (Source: Google Cloud, 2023; DORA, 2023).
Step 5: Keep governance lightweight and decision-driven
If a meeting does not change a decision or behavior, it is not governance. It is overhead.
Key Takeaways
An operating model is how work flows, not a diagram. The hardest shift is old-school IT delivery to modern delivery. Stable ownership, clear funding, simple prioritization, and outcome metrics beat complexity every time. DORA’s research shows that speed and stability can coexist when the operating model supports flow.
Operating models do not need to be hard. They need to be honest.
How Can RLK Help?
RLK Consulting helps leadership teams assess how work actually flows today, identify where friction is slowing execution, and design operating models that fit their strategy and scale.
If your organization feels slower than it should, the problem is rarely effort. It is almost always the model.
Sources
DORA, Accelerate State of DevOps Report (2023)
Google Cloud, Announcing the 2023 State of DevOps Report (2023)
McKinsey & Company, ING’s Agile Transformation (2017)
McKinsey & Company, Organizing for the Future (2018)
McKinsey & Company, Funding the Agile Enterprise (2019)
Boston Consulting Group, Simplifying IT Operating Models (2020)
Boston Consulting Group, HR’s Pioneering Role in Agile at ING (2018)
AWS Executive Insights, Amazon’s Two Pizza Teams (n.d.)
Spotify Engineering, Spotify Engineering Culture Part 1 (2014)
GOV.UK Service Manual, Service Standard Point 6: Have a Multidisciplinary Team (2019)
Team Topologies, Key Concepts (2025)
Martin Fowler, Team Topologies (2023)
Harvard Business Review, Why Strategy Execution Unravels (2016)
Humble, Jez and Farley, David, Continuous Delivery (as quoted in Goodreads; corroborated by Y. Brikman, Continuous Delivery Review, 2014)
