Transformation Operating Model: Decision Rights, Teams, Portfolio Cadence

A transformation operating model defines who decides what, how teams are formed and at what cadence budget is allocated — this is the layer where transformation programs actually lose speed.

Definition

Transformation Operating Model: Decision Rights, Teams, Portfolio Cadence: A transformation operating model defines who decides what, how teams are formed and at what cadence budget is allocated — this is the layer where transformation programs actually lose speed.

Decision rights: written thresholds

The single highest-return move in operating model design is writing decision rights with thresholds. An example frame:

Decision	Stays with team	Steering committee	Board
Backlog ordering	✅ Always	—	—
Technology/library choice	✅ Within approved list	If outside the list	—
Removing a process step	If impact is single-department	If cross-department	—
Launching a new initiative	—	✅ In quarterly portfolio	Above budget threshold
Stopping an initiative	✅ If data shows it	Informed	—
Raising AI autonomy level	—	✅ With eval record	If it involves financial actions

More important than the table itself is the second-to-last row: the authority to stop an initiative sitting with the team. In organizations where stopping authority sits above, nothing ever stops; the portfolio inflates, resources scatter and no initiative receives enough of them.

Team structure: product, not project

Project-based team structure is transformation's silent cost. When the project ends the team disbands; ownership of the system becomes unclear, lessons leave with the people, and the next initiative climbs the same learning curve from scratch.

A product-oriented persistent team has three properties:

Continuity — the team owns a process/product area; the work does not end, the backlog continues.
End-to-end responsibility — the same team owns design through production operations ("build it, run it").
Business-metric ownership — the team's success is measured by the metric it owns, not by features delivered.

The hardest part of this transition is not resource allocation but performance management: evaluating a team on a metric requires a different management practice from evaluating individual output, and it forces the HR system to change too. This is why operating model change is not an org-chart refresh but a rewrite of the incentive system.

Portfolio cadence and the correct role of a CoE

A quarterly portfolio cadence does three things: reallocates budget every quarter, demands evidence from every initiative at quarter end, and closes the ones that produce none. None of the three is possible on an annual budget cycle; an opportunity that appears mid-year is written into next year's plan and usually goes stale.

A Center of Excellence (CoE) is the most frequently mispositioned structure in transformation and AI programs. The wrong role: an approval gate every initiative must pass. In that setup the CoE inevitably becomes a bottleneck and business units look for ways around it (shadow projects). The correct role has three parts:

Producing templates and standards — reference architecture, eval-set template, model-card format, procurement clauses.
Operating shared infrastructure — eval execution environment, logging/observability, access governance.
Supplying talent — experts embedded in the business unit; in the field, not in the CoE.

The measure is simple: a CoE's success is judged not by how many projects it delivers but by how often business units can do the right thing without needing the CoE.

Key Takeaways

The operating model is the one transformation component that cannot be purchased; technology, data and talent can be sourced, decision rights cannot.
If decision rights are not written down, every friction escalates upward; the source of lost speed is the approval queue, not model quality.
Project teams disband, product teams persist — the latter is what carries organizational learning.
When a CoE becomes an approval authority it becomes a bottleneck; its correct role is providing templates, eval infrastructure and talent.

Tools that work with this framework

Use-Case Prioritization

Quantitative scoring on business value × feasibility — the first draft of the initiative portfolio.

Frequently Asked Questions

Is a transformation office necessary?▾

A small core to run the portfolio cadence and track decision rights is useful (2–4 people). It stops being useful when the office starts executing initiatives itself; from that point it behaves like a business unit and can no longer make neutral portfolio decisions.

Is a decision-rights matrix the same as RACI?▾

No. RACI defines who is responsible/consulted on a task; a decision-rights matrix defines *which decision stays with whom at which threshold*. The difference matters in practice: RACI organizes escalation, decision rights make escalation unnecessary.

How large must a team be to move to a product structure?▾

The smallest structure that can carry end-to-end responsibility is in practice 5–9 people: a product owner, 2–4 engineers, data/analytics, and a domain expert from the process side. Smaller teams slow down on dependencies, larger ones on coordination cost.

Does AI need a separate operating model?▾

Not a separate model but three additions to the existing one: where the autonomy-level decision is made, who accepts eval results, and who defines human approval points. Building a parallel 'AI operating model' creates a two-speed organization and generates integration debt.

Other frameworks

Let us locate your organization's rung together

A diagnosis of the current state, the bottleneck in your weakest dimension and three concrete actions for the coming quarter — we can start with one conversation.

Get in Touch All of Transformation