If you’ve ever been part of an operating model redesign, you know how quickly the conversation turns to boxes, lines, spans, and layers. Someone opens a slide deck, a few rectangles get shuffled around, and within minutes the room is deep in debate about reporting lines, titles, and who reports to whom. It feels productive, but it’s one of the fastest ways to trap an organization in a cycle of superficial change.

It’s also seductive to start talking about names and performance. Before long, the model starts taking shape around a handful of individuals instead of the work itself. Those discussions have their place, but when they dominate the design, it’s a clear signal that the effort is already on shaky ground. An operating model built around people instead of purpose will eventually collapse under its own weight.

An operating model is not an org chart. It’s the living system that connects strategy to execution. It defines how value is created, how decisions are made, how work flows across teams, and how people collaborate to deliver on the company’s purpose. When you reduce it to structure, you lose sight of the system that actually makes it run.

The issue isn’t carelessness – it’s that structure feels concrete. It’s easy to draw, easy to explain, and deceptively satisfying to rearrange. Capabilities, connections, and culture, on the other hand, are harder to see and even harder to map. So leaders jump straight to the “who,” skipping over the “what” and the “how.” But without those foundations, you’re building on sand.

The approach that follows is one I’ve used and refined across many organizations. It centers on four core elements—the 4 C’s: the what (capabilities), the how (connective tissue), and the who (colleagues). Over time, I’ve added two optional layers—the where (countries) and the wires (computing)—for organizations that operate globally or rely heavily on technology. And before any of it, there’s a crucial first step that too many skip: the why—the compass that points the entire design in the right direction.

1. The why: compass

Every operating model effort begins with purpose and direction. If you cannot clearly articulate why you are redesigning the operating model, you will never align people behind the change or make consistent decisions along the way. The why acts as the compass – it keeps you from drifting into endless debates about structure or scope because it centers everything on intent.

The compass clarifies purpose: what problem are you trying to solve, and what opportunity are you pursuing? It defines direction: are you optimizing for efficiency, cost, agility, geopolitical resilience, innovation, resilience, or growth? It could be any number of factors. It sets the design horizon: are you building a model for the next twelve months, or the next ten years? These answers frame every downstream choice you will make about capabilities, structure, and investment.

Without a compass, design becomes decoration. You can rearrange functions and refine workflows all day, but if the organization lacks a shared sense of direction, no amount of design will hold it together.

Establish your design principles

Once the compass is set, the next step is to establish a set of design principles that will serve as the organization’s guardrails. Design principles are not slogans. They are explicit, values-based statements about how you will make decisions. Think of them as the filters through which you pass your key decisions about the operating model direction. They help balance competing priorities – centralization versus local empowerment, innovation versus standardization, flexibility versus control.

Every organization’s design principles should reflect its culture and aspirations. A company that prizes innovation might commit to principles like “empower decision-making closest to the customer” or “design for speed over perfection.” A global firm balancing efficiency and responsiveness might anchor on “global standards, local flexibility.” A technology-driven company might assert that “technology follows process, not the other way around.”

The power of design principles is that they make implicit tradeoffs explicit. They turn subjective debates into structured choices. And, perhaps most importantly, they ensure that the operating model reflects the values and behaviors that actually make the company effective. When design principles are clear and consistently applied, the rest of the model almost designs itself.

2. The what: capabilities

Capabilities are the foundation of any operating model. They define what the organization must be able to do to execute its strategy. They are not functions or processes – they are enduring abilities that deliver value. For example, “customer analytics” or “strategic sourcing” or “cyber defense” are capabilities. They describe outcomes, not activities.

Defining the capability map forces clarity. It reveals whether the organization is structured around how it works today or how it needs to work tomorrow. It also gives you a common language that transcends silos. Instead of departments defending their territory, you have a shared view of what truly matters to the enterprise.

A strong capability map usually includes twenty to thirty key top-level capabilities, categorized by purpose: those that run the business (the core operational engine), those that grow the business (the expansion and innovation levers), and those that transform the business (the future-building capabilities). Assessing the maturity of each capability helps identify strengths, gaps, and investment priorities. You can have as many sub-capabilities as you like – even sub-SUB-capabilities – to establish a hierarchy of business capabilities, but your top-most level should be clean, clear, and MECE (mutually exclusive and collectively exhaustive).

