How to Bootstrap an SRE Function From Scratch

Most reliability functions are born the same way: something breaks badly enough that a leader says "we need SRE," and three months later there is a team, a pager, and not much else. The outages keep happening. The new team becomes the place tickets go to die. Within a year someone is quietly asking whether the headcount was worth it.

That failure isn't about the people. It's about the order they were asked to work in. Standing up reliability engineering is an org-design problem first and a hiring problem a distant second, and almost everyone does those two in the wrong sequence.

Here is the sequence I'd run if I were starting one from nothing.

Reliability is a product decision, not a virtue

The first mistake is treating reliability as something more is always better. It isn't. Every nine you add costs real money and real velocity, and past a point your users cannot even perceive the difference. A function that chases 100% uptime as a moral goal will burn its credibility arguing for work the business never asked for.

So before you hire anyone, you answer one question for each critical service: how reliable does this actually need to be? Not aspirationally. In numbers the business will sign off on. That number is the foundation everything else stands on, and the fact that nobody has written it down yet is exactly why you have a reliability problem.

An SRE function without an agreed reliability target isn't an engineering team. It's an opinion with a pager.

Start with a contract, not a team

The unit of work that makes SRE real is not a person. It's an agreement. Three artifacts, in this order:

• SLIs: the handful of signals that actually reflect whether users are having a good time. Usually availability and latency on the requests that matter, not a wall of dashboards nobody reads.
• SLOs: the target you commit to for each of those signals. This is the number from the section above, made explicit and owned jointly by engineering and the business.
• Error budget: the inverse of the SLO. If the target is 99.9%, you have 0.1% to spend. That budget is the single most useful tool the function will ever own, because it turns "are we reliable enough" from a debate into arithmetic.

The error budget is what gives a brand-new function authority it has not earned yet. When the budget is healthy, teams ship fast and SRE gets out of the way. When it's blown, feature work pauses and reliability work takes priority, and nobody has to win an argument to make that happen, because the rule was agreed in advance. You are not the team that says no. You are the team that runs the scoreboard everyone already agreed to play by.

Earn the seat by deleting work, not adding it

A young reliability team has a credibility problem: it produces nothing customers can see. The fastest way to lose the mandate is to spend the first quarter building a platform nobody asked for. The fastest way to keep it is to find the most painful, most repetitive operational work in the org and make it disappear.

SREs have a word for that work: toil. Manual, repetitive, automatable effort that scales linearly with traffic and teaches you nothing. The deploy someone babysits by hand. The alert that fires every night and is always the same fix. The capacity request that takes four people and a spreadsheet.

Pick the worst one and kill it in public. Then the next. Toil reduction is how a function with no shipped features proves its worth in weeks instead of quarters, and it buys you the political capital for the deeper work later.

A reliability function earns its budget by giving other teams their time back, not by guarding a wall.

On-call is a culture you design, not a rotation you fill

The moment you stand up a pager, you are making a statement about how this org treats its engineers at 3 a.m. Get this wrong early and you will spend years undoing it. A few non-negotiables I'd set on day one:

• The team that writes it carries it. SRE does not exist to be the human shield between product teams and their own bugs. When developers feel the pain of what they ship, the pain gets engineered away. When SRE absorbs it, the bugs are free and they multiply.
• Every page must be actionable. If an alert fires and the right response is to ignore it, that alert is training your engineers to ignore alerts. Ruthlessly delete the noise. A pager people trust is worth more than a pager that catches everything.
• Blameless retros, in writing, every time. The goal of an incident review is a systemic fix, not a person to point at. The first time you let a retro turn into a search for who messed up, people stop telling you the truth, and you go blind.

You are building leverage, not a pager

Here's the part that gets missed. The goal of a reliability function is not to own reliability. It's to make reliability something the whole org is good at, and then to step back. The platform, the SLOs, the runbooks, the automation: those are all mechanisms for moving capability into other teams, not for hoarding it on yours.

This is the same shift that separates senior engineers from staff and leaders: you stop being measured by what you personally keep running and start being measured by what you make possible for everyone else. A reliability function that becomes indispensable as a firefighting squad has failed. One that makes itself progressively less necessary, because the rest of the org has internalized how to build and run reliable systems, has done the actual job.

The order, in one breath

Define how reliable each thing needs to be. Turn that into SLOs and an error budget the business co-owns. Use the budget as the scoreboard so reliability decisions stop being arguments. Earn your seat by deleting toil in public. Design on-call as a culture before you fill a rotation. And aim the whole thing at leverage, so the function's success looks like the rest of the org getting better, not the function getting bigger.

Do it in that order and the team you eventually hire walks into a function that already has a mandate, a scoreboard, and a reason to exist. Do it in the usual order, team first, and you've just bought yourself a second on-call rotation and a year of explaining why the outages didn't stop.