Body of work

Quality Engineering

Quality Engineering is the discipline of designing an organisation that can change its software quickly without losing control of it. It is a systems question long before it is a testing question.

Testing asks whether a change is correct.

Quality Engineering asks what the system must look like for correctness to be established continuously, cheaply, and at the speed the business needs.

Quality Engineering
and digital innovation.

Digital innovation is limited less by ideas than by the cost of validating them. Every hypothesis has to travel through a production system: build, verify, release, observe, decide. Where that path is slow or unreliable, organisations respond by shipping less often and deciding more slowly — which is experienced as a lack of innovation, though its cause is a lack of verified flow.

This is why Quality Engineering belongs in executive conversations. It determines how many validated experiments an organisation can run per quarter, and therefore how much of its technology investment converts into learning.

Principles

01

Quality is a property of the system

It is produced by architecture, feedback loops and decision rights — not inspected in at the end by a separate team.

02

Verification sets the pace

An organisation can only release as fast as it can establish that a change is safe. Verification capacity, not coding capacity, governs throughput.

03

Feedback before coverage

The value of a test lies in the speed and precision of the signal it returns, not in the percentage it reports.

04

Quality at Speed

Speed and quality trade off only when the system is badly designed. Reduce batch size, shorten loops, move checks closer to the decision.

05

Risk is the unit of prioritisation

Effort follows consequence: what breaks, for whom, and how visibly — not what is easiest to automate.

06

Governance is engineered, not documented

Controls that live in pipelines and platforms hold. Controls that live in slide decks decay.

Where quality is decided

01Product & requirement clarity

Ambiguity upstream becomes defects downstream.

02Architecture & testability

Boundaries, contracts and observability decide what can be verified cheaply.

03Automation & environments

Reproducible environments and reliable suites turn verification into a utility.

04Continuous delivery

Small, frequent, reversible change is the strongest quality mechanism available.

05Observability & operations

Production is the final test environment; what you can see there sets your real risk.

06Organisation & accountability

Ownership, incentives and skills determine whether the rest survives contact with delivery.

The agentic
turn.

As coding agents join the workforce, the scarce resource stops being the production of code and becomes the organisation's ability to absorb it. The constraint migrates to verification, integration, environments, observability and governance — which is to say, it migrates into Quality Engineering.

Read alongside AI Engineering Transformation, this is the same argument seen from the other side: the measure that matters is validated business value per unit of human intervention.

Longer treatments live in Quality Engineering (with Rémi Dewitte) and in the Ideas archive, which now holds the Quality Engineering writing previously published at QE Unit.

Discuss a quality system