Technology Standards
Constraining technology variety to reduce operational cost — with a waiver path, or the standard is broken quietly rather than formally.
Definition
A technology standard says what the organisation uses by default for a given purpose: this language, this database, this messaging system, this observability stack.
What standards actually buy
- Reduced operational surface. Every technology needs expertise, patching, monitoring, upgrade paths and someone available at 3am. The number of things an organisation can be genuinely good at is small.
- Mobility. Engineers can move between teams without learning a new stack.
- Negotiating position with vendors, through consolidated spend.
- Faster decisions. Most choices stop being debates.
The cost is local optimality: some team is doing something more expensively than they need to because the standard says so. That is usually a good trade, and it is a trade rather than a free win.
What makes standards work
A paved road, not a rulebook. The standard should be the easiest option — a template, a module, a pipeline that works out of the box. Compliance then happens because it is convenient, which is the only form that survives deadline pressure.
A fast, credible exception process. Standards without waivers are broken quietly rather than formally, and the exceptions become invisible — which is strictly worse than granting them, because you lose the ability to see and support what is actually running.
An exception should require a stated reason, an owner, and a review date, and should be granted in days rather than in a fortnightly committee.
A defined lifecycle. Adopt, trial, contain, retire — reviewed on a cadence, so the standard set evolves rather than freezing the estate on decisions made a decade ago.
What to standardise and what to leave alone
Standardise where variety costs operational effort and provides no benefit: observability, deployment, secrets management, identity, base images, network patterns.
Leave open where the workload genuinely differs and the team bears the consequences: a specialised data store for a specialised problem, a language suited to a particular domain.
Over-standardising the second category produces teams fighting the standard, which is where waivers and shadow infrastructure come from.
Failure scenarios
- Standards with no waiver path, producing invisible exceptions.
- Standards without a paved road, so compliance is extra work.
- A standard set that never changes, freezing the estate.
- Standards covering everything, so the exception rate is high and the standard is discredited.
- Enforcement without support — mandated tooling with no team behind it.
Interview question
"How do you set a technology standard that teams follow without resenting?"