Visually, these are often represented as “boxes,” but not in the organizational sense; they are simple boxes grouped together in a logical structure that define a single and complete capability. Internally, many organizations start with their business architecture document and consult the Enterprise Architecture team if one exists. If designing from scratch or aligning to an industry model, tools like APQC’s Process Classification Framework is an immensely helpful resource to speed things along.

This step is where strategy becomes concrete. It translates big ideas into tangible abilities. Once you know what capabilities you need, you can start to design how they connect and who will own them.

3. The how: connective tissue

The connective tissue is where most operating models succeed or fail. It represents the systems, processes, decision rights, data flows, and governance mechanisms that link capabilities together. If capabilities are the muscles of the organization, the connective tissue is the nervous system – the wiring that coordinates action.

When this connective tissue is weak, the organization slows down. Decisions bounce between functions, handoffs get lost, and data is trapped in silos. People spend more time managing friction than creating value. But when it is strong, the organization becomes coherent. Work flows smoothly, decisions are clear, and collaboration feels natural instead of forced.

Designing the connective tissue requires understanding how work actually gets done today. Map the real workflows, not the idealized ones. Look for bottlenecks, duplication, legacy alignments, and gray zones of accountability. Then design the future-state connections intentionally. Define decision-making forums that are fast and transparent. Clarify who owns what information. Align incentives so that collaboration is rewarded, not penalized.

The connective tissue often includes elements like shared services, governance bodies, operating rhythms, or digital platforms that enable seamless coordination. But the goal is not bureaucracy – it is clarity. The best connective tissue is lightweight and resilient. It should empower, not encumber.

4. The who: colleagues

Only after you have defined the capabilities and the connective tissue should you define the who – the structure, roles, and people. This is the visible part of the operating model, and the one that tends to dominate executive conversations. But without the what and the how (and of course, the why), the who is meaningless.

The who defines how people are organized around capabilities and connections. It is about aligning skills, decision rights, and accountability with the capabilities that drive value. It involves designing teams, leadership structures, and interfaces that support collaboration rather than competition.

The mistake most organizations make is treating structure as the design, when it should be the outcome of the design. Once you have clarity on what work must be done and how it flows, the right structure becomes obvious. You can then focus on talent, culture, and empowerment rather than endless debates about boxes on a page.

When you get the who right, it feels different. People know what they are accountable for. Decision-making accelerates. Teams collaborate across boundaries without losing focus. The organization feels lighter, not heavier.

The optional w’s: extending the model

In many contexts, the 4 C’s are sufficient. But in global, complex, or technology-driven organizations, two optional dimensions can make the model more robust: the where and the wires.

The where: countries

The “where” focuses on sourcing, shoring, and location strategy – where work is done and why. It recognizes that geography is both a cost and a capability lever. For some organizations, consolidating activities in lower-cost hubs creates efficiency and consistency. For others, proximity to customers or local regulatory expertise drives competitive advantage.

The key is to make location decisions after capability design, not before. You must know which capabilities need to be centralized for scale, which should be regionalized for relevance, and which must be localized for agility. The where is about matching talent and cost profiles to strategic needs, not about chasing the cheapest labor market.

The wires: computing

The “wires” represent the technology stack – the systems, data, and digital infrastructure that make the operating model work. In a modern enterprise, technology is the circulatory system that carries information, automates processes, and connects teams.

For technology-intensive or cybersecurity-oriented operating models, the wires are inseparable from the operating model itself. They determine what is possible, how fast decisions can be made, and how secure the enterprise can be. A clear view of the wires helps ensure that the technology strategy aligns with business capabilities and not the other way around.

A practical rule: design the operating model first, then design the technology that enables it. Technology should be a tool, not the tail that wags the dog.

The approach: building the model

Once the pieces are defined, the real work begins – turning design into action. The most effective way to do this is through an iterative, learning-oriented approach.

Start by grounding the effort in your compass and design principles. Make sure everyone understands why the redesign is happening and what values will guide the decisions. Then map the current state. Document how the organization truly operates today – the good, the bad, and the gray areas that rarely make it into process diagrams.

With that foundation, define the target state. Describe how the organization should operate to deliver on its strategy. This is not about perfection – it is about coherence. Once you have that north star, sequence the change. Begin with what you might call a “minimum viable operating model” – a set of immediate adjustments that deliver visible impact and momentum. Then evolve the model iteratively.

