Standards

The quality of a test suite is only as good as the data it runs against. When test data is sparse, stale, inconsistent across environments, or — worst of all — sourced from real production records containing personally identifiable information, testing becomes unreliable and the organisation is exposed to significant regulatory and reputational risk. This standard establishes that test data must be deliberately managed: it should be representative of real-world scenarios, consistently available across all environments, seeded reliably as part of environment provisioning, and free from any production PII that could violate data protection obligations.

Investing in well-managed test data accelerates delivery by reducing the time teams spend diagnosing test failures caused by missing or unexpected data states rather than genuine defects. It enables confident parallel development across feature branches and environments without contention over shared data. It also provides a critical control layer for compliance — ensuring that the boundary between production data and test environments is enforced systematically rather than relying on individual discipline. Teams operating to this standard can test edge cases, failure modes, and volume scenarios safely, leading to higher-quality software and fewer production surprises.

This standard ensures guardrails are embedded in delivery workflows to guide safe, high-quality engineering decisions without slowing teams down. They provide proactive, automated checks that prevent issues before they reach production.

Aligned to our "Guardrails, Not Gates" policy, this standard enables autonomy with confidence. Without it, teams rely on manual oversight or overly restrictive gates—leading to delays, frustration, or increased risk.

This standard ensures security is embedded from the outset—not bolted on later—by integrating threat modelling, secure design, and controls into early development stages. It reduces risk while supporting speed and scale.

Aligned to our "Secure by Design" policy, this standard builds resilience through foresight, not reaction. Without it, vulnerabilities emerge late, are costlier to fix, and erode user and stakeholder trust.

This standard ensures changes are introduced with minimal failures and maximum resilience by measuring and managing Change Failure Rate (CFR)—a core DORA metric. It enables high-velocity delivery without compromising quality, stability, or trust.

Aligned to our "Resilience Over Uptime" and "Secure by Design" policies, this standard drives investment in robust testing, observability, and safe deployment practices. Without it, change introduces risk blindly, erodes confidence, and limits the ability to innovate at pace.

This standard ensures systems are designed to recover quickly and fail safely, reducing the blast radius of incidents and supporting sustainable, high-velocity delivery. It embeds resilience into the architecture, not just the process.

Aligned to our "Resilience Over Uptime" and "Balance Sustainability with Speed" policies, this standard protects user experience and team wellbeing during failure scenarios. Without it, systems become brittle, outages last longer, and recovery depends on manual intervention.

Database schema changes are among the highest-risk operations in any software delivery pipeline. When migrations are managed informally — applied manually, stored outside version control, or executed independently of application deployments — the risk of data corruption, schema drift, and production incidents increases dramatically. This standard establishes that all schema changes must be tracked in version control, validated in lower environments, and applied automatically as a coordinated part of the deployment pipeline, ensuring the database and application code always evolve together.

Beyond risk reduction, treating database changes as first-class delivery artefacts enables teams to move faster with greater confidence. Automated migration execution eliminates the coordination overhead of manual DBA handoffs, rollback strategies become deliberate and tested rather than improvised under pressure, and zero-downtime techniques such as expand-contract patterns allow continuous deployment even for complex schema changes. Teams that adopt this standard experience fewer production incidents related to database changes and recover significantly faster when issues do occur.

This standard ensures infrastructure is managed as code—version controlled, peer reviewed, and tested before deployment. It brings rigour, traceability, and collaboration to infrastructure changes, reducing risk and improving quality.

Aligned to our "Infrastructure as Code (IaC) & Policy as Code" policy, this standard promotes shared ownership, continuous learning, and safer delivery. Without it, changes are harder to track, review, and recover from.

The goal of a production system is not to never fail — it is to fail safely, recover quickly, and ensure that when failures occur, the engineering team knows before the customer does. Reactive incident management, where teams discover problems through user complaints or support tickets, represents a fundamental failure of operational maturity. This standard establishes that teams must invest in proactive failure detection: alerts that fire based on meaningful signals, on-call processes that are clearly defined and fairly distributed, and runbooks that enable any engineer on the team to respond confidently to the most common failure scenarios.

