Lack of Standardisation

The Lesson

Standardisation is one of the most important enablers of a scalable and efficient SRE organisation. It reduces operational complexity, improves engineer productivity, simplifies onboarding, lowers cognitive load, and allows knowledge, tooling and operational practices to be shared across services.

As an application managed service, however, complete standardisation is not always achievable. Unlike an internal SRE team supporting a single product or technology stack, we inherit platforms built for many different clients, each with their own technical decisions, contractual constraints and operational requirements.

The objective is therefore not to eliminate diversity, which is often impossible, but to standardise wherever we have influence and minimise unnecessary variation wherever possible.

---

The Problem

Our operating model differs significantly from that of a traditional SRE organisation.

Rather than building and operating a single platform, we assume operational responsibility for many independently delivered solutions. These solutions are developed by different delivery teams, at different times, for different clients and often using completely different technologies.

This results in a highly diverse operating landscape.

Across our managed services we may encounter differences in:

• Cloud providers
• Infrastructure as Code frameworks
• Kubernetes distributions
• Programming languages
• Application frameworks
• CI/CD platforms
• Observability platforms
• Logging solutions
• Monitoring tools
• Alerting strategies
• Security tooling
• Deployment processes
• Change management processes
• Release management processes
• Incident management workflows
• Backup and disaster recovery solutions
• Authentication and identity providers

Each individual technology choice may be perfectly valid for its respective project. The challenge emerges when they are viewed collectively across the entire managed service portfolio.

Unlike a product organisation, we cannot simply mandate that every service adopts the same technology stack. Client requirements, existing investments, contractual obligations and historical design decisions often prevent this.

The result is an environment where SRE engineers must continually switch between different technologies, operational models and ways of working. While each platform may be manageable in isolation, the cumulative effect of supporting many different platforms creates a level of operational complexity that is difficult to scale.

This creates several operational challenges.

Reduced Operational Scalability

The more variation that exists across services, the harder it becomes to scale engineering teams.

Knowledge becomes fragmented across individuals rather than shared across the organisation, making it difficult to allocate engineers flexibly across projects. Teams become increasingly dependent on specialists with knowledge of specific platforms, creating bottlenecks and reducing operational resilience.

The lack of common technologies, tooling and operational practices also limits our ability to build reusable automation, standard operating procedures and repeatable support models that can be applied across multiple services.

High Cognitive Load

Supporting a highly diverse technology estate places a considerable cognitive burden on engineers.

Unlike teams that work within a relatively consistent technology stack, our engineers are expected to build and retain knowledge across multiple cloud providers, programming languages, infrastructure platforms, observability tools, CI/CD solutions, security models and client-specific operational processes.

Each additional technology introduces its own concepts, terminology, best practices, failure modes and troubleshooting techniques. While becoming proficient in a single ecosystem is achievable, maintaining working knowledge across many independent ecosystems becomes increasingly challenging.

Over time, this accumulation of knowledge increases cognitive load. Engineers must continually recall information that may only be used occasionally while simultaneously learning new technologies as additional services are onboarded.

As cognitive load increases, engineers may experience:

• Slower troubleshooting and decision making.
• Greater reliance on documentation and subject matter experts.
• Reduced confidence when working in unfamiliar environments.
• Increased mental fatigue.
• Higher risk of operational mistakes during incidents or changes.

This is not a reflection of engineer capability. It is a natural consequence of operating across a highly diverse managed service portfolio.

Frequent Context Switching

The diversity of our estate also results in frequent context switching particularly where a team has multiple client platforms to operate and maintain.

Engineers regularly move between completely different client environments throughout the working day. One investigation may involve Azure, Terraform, Azure Monitor and .NET. The next may require AWS, Kubernetes, Prometheus, Grafana and Java. Each environment has its own architecture, operational procedures, deployment pipelines, naming conventions and support processes.

Every transition requires engineers to mentally rebuild their understanding of the service before productive work can begin.

Unlike learning a single technology deeply, context switching incurs a continual cognitive cost. Engineers spend time recalling project-specific knowledge before they can begin diagnosing issues or implementing changes. During busy operational periods this may happen many times each day.

The consequences include:

• Reduced productivity.
• Increased mental fatigue.
• Longer investigation and recovery times.
• Greater likelihood of operational mistakes.
• Reduced opportunity to develop deep expertise within individual platforms.

Some level of context switching is unavoidable within an application managed service. However, unnecessary variation between projects amplifies this burden and reduces overall engineering effectiveness.

Longer Onboarding

New engineers require significantly longer to become effective when every project introduces a different technology stack and operational model.

Instead of learning one well-defined way of operating, they must gradually build experience across many independent ecosystems.

This increases the time before new engineers can confidently support services independently and makes mentoring more resource intensive.

Hiring Becomes More Difficult

Finding engineers with deep expertise across multiple cloud providers, programming languages, observability platforms and operational toolchains is inherently challenging.

As the range of supported technologies expands, so do the expectations placed upon each engineer. Candidates with broad experience are naturally less common, while specialists may only cover a subset of the technologies within our estate.

