Organisational Design for Strategy & OKR Progress Velocity

We’ll explore:

• Why functional structures create bottlenecks at scale

• How to organise around value streams rather than functions

• When teams should collaborate versus work independently

• How to manage cognitive load so teams can focus

• What organisational transformation actually requires

Let’s start with the framework that has reshaped how modern organisations structure teams for speed.

Team Topologies: Structure for Fast Flow

Skelton and Pais argue that most organisational problems stem from having the wrong team types or unclear team interactions.

Their framework identifies four foundational team types required for the fast flow of value to customers.

1. Stream-Aligned Teams

These teams are aligned to a flow of work from a customer or user perspective, organised around a product, service, customer journey, or persona.

They have end-to-end accountability for the value stream and can deliver value without constant cross-team coordination.

In practice, this is the team type most organisations need more of, because it creates autonomy with accountability.

2. Platform Teams

Platform teams provide internal services that reduce cognitive load for stream-aligned teams.

Instead of every team building its own infrastructure (authentication, payments, data tooling), platform teams create shared services that others consume.

The platform goal is not control. It’s enabling autonomy.

3. Enabling Teams

Enabling teams are specialists who work temporarily with stream-aligned teams to help them overcome obstacles and build new capabilities.

They coach, transfer knowledge, and remove barriers, rather than becoming permanent dependency factories.

4. Complicated-Subsystem Teams

Some domains are too complex to embed inside stream-aligned teams without overwhelming them.

Complicated-subsystem teams own these specialised areas (e.g., algorithms, modelling, complex integrations) so stream-aligned teams can consume them simply.

Conway’s Law and the Reverse Conway Manoeuvre

Skelton and Pais build on Conway’s Law: organisational communication structures tend to shape system architecture.

In simpler terms: your product architecture mirrors your org structure.

So if you want to change what you can build, you often need to change how teams are structured.

They call this the “reverse Conway manoeuvre”: intentionally design teams to match the architecture and customer flows you want.

For organisations using OKRs, the implication is immediate:

If your strategic OKRs require cross-functional capabilities, but your teams are organised by function, you are fighting your structure. Every OKR becomes a coordination problem.

Team Interaction Modes: Stop Defaulting to Collaboration

Skelton and Pais also make a critical point that most organisations ignore:

Teams should not collaborate by default. Collaboration has a high coordination cost.

They identify three interaction modes:

Collaboration Mode

High-touch working together for discovery and rapid learning. Valuable when uncertainty is high, but expensive, and not sustainable as the default.

X-as-a-Service Mode

Low-touch consumption of a service with minimal coordination. This should be the dominant mode once approaches are understood (platform teams typically work this way).

Facilitating Mode

An enabling team helps another team build capability and remove obstacles. Temporary, focused, knowledge-transfer oriented.

Most organisations overuse collaboration mode, and then wonder why they have meeting overload and stalled execution.

Cognitive Load: The Invisible Constraint on Execution

Skelton and Pais emphasise that teams have limited cognitive capacity and introduce three types of cognitive load:

• Intrinsic load: the complexity of the domain

• Extraneous load: friction from environment (unclear processes, bad tooling, excessive meetings)

• Germane load: the valuable effort of learning and problem-solving

Most organisations overwhelm teams with extraneous load, leaving little capacity for the germane work where value is created.

Their practical recommendation: limit the scope of stream-aligned teams to 2–3 domains maximum. Beyond that, cognitive overload rises, and quality suffers.

For CEOs executing strategy with OKRs, this becomes a forcing function:

If you have five strategic priorities, you likely need 3–5 stream-aligned teams with enough cognitive capacity to execute them. Layering strategic OKRs onto teams already drowning in operational domains creates overload, something we see often at ZOKRI.

Skelton and Pais call for “organisational sensing”: continuously monitoring whether structure and interaction modes are enabling or blocking fast flow. The signals are concrete:

• Deployment lead time

• Dependency wait time

