First in a three-part series on building Site Reliability Engineering (SRE) for real.
A leader gets the mandate: stand up an SRE function. They build the SRE team by reorganizing and transferring people from the existing operations team, change the titles on the org chart, and announce that the company now does Site Reliability Engineering.
A couple of quarters later, the same incidents are recurring. The on-call rotation is heavier, not lighter. Software engineers route around the new SRE team instead of through it. Reliability has not moved.
The reorg was the problem. Not the people in it, not their effort. The decision to produce an SRE function by relabeling an ops function, and the belief that the org chart was the thing standing between the company and reliability. We have seen this pattern repeat across organizations.
SRE means software engineers designing operations
Ben Treynor Sloss, who coined the term at Google in 2003, defined it in one line: “SRE is what happens when you ask a software engineer to design an operations team.”
The key is to design an operations function using software-engineering practices, where SRE runs production by building the software that runs it: platforms, control loops, self-service tooling, systems that remove the human from the repetitive path with feedback loops and continuous learning.
This is what we see as a trap waiting in most definitions. SRE teams use paradigms such as automation, GitOps, Infrastructure as Code, and observability. So do the ops teams that have traditionally managed infrastructure. Both camps use the same tools. The rebranded ops team will stand up Terraform, wire dashboards, and run pipelines. None of that distinguishes real SRE from the relabeled version, because the tools are shared ground.
The distinction lives one level up, in what gets produced with those tools. An ops mindset reaches for a script to fix the problem in front of it, time and time again. An engineering mindset builds a system so that the entire class of problem stops occurring. One accumulates fixes. The other engineers them out of existence.
That difference is invisible on an org chart and invisible in a tool inventory. It is the entire game.
Leaders mistake infrastructure fluency for engineering capability
When the SRE mandate lands, the leader looks at the people they already have. The operations engineers know the stack, carry the pager, and have survived the outages. Reaching for them is the natural move.
The error is in the next inference. The leader watches an ops engineer who is fluent in the infrastructure, decisive in an incident, comfortable across the systems, and concludes that this fluency will translate into the ability to design scalable software. Infrastructure fluency and software-engineering capability are different skills, and competence in the first does not necessarily imply the second.
This is not a knock on the engineer. It is a category error made by the person doing the staffing. Knowing a system deeply and being able to engineer software that operates that system at scale are separate capabilities that coexist in good SREs and frequently do not coexist in anyone the reorg happens to retitle.
Being like Google is how you build a cargo cult
There is a second route to the same failure, and it usually arrives wearing a copy of the SRE book.
A leader reads how Google does it and decides to “be like Google.” They copy the structure: a named SRE team, an on-call rotation, SLO dashboards, the vocabulary. When they copy only the superficial structure of an SRE model, they miss the underlying discipline required to make it functional.
Much like an inward reorganization, this approach creates an empty framework: “Be like Google” incentivizes teams to chase visible markers over technical discipline, producing SRE teams that own the tools but lack the engineering capability.
The honest version of the lesson is narrower and more useful. Most companies cannot staff a Google-style SRE org, run a Google-grade hiring pipeline, or fund the headcount that keeps a dedicated team from being dragged back into pure operations. That part does not transfer. What transfers is the operating principle: treat operations as a software problem, and hold the line that an SRE team spends its time engineering, not absorbing toil.
The mismatch fails in four predictable ways
We have observed that when a team is formed on the skill-transfer error, the failures are not random. They follow from the mismatch in predictable ways.
Automation debt that increases toil. The leader sees an engineer write a fifty-line Bash script to handle a backup and reads it as toil reduction. It is the opposite. Software engineering elevates basic scripting by building scalable frameworks that systematically eliminate entire categories of operational problems.
A team formed on the error ships thousands of lines of fragmented, unowned, undocumented scripts that are at times not even checked into a version control system. The result is a new debt with a running interest rate: every script is a thing to maintain, and the manual load climbs instead of falling.
A firefighting culture that normalizes instability. Hero behavior reads well in a review. The engineer who joins every 3 a.m. incident and stays until it is resolved looks like exactly the grit an on-call rotation needs. But a team optimized only for heroic resolution rewards managing incidents and starves the work of preventing them.
They drive down time-to-resolution and leave the failure in place to recur next week. The system’s instability stops being an emergency and becomes the weather. The whole point of SRE is to engineer the 3 a.m. page out of existence, and a firefighting culture is structurally uninterested in doing that.
A collapse in developer trust. The team was chosen partly because they know the stack inside out, and the assumption was that this makes them strong partners for the application developers. Then a developer hits a real engineering problem: a memory leak, connection-pool exhaustion under load, or a concurrency bug. They need a partner who will go into the code with them. If the team cannot, they retreat to the boundary they know and hand back the verdict that the infrastructure looks fine and the bug must be in the application.
Developers learn this fast. Once they conclude the SRE label does not come with engineering depth, they stop bringing problems to the team, and the cross-functional partnership that SRE depends on is gone.
Metrics that measure the appearance of SRE. Leadership wants evidence the strategy worked, so it tracks the things that are easy to count: percent of staff through a Python course, number of services with an SLO dashboard, etc. The newly titled team, under pressure to look the part, optimizes for exactly those numbers. They deploy superficial SLOs and dashboards without the underlying engineering capability, and the result is empty metrics that fail to drive automated remediation or real reliability improvements.
This is Goodhart’s law running on schedule: the moment the metric becomes the target, it stops measuring the thing you cared about.
Unreliability shows up on the income statement
These are not engineering aesthetics. The skill-transfer error shows up on the income statement and in the attrition report.
Incidents recur. Treating symptoms instead of engineering out root causes ensures that the same customer-facing failures will keep recurring. A fast firefighting team still spends its life on the same fires.
Repeated outages trigger a compounding cycle of direct revenue loss, SLA penalties, a slow erosion of customer trust, and eventual customer churn.
Delivery slows down. SRE is supposed to be a force multiplier, the function that lets product teams ship faster because the paved paths and the automated guardrails already exist or get built. A team without the engineering depth to build that self-service tooling becomes a manual gate instead. Developers wait on a person to provision infrastructure and hand-check configurations. The function meant to accelerate delivery is now the bottleneck throttling it, and the business loses ground it cannot see on a dashboard.
Your best people leave, from both sides. The retitled engineers are buried under alerts and toil while being asked to write software they were never set up to write, and they burn out. The application developers quit over the platform friction and the partner who could not partner. The engineers with the most options leave first, because they have the most options. The company eats the recruiting and onboarding cost of backfilling roles that the original decision quietly made unsurvivable.
We believe that none of this is fixed by another reorg. The way out runs through the discipline the reorg skipped: staffing for software-engineering capability, holding the team to engineering work instead of letting ops gravity reclaim it.
We have rarely seen a reorg produce reliability. We have watched the engineering produce it, and we have watched how many quarters it takes.
This is the first of three parts. Next: the two paths that actually produce an SRE function - then the one condition without which none of it holds.