Proactive failure detection is directly linked to the organisation's ability to honour service level objectives and manage error budgets responsibly. When alerting is well-designed — combining threshold-based rules for known failure modes with anomaly detection for unexpected behaviour — teams spend less time in reactive fire-fighting and more time on deliberate improvement. Alert fatigue, one of the most damaging conditions in on-call engineering, is addressed by continuously refining signal quality: ensuring every alert is actionable, routed to the right person, and tied to a documented response procedure. Teams that operate to this standard achieve lower mean time to detect, faster recovery, and a culture where reliability is an engineered property rather than a hoped-for outcome.

As AI tools, APIs, and models become embedded in software delivery, engineers must develop the literacy to apply them responsibly — not just as productivity accelerators, but as components of production systems with real risks. This standard ensures engineers understand how to evaluate AI-generated outputs, recognise the limitations and failure modes of AI models, and make informed decisions when integrating AI capabilities into features, workflows, and architectures.

This is not merely about using AI copilots more effectively. It encompasses understanding prompt design, model behaviour, data provenance, bias and fairness considerations, and the security and compliance implications of incorporating third-party AI services. Engineers who possess this literacy protect their teams and organisations from compounding hidden risk, and are equipped to realise the genuine value AI can offer when applied with judgement and care.

Systems that cannot be observed cannot be reliably operated or improved. This standard establishes that structured logging, distributed tracing, and metrics must be treated as core engineering requirements — designed in from the outset, not retrofitted after incidents expose gaps. When teams have genuine observability, they can understand system behaviour in production without needing to reproduce problems locally, dramatically reducing mean time to detect and recover from failures.

Observability is the foundation of confident delivery. The three pillars — logs, metrics, and traces — provide complementary lenses on system health: logs capture discrete events, metrics surface aggregated trends, and traces reveal the path of requests through distributed systems. Together, they empower engineers to ask novel questions about system behaviour, support informed capacity planning, and give product and operations teams the shared situational awareness needed to act with confidence.

This standard ensures major incidents are followed by timely, blameless reviews that focus on learning, not fault. It helps teams uncover root causes, share insights, and strengthen systems without fear or blame.

Aligned to our "Post-Incident Learning Culture" policy, this standard builds trust, encourages transparency, and improves system resilience. Without it, teams miss critical learning opportunities and risk repeating avoidable failures.

This standard ensures automation is a core part of team mindset and system architecture—not an afterthought. By embedding automation into how we design and build, teams reduce manual effort, improve consistency, and deliver with greater speed and confidence.

It supports our policy to "Automate everything possible" and reinforces a modern engineering culture that values self-service, resilience, and scalable operations. Without this focus, teams risk fragmented systems, slower delivery, and rising operational debt.

This standard ensures codebases consistently reflect high-quality engineering practices, enabling systems that are reliable, maintainable, and scalable. It promotes shared accountability for technical integrity and strengthens confidence in delivery outcomes.

Aligned to our "Engineering Excellence First" policy, this standard drives consistency, readability, and long-term value across teams. Without it, teams risk fragmented code, technical debt, and reduced ability to evolve systems with speed and safety.

This standard ensures that tests provide reliable, actionable confidence in code changes, allowing teams to move quickly without compromising stability. Effective testing practices catch issues early, reduce rework, and underpin safe, continuous delivery.

Aligned to our "Engineering Excellence First" and "Architect for Change" policies, this standard promotes technical assurance, repeatable quality, and accelerated learning. Without it, teams ship with uncertainty, increasing the risk of defects, regressions, and user impact.

This standard ensures systems are architected with modularity and adaptability in mind, enabling teams to make changes safely, quickly, and with minimal disruption. It promotes long-term agility and reduces the hidden cost of architectural debt.

Aligned to our "Architect for Change" policy, this standard supports scalable design, faster iteration, and technical resilience. Without it, change becomes costly, fragile, and a blocker to innovation.

Documentation is a first-class engineering concern, not a finishing touch. When documentation lives alongside the code it describes, is reviewed in pull requests, and is written for the next engineer rather than the current one, it becomes a force multiplier for the whole team. Architecture decision records capture the reasoning behind technical choices. READMEs enable fast onboarding. API docs reduce integration friction. Runbooks empower anyone on-call to respond with confidence. Together, these artefacts represent the institutional knowledge that allows teams to operate and evolve their systems sustainably.