• Blockers caused by other teams

• Coordination and meeting load

• Cognitive overload and burnout

When those signals degrade, the solution is rarely “communicate more.” It’s usually structural.

Galbraith’s Star Model: The Full System of Organisational Design

Team Topologies helps define team structure and interaction. But CEOs also need a systematic framework for the broader design choices that make reorganisations stick.

That’s what Jay Galbraith’s Star Model provides.

Galbraith identifies five interconnected elements that must align:

1. Strategy

Where to play and how to win. Strategy is the cornerstone: structure follows strategy.

2. Structure

Reporting relationships, spans of control, layers, and how authority is distributed.

3. Processes

The planning, information, and decision flows that cut across structure, especially cross-functional coordination mechanisms.

4. Rewards

What gets reinforced: compensation, promotion, recognition, and incentives that shape behaviour.

5. People

Hiring profiles, development systems, performance standards, succession planning.

Galbraith’s core insight: organisational dysfunction almost always stems from misalignment across these elements.

Change the structure without changing the rewards, and people will keep optimising for the old game.
Introduce OKRs as a process without changing decision rights, and OKRs become performative.
Create value-stream teams while maintaining functional incentives, and silos re-form inside the new chart.

Galbraith also reframes structure as a question of power:

• Who decides?

• Who controls resources?

• Which priorities win when conflicts arise?

For growth-mandate CEOs, that’s the real battle: if decision rights remain with functional leaders, cross-functional strategic work gets deprioritised as soon as it conflicts with functional targets.

Lencioni: Why Silos Persist and What Breaks Them

Even well-designed structures can drift into silos.

Patrick Lencioni’s work challenges a common misconception: silos don’t persist because people are inherently political.

They persist because leaders optimise for departmental goals instead of the company’s goal.

Each functional leader is rational:

• Engineering optimises for stability and quality

• Sales optimises for revenue and speed

• Product optimises for adoption and satisfaction

The problem is not the goals. It’s the absence of an overarching shared priority that forces coordination when goals conflict.

Lencioni’s solution is the thematic goal: a single, qualitative, temporary top priority that sits above functional objectives and requires all functions to cooperate.

It works because it is:

• Temporary (creates urgency)

• Qualitative (allows flexibility)

• Shared (forces coordination)

And it cannot be solved through communication alone. Silos break when leaders have shared work, shared accountability, and shared outcomes.

For organisations using strategic OKRs, this is a direct alignment: the most important strategic OKRs should function as thematic goals, forcing trade-offs and coordination.

Gardner: Smart Collaboration, Not Maximum Collaboration

Collaboration can create enormous value, and destroy it just as quickly.

Heidi Gardner’s research explains why: collaboration pays off only under specific conditions.

Collaboration is worth the cost when:

• Complexity is high and no single team has the full answer

• Customer needs are multifaceted and require integrated solutions

• Knowledge integration creates unique value

• Relationships built today accelerate future work

But indiscriminate collaboration creates predictable failure modes:

• Decision delays

• Diluted accountability

• Coordination overhead

• Burnout from constant cross-boundary work

Often, high performers become bottlenecks because they’re pulled into every collaborative effort.

Gardner’s practical guidance is simple and hard:

• Default to independent work

• Trigger collaboration explicitly when conditions justify it

• Design collaboration with clear goals, roles, and time boundaries

• Rotate collaboration responsibilities

• Make collaboration overhead visible and measurable

This maps cleanly to Skelton and Pais: use collaboration when uncertainty is high, then shift to X-as-a-Service or facilitation once learning stabilises.

Dignan: Upgrade the Operating System, Not Just the Org Chart

Aaron Dignan pushes the conversation deeper.

Most companies are still running a legacy organisational operating system designed for:

• Stable markets

• Predictable competition

• Top-down control

• Efficiency optimisation

That OS fails in today’s environment where growth requires:

• Speed

• Adaptation

• Innovation

• Distributed decision-making