The best operating models are not designed once and frozen. They grow, adapt, and mature as the organization learns. Treat the model as a living system that needs tuning and feedback loops. The goal is not stability – it is agility and alignment.

Common pitfalls

Even the best-designed operating model efforts can derail if they fall into a few predictable traps. These mistakes are easy to make because they often feel rational in the moment, yet each one quietly pulls the organization away from meaningful progress.

Starting with the org chart

The most common pitfall is starting with structure. It feels tangible and satisfying to rearrange boxes and lines, but when structure comes first, the design inevitably centers on personalities instead of capabilities. The result is an organization optimized for comfort, not for strategy.

Designing for structure, not strategy

A polished diagram does not equal a purposeful design. When the focus is on hierarchy rather than business outcomes, you end up with an attractive operating model that accomplishes little. Every element of the design should serve a strategic objective, not just aesthetic balance or organizational neatness.

Confusing technology with transformation

Technology is an enabler, not a savior. New tools and platforms can accelerate change, but they cannot fix unclear decision rights, broken processes, or misaligned incentives. Without the right operating model, technology often automates dysfunction rather than solving it.

Overcomplicating governance

In pursuit of control, organizations frequently overengineer governance. Layers of committees, councils, and review boards multiply until nobody knows who decides what. True governance should streamline decisions, increase accountability, and build trust – not drown people in bureaucracy.

Ignoring culture

Culture is the invisible gravity of any organization. You can design perfect processes and clever structures, but if they clash with how people actually behave, they will never take root. An operating model only works when it reinforces – and is reinforced by – the culture that powers it.

Striving for perfection

Many redesigns stall because teams chase the illusion of the perfect model. They workshop endlessly, refining slides instead of testing ideas in the real world. Operating models should evolve through learning and iteration, not freeze in pursuit of flawless theory.

Confusing current and future state

Another trap is blurring what is with what should be. Teams start mapping today’s organization while trying to design tomorrow’s, and the two blend into a confusing middle ground. Clarity requires separating diagnostic work from design – understand the current state fully, then design the future state deliberately.

PowerPoint ≠ implementation

Finally, a design on paper means nothing until it comes to life in practice. Too many operating model efforts end when the deck is finalized, not when the organization changes. Implementation is where the real work begins – translating elegant diagrams into new ways of working, leading, and deciding.Avoiding these pitfalls does not guarantee success, but it dramatically increases your odds. The organizations that get this right understand that operating models are not one-time projects. They are systems that must be implemented, tested, refined, and sustained over time – which is where the real challenge begins.

Implementing and sustaining the system, not the structure

Designing an operating model is only the beginning. The real test starts when the slides end and the work begins. Implementation is where theory collides with reality – where elegant designs meet messy human behavior, competing priorities, and legacy systems. Bringing an operating model to life requires discipline, leadership, and patience in equal measure.

The first step in implementation is alignment. Everyone who touches the system – from executives to frontline managers – must understand not just what is changing, but why it matters. This is where the compass and design principles earn their keep. They provide the language and logic to make consistent choices, even when the path forward is unclear. Without that shared foundation, every decision turns into a negotiation.

Next comes activation. Translating design into practice means building new habits, not just new org charts. Decision rights must be clarified, performance metrics must align to the new capabilities, and leaders must model the behaviors the system depends on. You cannot “roll out” a new operating model like a software update. It takes time for teams to unlearn the old ways of working and adopt the new ones. Progress happens through repetition, reinforcement, and feedback.

Sustaining the model is an ongoing discipline. Organizations evolve, strategies shift, markets move, and technology advances. The operating model must adapt with them. That means creating a simple but deliberate cadence for review and adjustment – a governance rhythm that keeps the model alive and relevant. Treat it as a living system that learns, rather than a fixed design to defend.

When the system is healthy, structure becomes almost self-correcting. Teams know how to flex, leaders know how to decide, and capabilities evolve naturally as the organization grows. But when the focus drifts back to structure alone, rigidity creeps in and the system begins to decay.

The truth is that operating models fail not because they are designed poorly, but because they are not maintained. Coherence requires constant attention – to the relationships, decision flows, and culture that make the system work. When leaders stay focused on those, the organization stops reacting and starts performing with intention.

An operating model that works is not a diagram. It is a discipline. When you build it from the inside out – from why to what to how to who – and keep it alive through continuous learning and alignment, you create more than a structure. You create a system that endures.