The Cloud Operating Model, on a 2×2

Strategy reviews lose people the moment we say operating model. The phrase sounds like consulting jargon. So I draw a 2×2. The two axes — who controls the platform, and who pays for what they consume — are enough to explain why most cloud transformations either work in twelve months or quietly miss their second anniversary. The grid is not a substitute for an operating model document; it is the conversation that has to happen before the document is written. In our work with Bangladeshi BFSI, telco, and large manufacturing customers, the grid has correctly predicted programme trajectory in roughly eight out of ten cases.

The grid

Why chargeback is the y-axis

Showback is consumed carelessly. A real BDT invoice creates the feedback loop that forces every other decision in the right direction — right-sizing, environment teardown, vendor consolidation, IdP federation. Without that loop, the platform team becomes a cost centre and every BU has the incentive to fork. We have watched programmes where the only structural change between the failing year and the working year was that someone in finance finally agreed to issue real BDT invoices to the business units; within two quarters, environment counts dropped by a third, idle resources collapsed, and the architecture review board had a queue rather than a backlog. The decision is administrative. The consequence is cultural.

Why platform control is the x-axis

Centralisation reduces variance and increases queue. Decentralisation increases variance and reduces queue. Neither is wrong; both produce predictable failure modes. The art is choosing the queue you can live with. A small mid-sized organisation can absorb a centralised queue because the total work is bounded. A large multi-business-unit enterprise cannot — the queue becomes a political bottleneck within eighteen months and BUs start forking platforms in self-defence. The federated paved-road pattern, popularised by Spotify and formalised by Team Topologies, exists precisely to handle the second case.

What sits behind the grid

Where I see Bangladeshi enterprises actually land

Tier-1 banks gravitate to Q1 (federated paved-road) under regulatory pressure to demonstrate centralised governance with measurable BU accountability. The combination satisfies both the audit committee — which wants a single throat to choke for cloud risk — and the BU heads, who want to ship without queueing behind every other BU’s change request. Mid-sized digital-natives lean Q4 first because a small team can run everything; they migrate to Q1 around two-hundred engineers, when the queue starts hurting delivery velocity. Public-sector estates are Q3 by default until a budget shock forces a move; once chargeback gets installed, the rest of the move to Q1 follows within a year. Q2 is rare and never deliberate — it appears when chargeback is enforced before a platform team exists, and it is operationally the worst place to be.

What signals a good outcome

Three early signals predict programme success regardless of starting quadrant. First, the executive sponsor can answer the chargeback question in one sentence. Second, the platform team has shipped a paved-road template that at least one BU has adopted voluntarily. Third, the architecture review board has at least one explicit no on its record — evidence that governance has teeth. Programmes missing any one of these three signals are still recoverable; programmes missing all three are not.