The Difference Between Standards, Policies, and Guidelines

These three terms are used interchangeably in most organisations, which creates significant confusion about what is mandatory and what is advice. Precision matters here.

A policy is a non-negotiable rule backed by organisational authority or external requirement. All engineers must complete annual security training. All production services must have defined on-call ownership. Policies are not subject to team-level discretion. Violation has consequences.

A standard is a required practice or pattern for a specific context. All new services must be containerised. All APIs must be documented using OpenAPI. Standards are mandatory within their defined scope. They can have defined exception processes, but the default is compliance.

A guideline is a recommended approach that teams are expected to follow unless they have a specific reason not to. Prefer functional patterns for data transformation. Name variables for clarity rather than brevity. Guidelines provide direction without mandating specific implementation. Teams can deviate when the context warrants it.

Understanding this distinction allows you to be precise about expectations. When everything is called a "standard," engineers cannot distinguish the mandatory from the advisory, and compliance with genuinely important requirements suffers.

Why Standards Exist

Standards exist to reduce the cost of cross-team work. When teams use the same logging patterns, the same observability approach, the same deployment mechanism, the same testing patterns - a platform engineer can support any service, an SRE can debug any production issue, a new team member can navigate any codebase.

Without standards, every team is an island. Knowledge is not transferable. Tooling cannot be shared. Cross-team collaboration requires extensive translation work.

The cost of standards is autonomy. Teams must make specific choices even when they have a preference for something different. The benefit justifies the cost when standards genuinely reduce coordination overhead - and only when they do.

This is the test for any proposed standard: does compliance materially reduce the cost of cross-team work, or does it just make one team's preferences mandatory for everyone?

Involving Engineers in Creating Standards

Standards that are handed down without input are standards that engineers follow minimally and work around readily. Standards created with genuine engineering input are standards that engineers understand, improve, and actually follow.

The process for creating a standard should include:

Problem identification. Start with the problem the standard is trying to solve, not the solution. "We have inconsistent logging that makes incident debugging painful" is the problem. The standard is one solution to that problem. Starting with the problem allows engineers to contribute to the solution design.

Option exploration. Present two or three realistic options with honest assessment of trade-offs. Avoid presenting a single option as if it were the only choice - this communicates that the decision is already made and the consultation is theatre.

Pilot. Before mandating a standard, pilot it with one or two teams. Does it work in practice? What did they learn? What would they change? Incorporate that learning before wider rollout.

Rationale documentation. Write down not just what the standard requires, but why. The "why" allows engineers to make good judgements in edge cases. A standard without rationale becomes cargo cult compliance - teams follow the letter without understanding the intent.

Standards Lifecycle Management

Standards are not permanent. The technical landscape changes, team structures change, tooling improves. A standard that made sense three years ago may be actively unhelpful today.

Most organisations are good at creating standards and poor at retiring them. The result is an accumulating body of requirements, some current and some obsolete, that teams must navigate. When a team encounters an outdated standard, they face a choice: comply with something that makes no sense, or deviate and hope nobody notices. Neither is good.

Review Cadence

Schedule a formal review of your standards catalogue at least annually. For each standard, ask:

• Is the problem this standard addresses still real?
• Is this standard still the best response to that problem given current tooling and practices?
• Is this standard being followed? If not, why not?
• Should this standard be retired, updated, or confirmed as still current?

Mark each standard with a last-reviewed date. A standard that has not been reviewed in two years is a candidate for retirement until proven otherwise.

Deprecation and Transition

When a standard changes or is retired, teams need a transition path. A standard that disappears overnight creates compliance problems for teams that have built processes around it. Give a sunset date, communicate the change clearly, and support teams in transition.

Handling Exceptions

No standard covers every situation perfectly. A good standards process includes a clear exception path that is neither so easy that exceptions are routine nor so hard that teams just ignore the standard instead.

An exception should require:

• Clear description of the specific situation and why the standard cannot be applied as written
• Assessment of the risk or downside of the exception
• A plan for how the team will achieve the standard's intent in a different way
• Named approval from the appropriate authority - not just self-granted exception
• A time-bound review: exceptions should not be permanent by default

Track exceptions. When you see multiple teams requesting the same exception, that is a signal that the standard needs revision, not that the teams need tighter governance.

Standards and Team Autonomy

The most common objection to engineering standards is that they reduce team autonomy. This is true, and the objection is legitimate. Autonomy matters. Engineers who can make technical decisions appropriate to their context deliver better outcomes than engineers constrained to choices that do not fit.

The response is not to abandon standards - it is to be precise about what is standardised and why.

Standardise at the boundary. The things that cross team boundaries - APIs, observability, deployment, security practices - benefit from standardisation because they affect the whole organisation. The things internal to a team - how they structure their code, what patterns they use internally, how they organise their work - typically do not.

A team should be able to choose their own internal architecture, testing approach, and code style within a standard that says "your service must expose a health endpoint and emit structured logs with these fields." The internal choices are theirs. The boundary choices are shared.

Getting Teams to Actually Follow Standards

Having standards is easy. Getting teams to follow them consistently is harder.

Make compliance visible. When teams can see their own compliance status - through automated checks, dashboards, or regular reviews - the status of standards becomes a fact rather than a question. Automated linting, security scanning, and compliance checks that run in CI pipelines make compliance default rather than effortful.

Make non-compliance difficult to miss. A standard that generates a build warning is easier to ignore than one that fails the build. Reserve build failures for the most critical standards. Use warnings for the rest. Make it clear which is which.

Avoid naming and shaming. Publishing individual team compliance scores in forums where they feel like performance metrics creates defensiveness rather than improvement. Use compliance data to identify where teams need support, not where to assign blame.

Remove the friction of compliance. If following the standard is hard and deviating is easy, teams will deviate. Invest in making compliance the path of least resistance - starter templates, platform tooling, good documentation, and responsive support when teams hit problems.

Common Failure Modes

Standards without owners. A standard that nobody is responsible for maintaining becomes outdated and ignored. Every standard should have a named owner who is accountable for keeping it current.

Standards as compliance, not learning. Checking boxes does not produce better engineering. The best standards programmes include mechanisms for teams to learn from each other about how to implement standards well, not just whether they have implemented them.

Quantity over quality. A large catalogue of standards, most of which are vaguely worded and inconsistently enforced, is worse than a small catalogue of clear, consistently enforced standards. Less and clearer is almost always better.

Enforcement without support. Telling teams they must comply with a standard without giving them the tools, training, and support to do so creates frustration rather than improvement. Standard-setting and enabling are two sides of the same coin.