Operating-model design

How work, decisions and accountability are arranged once the technology changes.

What is it?

When systems and processes change, the structure around them usually needs to change too. This covers how teams are organised, who decides what, which capabilities are kept in-house, and how the parts coordinate. Often the difference between a programme that sticks and one that quietly reverts.

For a technical reader

The useful artefacts are a capability map, a decision-rights matrix, and an explicit sourcing position per capability. Team topology matters because the interfaces between teams become the interfaces in the system — organisations tend to ship their communication structure. Where delivery is chronically slow, the cause is usually ambiguous decision rights or a handoff between teams with misaligned incentives, both of which are structural rather than effort problems.

Our services

Capability mappingWhat the organisation must be able to do, assessed independently of the current structure.
Team and structure designHow teams are grouped and what the interfaces between them are.
Decision rights frameworkWho decides what, documented, so escalation stops being the default.
Transition planningSequencing and communication, because moving to a new model is itself a change programme.

What’s covered

Capability mapping
What the organisation must be able to do, independent of current structure
Team topology
How teams are grouped, and the interfaces between them
Decision rights
Who decides, who is consulted, who is informed, written down
Build, buy or partner
Which capabilities are core enough to own and which are better sourced
Governance cadence
The meetings, inputs and decisions that keep the model running

Business problems we solve

Everything escalatesAmbiguous decision rights. Making them explicit is usually the single highest-value change.
Delivery is slow despite enough peopleHandoffs and queues between teams, not individual effort. Structure is the lever.
We cannot tell what to keep in-houseAn explicit sourcing position per capability replaces case-by-case improvisation.
The last reorganisation changed nothingBecause it moved boxes without changing decision rights or interfaces.

Our delivery approach

  1. 01
    Start from the workWhat has to get done, at what volume and speed. Structure follows from that rather than from an org chart preference.
  2. 02
    Make decision rights explicitWho decides, who is consulted, who is informed. Ambiguity here is where delivery slows down.
  3. 03
    Decide what stays in-houseCapabilities core to your advantage are built internally. The rest can be partnered. That line is a deliberate choice.
  4. 04
    Plan the transitionMoving to a new model is a change programme in itself, with sequencing and communication, not a reorganisation announcement.

Solutions & project types

Examples of the work we take on in this area. These describe project shapes, not named client engagements.

Technology operating modelRestructuring delivery around products and platforms rather than projects.
Post-implementation modelDefining how a function runs after a major system change.
Shared services designWhat centralises, what stays local, and the service levels between them.
Sourcing strategyA deliberate in-house versus partnered split per capability.

Technologies & platforms

Methods

  • Capability mapping
  • Team Topologies
  • Value stream mapping
  • RACI / decision rights

Governance

  • Operating cadence design
  • Portfolio governance
  • Service level agreements

Assessment

  • Capability maturity assessment
  • Flow and lead-time analysis

Change

  • Stakeholder mapping
  • Communication planning
  • Role transition design
Learn this field

Where to start with operating-model design.

Secondary to the work itself, but genuinely useful if you are building the skill. Every link goes to official documentation or an official channel.

Beginner

  • What an operating model actually contains
  • Capability versus process versus function
  • Reading an organisation chart critically
  • Conway's law and its practical consequences

Intermediate

  • Team Topologies: the four team types and three interaction modes
  • Value stream mapping and queue analysis
  • Decision rights frameworks
  • Service level design between internal teams

Advanced

  • Operating model design for multi-business-unit organisations
  • Sourcing strategy and capability retention
  • Measuring flow efficiency across a portfolio
  • Sequencing a structural transition without stalling delivery

Certifications

  • Prosci Change Management Certification
  • TOGAF Enterprise Architecture Certification
  • Certified Scaled Agile (SAFe) Program Consultant

Practice projects

  • Map your capabilities and mark which are genuinely differentiating
  • Write a decision-rights matrix for one recurring decision type
  • Value-stream map one delivery and measure wait time versus work time
  • Classify your teams using Team Topologies and name the interaction modes
  • Draft a sourcing position for each capability and defend it
FAQs

Questions we get asked.

Is this just a reorganisation?

No, and reorganisations that only move boxes are exactly what this is meant to avoid. The substance is decision rights, interfaces and sourcing.

How long does it take to see an effect?

Decision-rights clarity can change things within weeks. Structural change takes longer and should be sequenced so delivery continues throughout.

Do you recommend a specific framework?

No. Frameworks are useful vocabulary and poor substitutes for designing around your actual work. We borrow from several and commit to none.

What if leadership disagrees on the target?

Then that is the work. Surfacing and resolving the disagreement is more valuable than producing a document that papers over it.

Start the conversation

Talk to our experts about operating-model design.

Tell us where you are. A specialist will read it and reply within one business day.