Documentation that drifts from the systems it describes is worse than no documentation — it misleads and wastes time. This standard establishes that accuracy and accessibility are ongoing engineering responsibilities, not one-time tasks. Teams that embed documentation into their definition of done, review it as seriously as code, and invest in structured approaches like Architecture Decision Records (ADRs) and operational runbooks, build systems that are more resilient, more transferable, and far easier to maintain over time.

This standard ensures that product and engineering decisions are grounded in live, reliable data—enabling teams to prioritise effectively, validate assumptions, and adapt with confidence.

Aligned to our "Data-Driven Decision-Making" policy, this standard strengthens accountability, improves responsiveness, and reduces risk. Without it, teams operate on guesswork, slowing progress and increasing the chance of misaligned outcomes.

This standard ensures systems are integrated through stable, loosely coupled interfaces—enabling teams to evolve domains independently without breaking changes. It supports resilience, modularity, and flexibility at scale.

Aligned to our "Architect for Change" policy, this standard reduces integration risk, improves maintainability, and strengthens autonomy. Without it, changes ripple unpredictably across domains, slowing delivery and increasing system fragility.

Monitoring and observability practices have historically been designed for operations teams — measuring infrastructure health, CPU utilisation, memory usage, and service uptime. While these signals are necessary, they are insufficient. A server can be running perfectly while customers are experiencing failed transactions, slow checkouts, or broken user journeys. This standard establishes that monitoring must be anchored to what customers and the business actually care about: whether users can complete their goals, whether revenue-generating flows are functioning correctly, and whether the organisation can detect and respond to degradations that affect outcomes before they escalate into incidents.

Aligning monitoring to business and customer outcomes transforms observability from a reactive operations tool into a proactive product intelligence capability. When teams instrument against Service Level Indicators (SLIs) tied to user experience — such as the percentage of checkout completions, the latency users experience on critical pages, or the error rate visible to end users — they gain the ability to prioritise work, justify investment, and communicate system health in a language that business stakeholders understand. This standard supports the transition from "the servers are fine" to "our customers are succeeding", enabling engineering teams to demonstrate value, not just availability.

This standard ensures teams plan and execute work based on measurable outcomes rather than just outputs—focusing on the real impact achieved. It aligns efforts with meaningful goals, driving more informed decisions and reducing wasted effort.

Aligned to our "Outcome-Driven Development" policy, this standard keeps teams laser-focused on delivering tangible, trackable value. Without it, work drifts toward checking boxes instead of creating true impact.

This standard ensures teams regularly review and retire low-value features, preventing bloat and maintaining a clear, high-impact product. It frees up capacity, reduces user confusion, and aligns development with measurable outcomes.

Aligned to our "Measure & Validate Value" policy, this standard drives continuous improvement and focus on what truly matters. Without it, products become cluttered, maintenance costs rise, and user satisfaction suffers.

This standard ensures prioritisation decisions are driven by real customer needs, aligning effort with the highest user impact. It keeps teams focused on what matters most for delivering meaningful outcomes.

Aligned to our "Customer-First Thinking" policy, this standard fosters shared clarity on value creation. Without it, resources may be invested in lower-impact work, delaying or diminishing benefits for customers.

Change approval processes exist to reduce risk — but when they rely on manual gates, committee reviews, and synchronous sign-off, they become the primary bottleneck to delivery flow. This standard establishes that approval processes must be redesigned around trust, evidence, and automation rather than bureaucratic ceremony. High-trust teams with strong test coverage, observability, and automated quality gates do not need a Change Advisory Board to approve every deployment. The risk is managed earlier in the pipeline, not at the point of release.

Aligned to our "Engineering Excellence First" policy, this standard pushes organisations to replace heavyweight approval theatre with automated change classification, pre-approved change types, and peer-reviewed deployment processes backed by audit trails. The DORA change failure rate — not process compliance — becomes the primary indicator of whether the change process is working. Teams that adopt this standard deploy more frequently, with greater confidence, and with a measurable reduction in change-related incidents.

