Most companies that say they have adopted SRE have actually just renamed the operations team. They changed the title of "sysadmin" to "site reliability engineer", left the processes intact and then were surprised when the incidents continued at the same pace and the tension between dev and ops didn't ease. SRE is not a position. It's a specific way of thinking about responsibility, risk and speed — and without changing how the team actually operates, the title is worthless. The problem is not in the intention, but in the assumption that a change in nomenclature is enough to transform the culture of how engineering and operations relate.
What SRE really means
Site Reliability Engineering was born at Google with a straightforward premise: if you want software to work reliably at scale, put software engineers in charge of it. The core idea isn't to have people who "take care of the servers" — it's to have engineers who apply software development principles to solve operations problems.
This changes the profile of the function radically. An SRE writes code to automate repetitive operational work. Google's original book defines that up to 50% of an SRE's time should be spent on engineering — automation, tools, infrastructure improvements. When this percentage drops below this, it is a sign that the team is operating as a traditional ops team with a new name, and not as a true SRE.
SLOs and error budgets: negotiable reliability
The mechanism that makes SRE operationally coherent is the combination of Service Level Objectives and error budgets. SLOs define how much reliability a service needs to deliver — for example, 99.9% availability measured over a 30-day window. The error budget is the complement: the remaining 0.1% represents the space the team has to make mistakes, deploy, test changes without breaking the contract with the user.
This mechanism turns reliability into something negotiable rather than absolute. When the error budget is full, the team can be more aggressive in deployments and experiments. When running out, releases slow down until the window recovers. This removes the arbitrariness of risk decisions: it's not the operations manager saying "we can't deploy now" — it's the budget saying that with data. The conversation between product and engineering is based on something measurable, which completely changes the negotiation dynamics. Poorly defined SLOs, however, are worse than non-existent SLOs: they create a false sense of control while measuring things that don't reflect the real user experience.
The structural question: embedded SREs or platform team
One of the most concrete decisions an organization needs to make when adopting SRE is about structure: do SREs work embedded in product teams, or do they form a centralized platform team? There is no universal answer — and be wary of anyone who offers one without asking about the size of the organization, the level of technical maturity and the profile of the services in question.
Each model has real trade-offs. Embedded SREs stay close to the service context, understand product decisions, and build credibility with the team's developers. The risk is dispersion: the SRE ends up solving urgent problems for the local team and losing time to build shared infrastructure. Furthermore, it is difficult to maintain consistency of practices between different teams.
The platform model concentrates expertise and allows you to build tools that scale. The risk is the opposite: distance from the real context of services, a tendency to deliver solutions that do not fit well into everyday use, and an "internal customer" dynamic that sometimes generates more bureaucracy than agility. Mature SRE organizations often use both models at the same time — a platform team responsible for the base infrastructure and SREs embedded in high-risk product teams.
What the transition looks like from the inside
For those coming from the operations side, adopting SRE is often uncomfortable. The expectation is that the work will shift from "resolving incidents" to "preventing incidents from recurring through code and automation." This requires a change in identity: the professional who was valued for his ability to put out fires is now charged with reducing the rate of fires. Not everyone wants or can make this transition, and pretending it's simple creates frustration.
For those coming from the development side, the adjustment is different. Product teams need to accept that they now have co-responsibility for the reliability of the services they deliver. SRE introduces the idea that operations is not "another area's problem" — it is part of engineering work. This clashes with cultures where developers write code and "throw it over the wall" for operations to take care of. Cultural change here is as important as any tool or process.
Where adoption tends to break down
The most common SRE failures follow recognizable patterns. The first is to adopt the vocabulary without adopting the substance: teams that define SLOs but have no mechanism to act when the error budget is exhausted are only documenting expectations, not managing risk. The second common mistake is to outsource reliability completely to the SRE team, relieving product teams of any responsibility. This rebuilds exactly the silo that SRE was designed to eliminate.
The third point of failure is underestimating investment in automation. SRE only works as a philosophy if operational manual labor is systematically reduced. Without dedicated time and resources for this, the team drowns in toil — repetitive and reactive work that does not generate accumulated value. Honest SRE adoption requires leadership to actively protect the team's engineering time against short-term operational demands. Without this explicit commitment, SRE becomes just an expensive rebranding.
Also read
- Site Reliability Engineering Metrics: Defining and Monitoring SLIs, SLOs and SLAs
- Modern incident response: from detection to drama-free postmortem
- Test Coverage: Complete Guide
- Automated Testing: Architecture and Fundamentals
- Load tests: what they are and why your system should do them before the customer
- Load Testing - Business Models for Small Teams