Dignan frames organisations as a set of “loops” that define how they operate:

• Purpose

• Authority

• Structure

• Strategy

• Resources

His warning: reorganisations fail when they are imposed top-down without participation, sensing, and iteration. The change doesn’t stick.

For growth-mandate CEOs, this creates a tension: you need speed, but imposed change creates resistance. Dignan’s approach favours:

• Experiments

• Early adopters

• Safe-to-fail trials

• Scaling what works

He also advocates principles over policies: principles guide judgment in dynamic environments; policies create rigid rules that break under change.

Connected Strategy: Connected Customer Experiences Require Connected Structures

Siggelkow and Terwiesch show that digital technology enables “connected strategies”—continuous customer relationships rather than episodic transactions.

Connected strategies fail when organisations maintain silos between:

• Customer-facing teams (sales/marketing)

• Operational teams (delivery/service/fulfilment)

Those handoffs create breakpoints that destroy the seamless connected experience.

Their conclusion is structural: teams must organise around customer journeys with end-to-end accountability, supported by rapid feedback loops. Data, product, and operations must be tightly integrated so customer signals translate into rapid improvements.

This is another reinforcement of the same theme: if your strategy is connected, your structure must be connected too.

Cagan: Empowered Teams and Outcome Accountability in Product Companies

Marty Cagan’s work explains why many “product transformations” fail.

Most organisations operate like project factories:

• Stakeholders request features

• Teams build features

• Outcomes disappoint

• Repeat

True product companies organise around empowered teams that solve customer problems and achieve business outcomes.

The model requires:

• Stable, dedicated teams (not temporary project squads)

• Outcome accountability (not output targets)

• Customer access and authority for discovery

• Technical capability to build, deploy, and measure independently

Cagan’s key warning mirrors Galbraith: partial transformations fail. Changing structure without changing authority, measurement, and leadership behaviour creates cynicism.

Empowerment does not mean chaos. Teams are empowered within strategic boundaries—defined by product strategy and outcomes. This connects directly to OKRs: strategic OKRs define outcomes; empowered teams provide the velocity and innovation to achieve them.

Where the Experts Converge

Across these frameworks, the common patterns are consistent:

• Organise around value streams, not internal functions

• Create stream-aligned teams with end-to-end accountability

• Manage cognitive load: teams should own 2–3 domains max

• Use collaboration selectively; default to low-overhead interaction modes

• Treat organisational design as a system: align processes, rewards, people, and leadership behaviours—not just the chart

• If your strategy depends on connected customer journeys, your structure must enable connected execution

Your Next Steps

If you want to make this actionable immediately, start with five moves:

1. Audit Structure vs. Strategy

Do your strategic OKRs require cross-functional execution while your org is designed functionally? If yes, you have structural misalignment.

2. Identify the Value Streams That Matter Most

Map the customer journeys and value streams that drive growth. These should connect directly to your strategic priorities.

3. Design Stream-Aligned Accountability

Where appropriate, create stream-aligned teams with end-to-end accountability for outcomes, supported by platform and enabling capabilities.

4. Assess Cognitive Load

Are teams trying to manage too many domains while also executing strategic OKRs? If yes, you need either more focused teams or fewer strategic priorities.

5. Diagnose Interaction Modes

Are teams collaborating on everything when X-as-a-Service would work better? Is collaboration overhead killing velocity? Make the coordination cost visible—and redesign how teams interact.

The Question That Determines Whether Growth Restarts

These experts ultimately pose one foundational question:

Is your organisational structure designed for the strategy you need to execute now—or for the strategy you executed five years ago?

Most companies trying to speed up growth discover that their structure is the constraint.

The work is difficult. That’s why organisations avoid it. But incremental improvements to broken structures won’t restart growth.

Sometimes you need a fundamental redesign, toward value streams, clear decision rights, managed cognitive load, and operating-system-level upgrades that make execution fast, aligned, and sustainable.