New here? Start here.

The engineering operating model explained.

This page explains the problem this site exists to solve, introduces the BVSSH operating model, and shows you how everything connects. Read this first - then explore the system in the order that's most relevant to where you are.

01

The problem most engineering organisations have

Most engineering organisations get better at producing output. They don't consistently get better at producing outcomes. There's a difference - and it compounds over time.

The teams that ship most frequently are usually not the ones with the most engineers, the most process, or the most governance. They're the ones that have built a coherent operating model - a system in which culture, practice, architecture, and measurement all reinforce each other.

Releases are slow and risky
…because integration, testing, and deployment are manual and infrequent
Engineering feels like a bottleneck
…because work piles up at handoff points instead of flowing end to end
Incidents keep recurring
…because organisations optimise for recovery rather than learning
Talented engineers leave
…because toil, poor tooling, and unclear purpose make the work unrewarding
Metrics mislead
…because velocity and story points measure effort, not progress
02

The BVSSH operating model

BVSSH - Better Value Sooner Safer Happier - is the outcome lens this entire site is built around. It comes from Jonathan Smart's work and the research that underpins it is robust: the organisations that excel at all five outcomes outperform those that optimise for one or two at the expense of others.

These aren't aspirational values. They're measurable outcomes - and every policy, standard, practice, and playbook on this site exists to move the needle on at least one of them.

Explore the full BVSSH framework
B
Better

Quality built in - not inspected in. Sustainable technical health, reduced defect rates, codebases designed to change. Better is the outcome of treating engineering excellence as a first-class concern, not a nice-to-have.

V
Value

Work that connects to outcomes customers and the business actually care about. Value is delivered when what gets built solves the right problem - not just when the ticket moves to done.

S
Sooner

Frequent, small, safe releases driven by short feedback loops. Sooner is made possible by trunk-based development, CI/CD, and deployment pipelines that make releasing a non-event.

S
Safer

Reliable, observable, secure systems. Safety means being able to detect problems fast, recover quickly, and deliver change without fear. It is not about slowing down - it is about building the confidence to speed up.

H
Happier

Developer experience, psychological safety, and a culture of learning. Happier teams stay longer, perform better, and produce higher-quality work. This is not a soft outcome - it is a leading indicator of everything else.

03

How the system is organised

The site is structured around four interconnected components. Each is useful in isolation. Together they form a complete picture of what an engineering organisation needs to build, measure, and sustain high performance.

BVSSH

The outcome framework. Five outcomes that define what high performance looks like - and the lens through which every standard and practice is evaluated.

Explore BVSSH →

Centre of Excellence

Eight engineering domains - each with policies, standards, practices, and measures. This is the operational layer: what teams should do, how to know they're doing it well, and how to get better.

Explore the C4E →

Playbooks

Opinionated, practical guides for the practices that matter most. Each playbook covers the what, the why, the how, and the measures of success - at five levels of maturity.

Read the playbooks →

Frameworks & Evidence

DORA, DevEx, DevOps capability mapping, and engineering strategy. The research base that underpins the operating model - so recommendations are evidence-led, not opinion-led.

Explore frameworks →

Where to go next

Depending on where you are and what you need, the path through the site is different. Here are the most common starting points.

🎯
If you're a CTO or VP

Start with the Engineering Strategy page and the BVSSH framework. Then use the C4E to assess where your domains are strongest and weakest.

Engineering Strategy →
🔧
If you're a Head of Engineering

Go directly to the Centre of Excellence. Pick the domain most relevant to your current challenge and work through the standards and practices.

Centre of Excellence →
📋
If you're running a transformation

Start with the Playbooks - particularly Measuring Engineering Outcomes, Observability, and Trunk-Based Development. Then use the DevOps Capability Framework.

Playbooks →
📚
If you want the research base

Go to Frameworks. DORA, DevEx, and SPACE give you the evidence behind the practices. Use these to build the case for change.

Frameworks →

Want help applying this in your organisation?

The model works. But applying it inside a real organisation - with its politics, history, and constraints - is a different challenge. That's what I help with.