This narrows the available hiring pool and increases the investment required in training and knowledge development.

Reduced Automation Opportunities

Standardisation enables reusable automation.

When every service follows similar deployment patterns, monitoring standards and operational processes, automation can be developed once and applied many times.

When every project is different, automation often becomes project-specific, reducing its value, increasing maintenance effort and limiting the operational efficiencies that automation is intended to deliver.

Inconsistent Operational Experience

Differences in tooling and operational practices can lead to inconsistent support quality between services.

Although engineers strive to provide a consistent operational service, differing technologies and processes mean that the experience of supporting one platform may differ considerably from another. This increases operational complexity and makes it more difficult to deliver a predictable managed service.

---

The Solution

While complete standardisation is unrealistic in our operating model, meaningful standardisation is both achievable and highly beneficial.

The focus should be on standardising the areas that are under our influence while accepting justified variation where business or client requirements demand it. The objective is not to force every client onto an identical technology stack, but to reduce unnecessary diversity and create greater consistency across the services we operate.

Establish Supported Technology Standards

Rather than allowing unlimited technology choice, define preferred technology standards for future projects.

These should include recommended technologies for areas such as:

• Observability
• Logging
• Monitoring
• Alerting
• Infrastructure as Code
• CI/CD
• Kubernetes
• Secret management
• Deployment strategies

Alternative technologies should still be supported where necessary, but preferred standards provide a default direction for new projects.

This gradually reduces diversity across the estate without disrupting existing client environments.

Influence Projects Earlier

SRE should engage during discovery and solution design to advocate for technologies that align with the managed service operating model.

Delivery teams should understand that technology selection affects not only project delivery but also many years of operational support.

Operational supportability should be considered alongside technical capability during technology selection, allowing long-term operational costs to become part of the design decision rather than an afterthought.

Define Minimum Operational Standards

Even when technologies differ, operational expectations can remain consistent.

Every service should meet common standards for areas such as:

• Monitoring coverage
• Alert quality
• Logging structure
• Dashboard availability
• Documentation
• Runbooks
• Disaster recovery
• Security controls
• Operational ownership

Standardising operational outcomes is often more achievable than standardising the technologies used to achieve them.

Build Reusable Operational Patterns

Where complete technology standardisation is not possible, standardise operational approaches.

Examples include:

• Common incident response processes.
• Standard service documentation templates.
• Shared runbook structures.
• Consistent alert severity definitions.
• Standard onboarding checklists.
• Common production readiness assessments.
• Shared operational review processes.

These reduce variation without requiring every project to use identical tooling.

Invest in Internal Engineering Standards

Document internal conventions for operating services regardless of the underlying technology.

Examples include:

• Naming standards.
• Documentation standards.
• Dashboard conventions.
• Alert naming conventions.
• Operational ownership models.
• Support processes.
• Escalation models.

Consistency in how services are operated can often be achieved even when the underlying platforms differ.

Create Shared Engineering Patterns

Where technologies cannot be standardised, the engineering experience should be.

Providing common templates, documentation structures, operational playbooks, automation patterns and architectural guidance helps engineers move between services with less cognitive effort.

The more familiar each service feels from an operational perspective, the less time engineers spend rebuilding context and the more time they spend solving problems.

Encourage Knowledge Sharing

Technology diversity cannot be eliminated, making knowledge sharing essential.

Communities of practice, technical showcases, internal documentation, technical standards and cross-project collaboration help distribute expertise and reduce dependency on individual engineers.

Cross-training also improves team resilience, increases engineering confidence and makes resource allocation more flexible.

Reduce Unnecessary Variation

Not all variation is unavoidable.

Before introducing a new technology, teams should consider whether it delivers meaningful business value or simply introduces another tool that must be supported for years to come.

Where an existing supported solution already meets the requirements, adopting that solution is often the better long-term decision.

Technology diversity should be an intentional decision supported by clear business or technical benefits, rather than the default outcome of individual project preferences.

Benefits

Improving standardisation, even incrementally, provides significant long-term benefits.

These include:

• Reduced cognitive load for engineers.
• Reduced context switching between services.
• Faster onboarding of new engineers.
• Increased engineer confidence when supporting unfamiliar platforms.
• Improved operational consistency.
• Increased opportunities for reusable automation.
• Better knowledge sharing across teams.
• Greater flexibility when allocating engineers across projects.
• Lower operational overhead.
• Reduced risk of operational error during incidents and changes.
• Improved scalability of the managed service.
• More predictable and consistent service delivery.

Our operating model will always involve a greater degree of technical diversity than many traditional SRE organisations. That diversity is a consequence of supporting a broad portfolio of client platforms rather than a single product.

The goal is therefore not complete uniformity, but deliberate consistency. By standardising where we have influence, reducing unnecessary variation and creating common engineering patterns across our managed services, we can lower cognitive load, reduce operational complexity and build an SRE organisation that is both scalable and sustainable over the long term.