Design Your Operating Model or It Will Design You

Every IT organization has an operating model. Most just didn’t design it.

It emerged from years of decisions — some deliberate, most not. A QA team was separated from development because quality was suffering. An architecture review board was created after a costly technical decision. A change advisory process was added after a production incident. None of these were bad calls in isolation — each was a reasonable response to a real problem. Together they produced something nobody would have chosen from scratch.

This isn’t a failure of leadership. It’s what happens when operating model design is treated as an output of organizational events rather than an input to them.

What an Operating Model Actually Is

An operating model is the set of decisions that determine how your organization delivers on its strategy:

• How work is structured and who owns what outcomes
• How decisions are made and at what level
• How teams coordinate and hand off across boundaries
• How performance is measured and improved

Every IT organization has all of these. The only question is whether they were chosen deliberately or accumulated over time through workarounds, reorgs, and informal agreements.

The Failure Modes That Emerge Without Design

When IT organizations don’t deliberately design their operating model, the same patterns tend to appear:

Ownership without accountability. Teams own codebases, not outcomes. Nobody is responsible for whether a capability actually serves the business — only for keeping their piece of the stack running. When something is slow to deliver or broken in production, it’s genuinely unclear who should fix it.

Structure that fights the work. Teams are organized by technology layer — frontend, backend, data, platform, ops — but the work requires all of them to coordinate. Every delivery becomes a cross-team negotiation. The structure creates the overhead it was supposed to avoid.

The build-run split. Development teams hand off to operations teams who had no involvement in design decisions. Incidents are slow to resolve because the people who understand the code aren’t the people who run it. Post-mortems surface the same root causes repeatedly.

Architecture by accident. Decisions about service boundaries, data ownership, and integration patterns get deferred because there’s no designed process for making them early. By the time they’re visible, they’re expensive to change.

Most of these patterns appeared for good reasons at the time. The problem isn’t that they were created — it’s that they outlive the context that made them necessary.

What Intentional Design Actually Requires

Effective IT operating model design starts with three questions — and most organizations skip all three:

1. What outcomes do teams own, not just what they do? The distinction matters. A team that owns “the API” is optimizing for something different than a team that owns “customers can complete checkout reliably.” Outcome ownership changes what people pay attention to.

2. Who is accountable end-to-end? Not “shared responsibility” — actual accountability. Someone who can be held responsible for whether the solution works in production, not just in their sprint. Shared accountability is usually no accountability.

3. How do decisions flow? Which decisions are made at team level, which need coordination, which need escalation? Organizations that can’t answer this clearly spend enormous energy on decisions that should be cheap.

These three questions don’t give you the design — but they surface the assumptions and gaps that the current model is built on. The answers become the foundation for everything else: team topology, process design, how work moves between teams, and what “done” means at each stage.

What a Designed Operating Model Actually Delivers

When the model is intentional, the effects are concrete. Teams ship without constant cross-team negotiation because ownership is clear. Incidents get resolved faster because the people who built the solution are accountable for running it. Architecture decisions happen early, when they’re cheap, rather than late, when they’re expensive. New people can orient themselves to how the organization works without depending on whoever happens to sit next to them.

The informal structure you have today isn’t the enemy — it’s evidence that your organization is finding ways to function. But informal structures depend on specific people, don’t survive reorgs, and can’t scale. Intentional design replaces fragile workarounds with something that holds up under growth and change.

Your operating model already exists. The only question is whether you designed it — or whether you’re ready to change that.