Enablement Over Execution: The Real Role of SRE

There is a question that appears harmless, pragmatic, even reasonable:

“Can SRE do this for us?”

It shows up in Slack, in meetings, in tickets. Sometimes wrapped in urgency, sometimes disguised as collaboration. Yet this single sentence is one of the clearest signals that an organisation has drifted away from enablement and quietly reinstalled dependency.

This article explains why that question is wrong, what it reveals structurally, and how organisations that genuinely scale learn to replace it with a different kind of interaction.

The Agency Trap

When SRE teams are treated as an internal agency, three things happen almost immediately.

First, ownership shifts. Reliability stops being a shared property of the system and becomes someone else’s responsibility. Incidents are escalated instead of understood. Decisions are deferred instead of owned.

Second, demand explodes. Tickets multiply because the cost of asking is lower than the cost of learning. What begins as support slowly turns into permanent execution.

Third, SRE capacity becomes the bottleneck. Not because the team lacks skill or discipline, but because responsibility has been centralised where it should never have been.

None of this improves reliability. It only improves the illusion of control.

Enablement Is Not a Service

In An Evolution for a Revolution, we describe a recurring pattern: platform and SRE teams are often created with an enablement mandate, yet structured as reactive support units. The intent is sound. The structure is not.

Enablement is frequently misunderstood as “doing things once so others can copy later”. In practice, it degenerates into “doing things repeatedly so others do not have to”. This is how enablement quietly becomes an agency.

Real enablement does not scale by effort. It scales by irreversibility.

This is not a metaphor. It is thermodynamics.

In any system, reversible processes require continuous energy to maintain. The moment that energy is removed, entropy wins and the system drifts back to its previous state. Organisations behave the same way. If reliability, ownership, or safety depend on constant human intervention, meetings, or reminders, they will decay.

The only sustainable alternative is a deliberate entropy peak, applied once. A controlled increase in constraint that moves the system into a better equilibrium, where the desired behaviour persists without continuous input. Not a metastable state that collapses as soon as attention moves elsewhere, but a structurally better state.

An enabled team does not need to ask permission, escalate routinely, or wait for execution. It operates within clearly defined constraints, with tools and interfaces that make the correct behaviour the easiest behaviour.

Reliability Is a Property of the System

In mature engineering disciplines, reliability is never delegated as a service. Bridges do not have a reliability department. Aircraft do not outsource safety.

Reliability emerges from design, constraints, and distributed accountability.

This naturally pairs with proper domain isolation and explicit blast-radius control. When domains are well bounded, failures remain local, understandable, and recoverable. When they are not, incidents propagate, coordination explodes, and reliability collapses under its own coupling.

SRE was never meant to be a reliability helpdesk. Its original promise was to encode operational knowledge into systems so that humans are needed less, not more. That encoding happens through enablement: programmatic governance, shared operational language, and interfaces that make expectations explicit.

When SRE becomes busy executing tickets, it is usually because the organisation has failed to translate knowledge into constraints every team can apply consistently.

The Better Question

The wrong question is:

“Can SRE do this for us?”

The better interaction is not a request for execution, but an enablement statement, ideally formulated by the consuming team:

“What capability, constraint, or interface is missing that prevents us from doing this ourselves?”

In a healthy system, teams approach SRE not as an agency, but as a platform partner. The intent is not to delegate work, but to surface a gap in the enabling surface that SRE owns.

A Concrete Example

A team asks SRE to manage their public API.

In an agency model, SRE accepts. It provisions infrastructure, manages deployments, handles incidents, and slowly becomes the de facto owner of something it did not design and does not evolve. The domain team loses ownership. SRE gains load. The system accumulates coupling.

In an enablement model, the response is different.

SRE does not take ownership of the API. Instead, it provides an API gateway as a platform capability. Teams deploy and operate their own APIs, public or private, while remaining compliant with internal standards.

Domain teams own the API surface, the data model, and the lifecycle. SRE owns the gateway, the programmatic governance, and the shared operational guarantees.

Through the gateway, SRE encodes expectations once and applies them everywhere: authentication and authorisation standards, throttling per domain and per region, cost visibility, automatic rollback, PII filtering, and uniform observability.

The entropy peak is applied once. After that, the system runs at a lower energy state. New APIs, migrations, and integrations become easier, not harder. SRE effort decreases over time. Reliability increases. Ownership remains clear.

What SRE Measures (and What It Does Not)

SRE should remain deliberately disconnected from business-side ROI narratives. Not because outcomes do not matter, but because owning them would collapse enablement back into service delivery.

The primary metric of SRE enablement is predictability: predictable deployments, predictable failure modes, predictable costs, and predictable recovery.

Time to market, feature impact, and revenue outcomes remain the responsibility of domain teams. They choose where to invest and which trade-offs to make. SRE may influence the cost of use cases by lowering the marginal cost of shipping and operating systems, but it does not own ROI.

When SRE is asked to justify itself in terms of business performance, the system is already drifting back toward an agency model.

Beyond SRE

Nothing in this article is specific to SRE.

The same failure mode appears whenever a platform team, whether data, mobile, identity, security, or infrastructure, is treated as an internal agency rather than an enabling system.

Healthy platform teams own programmatic governance, primitives, and constraints. Product and domain teams own use cases, outcomes, and ROI. Predictability, not delivery volume, is the platform signal.

If your platform teams are drowning in requests, the answer is not more headcount.

It is fewer questions.

And that starts by refusing to answer the wrong one.