Introduction to technical standards

Technical standards define what "good" looks like from a technical perspective. They describe the desirable end state of working software in terms of its internal quality. Also in scope are the artifacts that support the development, maintenance, and operation of software, from requirements specifications and design docs, to automated tests and deployment pipelines.

Technical standards specify outcomes for technical quality, but they do not prescribe methods for achieving those outcomes. Topics like iterative and incremental development, feedback loops, and ways of working are out of scope. Those topics are for a process playbook.

Technical standards are written for a technical audience: architects, technical leads, computer programmers, quality assurance engineers, etc. Business stakeholders state what they need from a system separately, through product requirements documents and service-level agreements. Technical standards are what the people who design, build, and operate a system hold each other to.

Technical standards have numerous benefits. They shorten onboarding, reduce the number of decisions revisited on every project, and give reviewers a shared, objective basis for feedback. But their main value lies in containing technical sprawl across an organization.

To be useful and enduring, technical standards must strike a balance between the abstract and the concrete. High-level design principles are the most timeless but offer nothing to verify against. At the other extreme, treating technical standards as requirements specifications — eg. pinning numeric targets for metrics like service availability and latency — tightly couples them to a particular software system at a particular point in its lifetime. Technical standards have the greatest value when they can be applied across many systems.