When to Hire an SRE and What Must Exist Before You Do
When to hire an SRE depends on signals you can check and four prerequisites the first hire needs. What one SRE cannot fix and the cheaper steps to try first.
Quick Answer
Hire a first SRE when production interrupts are visibly stalling product work and the system is complex enough to need specialist diagnosis. The hire only works if service ownership, basic SLOs, an incident review habit and usable observability already exist. Without them the new SRE becomes the person every page lands on. Cheaper steps, such as an owned on-call rotation and faster diagnosis, should come first.
Knowing when to hire an SRE means knowing when reliability work has outgrown what product engineers can absorb alongside their roadmap. A site reliability engineer applies software engineering to operations, so the role pays off when there is engineering to do, not only fires to put out.
We wrote this because most of the advice on the question comes from people with something to sell, such as a placement, a contractor or an outsourced service. Their answer is usually yes. Ours is "it depends on four things you can check this week".
In this post we cover the signals that matter, the four prerequisites a first SRE needs, what one SRE cannot fix, the cheaper steps to try first, SRE versus platform engineering, where to place the hire, and when hiring now is the right call.
Most Advice on Hiring an SRE Comes From Someone Selling One
Search results for this question are dominated by recruiters, staffing firms and vendors offering SRE as a service. A recruiter earns more when you hire, a staffing firm when you contract and an outsourcing vendor when you rent. None of that makes their advice wrong, but it does make "yes" the default.
What those pages rarely say is the uncomfortable part. An SRE hired into a team with no ownership and no shared definition of healthy does not create reliability. They become the new name on every incident, and they leave.
We think the better starting point is evidence from inside your own organization, plus the practices Google documented when it explained how its SRE teams are run.
The Signals That Answer When to Hire an SRE
No headcount number answers this on its own. We look for several of the following at once, and treat any single one as a reason to investigate rather than to hire.
- Interrupts are eating the roadmap. Senior product engineers spend a large, growing share of each sprint on incidents, manual fixes and questions about production.
- Diagnosis is the slow part. Incidents take hours not because fixes are hard but because nobody can find the cause quickly across services, queues and databases.
- Commitments have become contractual. Customers now hold SLAs with consequences, so reliability is a business obligation, not a preference.
- The rotation is too small to be humane. Google's chapter on being on-call derives that a single-site team needs at least eight engineers to sustain a 24/7 primary and secondary rotation within its 25% on-call limit.
The same book frames the budget an SRE needs. In its chapter on eliminating toil, Google says its SRE organization aims to keep operational work "below 50% of each SRE's time." If a hire would spend nearly all of their time on toil from day one, the signal is real but the conditions are not.
Four Things That Must Exist Before the First SRE Arrives
Reliability is a capability of the whole engineering organization before it is a job title. We check four prerequisites, because each one decides if a first SRE spends their time building or absorbing.
1. An Ownership Map
Every service, database and pipeline has a named owning team. If the SRE owns whatever breaks, product teams lose the feedback that comes from being paged for their own code, and the SRE inherits every orphaned system in the company.
2. SLOs With Consequences
Google's SRE workbook chapter on team lifecycles puts this first, as its Principle #1. "SRE needs SLOs with consequences." It also argues that a team can set SLOs and an error budget policy without having a single SRE, because an implicit 100% target means a team can only ever be reactive.
We would not wait for a sophisticated framework. A shared definition of up and fast for the few user journeys that matter is enough to start.
3. An Incident Review Habit
If reviews end with "we fixed the bug and it will not happen again", a new SRE has nothing to work with. A habit of looking for contributing causes, missing safeguards and tooling gaps gives the first SRE a backlog that is worth their time.
4. Observability Good Enough to Investigate With
With no structured logs, metrics or traces, a first SRE spends months discovering where errors come from before fixing any of them. The workbook lists improving monitoring as one of the natural first projects, which is fine, but it should not be the only thing standing between the team and every diagnosis.
The workbook's other suggested first projects are telling. Addressing high-priority actions from recent postmortems and automating one specific element of toil both assume the prerequisites above already exist.
What Your First SRE Cannot Fix
One SRE cannot be the first responder for every alert. We call this the pager sink, and it fails predictably. The workbook names the warning signs, including an SRE on a product team "doing more than their fair share of operational work" and SLOs that are not taken seriously.
A single hire also cannot fix an interrupt culture where untested changes ship because someone else will catch them, or services that nobody has owned since their author left. Those are management problems that need management decisions.
The workbook's Principle #2 is the guardrail. "SREs must have time to make tomorrow better than today." If the plan for the hire leaves no project time, we would fix the plan before opening the role.
Try These Cheaper Rungs Before You Open the Req
A full hiring cycle is slow and expensive, and a new SRE needs time to learn the system. Each rung below is cheaper and faster, and each makes an eventual hire more effective.
- Rotate ownership. Put product engineers in a formal on-call rotation for their own services, so the people who change the code see what it does in production.
- Buy down diagnosis time. Much of on-call pain is the hours of root cause analysis, not the fix. Faster investigation, from better runbooks to an AI agent that investigates with evidence, returns that time without a new role.
- Fund platform work. Give an existing group a quarter to standardize deploys, CI and basic monitoring.
- Then hire. If the rungs above do not stabilize things, open the role with the prerequisites in place.
Outsourcing is another rung, with its own questions about who owns which production work. Our post on what managed SRE services should answer covers that comparison.
SRE or Platform Engineer Depends on the Pain
The SRE vs platform engineer choice blurs at small companies and sharpens as teams grow. We decide by the problem that hurts most, not by the title that sounds more senior.
| If the main pain is | Hire toward | Their first quarter |
|---|---|---|
| Outages, slow diagnosis and on-call burden | SRE | SLOs, incident follow-ups, toil automation |
| Deploy friction and manual infrastructure | Platform engineer | Paved paths for build, deploy and environments |
| Both, at a small company | One generalist with clear priorities | The single bottleneck that costs the most this quarter |
Where to Place the First SRE Matters as Much as Who
The workbook gives three options for a first SRE. Embed them in a product development team, in an operations team, or in a horizontal role consulting across teams. It recommends choosing based on your own influence, the immediate challenges, the next 12 months and the person you hired.
It also warns against switching models repeatedly, and "strongly" recommends one stable and coherent model in the long term. We would add that a separate one-person SRE team tends to become a help desk, so whichever option you pick, give the SRE a distinctive role with projects that benefit the whole team.
Once the person starts, the speed at which they can take a primary on-call shift is worth measuring. Our post on time to first page covers that number, and our piece on interviewing SREs for diagnosis covers how to find the right person.
When Hiring an SRE Now Is the Right Call
The prerequisites are a strong default, not a law. If a contract carries real penalties for downtime, or a regulator expects named operational ownership, waiting a year to build ownership maps first may cost more than an imperfect hire.
In that case we would hire, but make the prerequisites the SRE's explicit first mandate, with leadership backing to assign owners and set SLOs. A first SRE with authority to change how the team works can build the foundation. One without authority will drown in it.
It is also the right call when the prerequisites already exist and the team is still overloaded. That is exactly the situation the role was designed for.
Decide When to Hire an SRE From Evidence, Not One Bad Outage
A single painful outage is a poor reason to open a role. We would decide when to hire an SRE by checking the signals, confirming the four prerequisites, trying the cheaper rungs, and then hiring into a placement you intend to keep.
Start by measuring how much of each sprint goes to production work. Operate runs dedicated AI agents inside your own infrastructure that investigate production issues through read-only adapters, and every finding cites its evidence.
Frequently Asked Questions
When production interrupts are visibly slowing product work, diagnosis is the bottleneck, and the system is complex enough to need specialist skills. We also want ownership, basic SLOs and usable observability in place first, so the first SRE builds lasting improvements instead of answering every page.
An SRE focuses on running production reliably, through SLOs, incident response and automating toil. A platform engineer focuses on the tools and paved paths developers use to build and deploy. We pick by the pain that costs most, outages and on-call, or deploy friction and manual infrastructure.
Getting up to speed on the service, then defining SLOs if none exist. Good first projects are better monitoring, high-priority postmortem actions and automating one specific source of toil. We protect project time from the start, because an SRE buried in operational work cannot make tomorrow better than today.
Google's SRE book calculates that a single-site team needs at least eight engineers to run a 24/7 rotation with a primary and a secondary on week-long shifts, while keeping on-call under a quarter of each person's time. We treat smaller rotations as a burnout risk to plan around.
It can be. The SRE workbook lists three placements, a product team, an operations team or a horizontal consulting role, and advises choosing by your current challenges and plans. We would pick one model and keep it, since switching repeatedly undermines the role.
About the author
Operate Team
The team behind Operate
Operate Team builds Operate, enterprise AI agents for production operations. Operate answers production questions from Slack and Microsoft Teams, investigates alerts, and reviews performance, security and cost. It finds the root cause with evidence and proposes a fix for an engineer to review, with controlled access to your systems.
