Building Quality In: A Framework for Engineering Teams

Quality is easy to recognise and surprisingly hard to explain. In software, that often means we only talk about it when something goes wrong: incidents, defects, rework, and disappointed users. Deming’s warning still holds: “Quality cannot be inspected into a product or service; it must be built into it.”

In this talk, I’ll begin with three cautionary tales from outside tech (Boeing 737 MAX, Peanut Corporation of America, and Volkswagen Dieselgate) to show a pattern: major quality failures are rarely just “a testing problem” or “a process problem”. They are systems problems, shaped by how people work, what they prioritise, and what they’re rewarded for.

Using Google’s research into how engineers think about software quality, I’ll introduce a framework that breaks quality down into process, code, system, and product quality, and I’ll add the missing foundation that holds it together: people quality. We’ll translate “quality” into concrete, stakeholder-valued attributes, then connect those attributes to the artefacts teams already use, so quality becomes part of delivery rather than a last-minute scramble.

What will attendees learn?:

• A practical definition of quality: stakeholder-valued attributes you can use to guide decisions.
• A five-part framework to locate where quality risks really live (and what to do next).
• A repeatable workshop approach to embed quality into team charters, ways of working, definitions of done, and product health metrics.