MR cxo.riera.co.uk / strategy
cxo.riera.co.uk

Technical organisations should work like well-designed systems, not collections of heroic exceptions.

Posture

The strategy and operating-model lens on the same practice. Service design, decision rights, technical bets that hold up under pressure, and the conditions in which engineering teams produce durable work.

ProgrammeCambridge Judge · CTO · 2024–2025
ProgrammeOxford Executive Finance · 2025–2026
CertificationsITIL 4 DPI · PRINCE2 Agile
MemberBCS, the Chartered Institute for IT
§ 01 · Shifts

What changes as scope widens.

01

Local optimisation → portfolio judgement

The work stops being about choosing the right tool and becomes about choosing the right set of trade-offs across a system of commitments.

02

Tool choice → service design

Technology decisions only matter inasmuch as they produce a service that teams can actually run, and that users can actually rely on.

03

Control → context design

Leadership at scale is less about ownership of individual decisions and more about shaping the environment in which those decisions are made.

04

Heroics → repeatable systems

Anything that depends on one exceptional person failing to sleep is, on any horizon that matters, a bug in the operating model.

§ 02 · Operating practices

A small set of practices, repeatedly applied.

Four practices

A weekly operating rhythm with short standing meetings for delivery, incident, and roadmap signals. Written before it is spoken, so the conversation is decision-making rather than information transfer.

Service maps that name owners, escalation paths, and dependencies, reviewed every quarter. When a system is hard to draw, that is the first warning that it is also hard to run.

Technical strategy written as a short document that names the bets, the trade-offs, and the invariants — the things we will not change even under pressure. Short enough that every engineer has read it.

Operating quality reviewed the way product quality is reviewed: on-call load, deployment friction, incident patterns, onboarding time. When these numbers drift, the system is telling you something before people notice.

§ 03 · Operating model

The five layers I return to under pressure.

Layer 01

Strategy

Short, written, contested. Names three to five bets with explicit trade-offs. Revised once a year, not once a quarter.

Layer 02

Architecture

The service map and the dependency map. The question it answers: what do we run, who owns it, what fails when it fails.

Layer 03

Delivery

A weekly rhythm, written ahead, with decisions recorded where future engineers can find them. Standing meetings are the exception, not the baseline.

Layer 04

Operations

Observability, on-call, incident review, and the quiet discipline of SLOs. Operating quality reviewed like product quality, with data.

Layer 05

Talent

Hiring, growth frameworks, levelling. The boring part that, done well, makes the other four layers work themselves.

Posture

Invariants

Three or four things we will not change even under pressure. A small, durable list — the part of the practice that outlives any particular strategy.