The short answer
Quality is an operating model because every function makes choices that shape customer risk. Product defines what ‘correct’ means, engineering designs for change, security reduces avoidable exposure, delivery controls release risk, operations makes failure visible, and leadership decides which trade-offs the company will accept.
Key takeaways
- Define quality as customer confidence, not defect count.
- Move prevention and observability earlier while keeping independent challenge where risk warrants it.
- Use service objectives and error budgets to make reliability trade-offs explicit.
- Treat every incident as product and operating-model feedback, not only a technical event.
Quality starts before a requirement exists
Many expensive failures begin as ambiguity. The customer problem is underspecified, an operating assumption is invisible, or a non-functional requirement appears late. A strong quality model begins in discovery by identifying critical user journeys, failure consequences, environmental constraints, data obligations, and the evidence that will demonstrate success.
This does not mean writing exhaustive specifications. It means making risk discussable. A workflow used in a control room deserves different evidence from an administrative convenience. The quality approach should follow the consequence of failure, not apply the same ceremony to every change.
Design three connected lines: prevention, detection, learning
Prevention includes clear acceptance boundaries, architecture that contains failure, secure development practices, automated checks, and small reversible changes. Detection includes telemetry, synthetic checks, customer signals, and support patterns. Learning connects what happened back to product choices, engineering standards, capacity, and leadership decisions.
Organizations often invest heavily in one line and neglect the others. Prevention without detection creates false confidence. Detection without learning creates recurring alarms. Learning without authority creates thoughtful postmortems and unchanged systems. Quality improves when all three lines have owners and a route into portfolio decisions.
Make reliability a product decision
Google's Site Reliability Engineering practice describes error budgets as a way to balance reliability with the pace of innovation. The important idea is not the terminology; it is the agreement. A service objective defines the reliability customers need, and the remaining budget makes the cost of change visible.
When the budget is healthy, teams can move with normal risk controls. When it is exhausted, reliability work earns priority because the organization has crossed an agreed boundary. This replaces opinion battles between ‘move faster’ and ‘stabilize’ with a decision grounded in customer impact and observed performance.
Integrate security into the same system
NIST's Secure Software Development Framework recommends integrating secure practices throughout the development lifecycle. That principle belongs inside the quality model, not in a parallel compliance track. Threats, dependencies, access, data handling, build integrity, and remediation all influence whether the product can be trusted.
Integration does not eliminate specialist review. It makes specialist knowledge available at the moment teams make design and delivery choices. Independent assurance should then concentrate on material risks, system boundaries, and whether controls work in practice.
Choose measures that reveal the system
Defect counts are easy to collect and easy to misuse. They say little without severity, escape point, customer consequence, detection time, and recurrence. A useful quality view combines escaped-impact trends, reliability against service objectives, change failure, recovery time, support demand, adoption friction, and the age of known risk.
Measures should trigger questions, not become targets detached from context. A falling defect count may signal better quality, less testing, smaller usage, or classification changes. Review the story across multiple measures and sample the underlying work. Good governance preserves curiosity.
Leadership owns the conditions for quality
Teams cannot engineer quality sustainably if every planning conversation rewards visible scope and treats resilience, maintainability, and observability as optional. Leaders set the real quality policy through capacity allocation, release pressure, incentive design, and which risks they are willing to leave unnamed.
The operating question is therefore broader than ‘Did testing pass?’ Ask instead: Do we understand the critical journeys? Can we observe them? Are changes small enough to recover from? Is known risk visible beside new investment? Does learning change priorities? Those questions turn quality from a gate into a capability.