Infrastructure that is manually provisioned, inconsistently configured, and unable to scale without human intervention is a direct constraint on delivery speed and system reliability. This standard establishes that all infrastructure must be defined as code, provisioned on-demand, and capable of scaling horizontally to meet changing load — without manual intervention. Infrastructure as Code (IaC) using tools such as Terraform or Pulumi ensures that environments are reproducible, version-controlled, and auditable. It eliminates environment drift, reduces the risk of configuration-related incidents, and enables teams to spin up and tear down environments in minutes rather than days.

Aligned to our "Engineering Excellence First" policy, this standard recognises infrastructure as a first-class engineering concern, not an operational afterthought. Cloud-native patterns including auto-scaling, containerisation, and ephemeral environments allow teams to match resource allocation to actual demand, reducing cost while improving resilience. Environment parity — ensuring that development, staging, and production environments are structurally identical — removes the "it works on my machine" class of incident and accelerates the path from code to confident deployment. Infrastructure that cannot keep pace with delivery ambitions will always constrain the speed of the teams that depend on it.

This standard ensures Continuous Integration (CI) pipelines are engineered for speed, reliability, and enforce essential quality gates automatically. Fast, stable pipelines shorten feedback loops, reduce the cost of change, and ensure defects are caught early without slowing down delivery.

Aligned to our "Automate Everything Possible" and "Engineering Excellence First" policies, this standard improves team velocity, delivery confidence, and technical quality. Without it, delivery slows down, errors creep into production, and engineering teams lose confidence in their ability to release safely at speed.

This standard ensures changes are deployed to production frequently and sustainably, enabling faster feedback, safer releases, and quicker time-to-value. Deployment Frequency (DF) is a key DORA metric and a signal of healthy engineering flow.

Aligned to our "Fast Feedback Loops" and "Empower Teams to Self-Serve" policies, this standard promotes autonomy, reduces risk, and supports continuous delivery. Without it, releases become bottlenecks, innovation slows, and operational risk increases.

This standard ensures teams minimise lead time—from the start of work to safe production deployment—by targeting Lead Time for Change (LTFC), a key DORA metric. Shorter lead time lowers risk, accelerates learning, and increases delivery flow efficiency.

Aligned to our "Fast Feedback Loops" and "Limit Work in Progress (WIP)" policies, this standard reveals and resolves bottlenecks that slow value creation. Without it, teams endure lengthy development cycles, delayed feedback, and hidden coordination costs.

This standard ensures developer workflows are optimised for speed, clarity, and flow—minimising friction, blockers, and waste. It enables engineers to focus on delivering value, not fighting tools or processes.

Aligned to our "Developer Experience Matters" and "Minimise Handoffs" policies, this standard improves delivery velocity, engineering satisfaction, and system quality. Without it, productivity drops, morale suffers, and the cost of change increases.

This standard ensures customer feedback is continuously captured, analysed, and acted on—closing the loop between delivery and real-world outcomes. It helps teams stay responsive, reduce waste, and build what truly matters.

Aligned to our "Fast Feedback Loops" and "Customer-First Thinking" policies, this standard turns insights into action and strengthens user-centric design. Without it, teams risk drifting from user needs, repeating mistakes, and missing opportunities for improvement.

When delivery teams must raise tickets, wait on other teams, or navigate undocumented processes to provision environments, deploy services, or access shared capabilities, their flow is interrupted and their autonomy is constrained. Internal Developer Platforms (IDPs) solve this by building paved roads — curated, opinionated golden paths that make the right way the easy way. Teams can self-serve what they need, when they need it, without creating dependencies on centralised operations or platform teams. The platform encodes organisational best practices into tooling, so safe and efficient delivery becomes the default rather than something that requires expertise or permission.

Aligned to our "Engineering Excellence First" policy, this standard recognises that platform teams must treat their platform as a product — with a roadmap, user research, versioned APIs, and a commitment to reducing cognitive load for the teams they serve. A great internal platform abstracts complexity without hiding it entirely, offers clear platform contracts, and measures its own success through the delivery performance and satisfaction of the product teams using it. Platforms that are poorly designed or poorly maintained become obstacles rather than accelerators; this standard defines what good looks like at each level of organisational maturity.