# How to create an SRE team > Creating an SRE team: assess your needs, master SLOs and error budgets, hire the right profiles, choose the right team model and start small to build lasting reliability. - Date : 2023-06-29 - Lecture : 6 min - Catégorie : devsecops - Tags : SRE, SRE Team, DevOps, Reliability, SLO, Error Budget, Automation, Incident Management, Hiring - URL : https://www.adservio.fr/en/insights/articles/creer-une-equipe-sre ## TL;DR - An SRE team keeps systems running smoothly, resolves errors that disrupt business workflows and documents problems and solutions. - Building one goes through four steps: assess current needs, understand SRE practices (SLIs, SLOs, error budgets), select experienced profiles and clearly distinguish SRE from DevOps. - Its tasks cover error prevention, data-driven decisions from metrics, toil automation, continuous learning and on-call support. - There are several types of SRE teams: comprehensive, tools-oriented, production and application, infrastructure or embedded, the right model depends on the organisation's size and maturity. - The right move is to start small with one highly qualified person, then scale up gradually, taking the time to choose. ## Why structure an SRE team in 2026 Site Reliability Engineering (SRE) teams address issues affecting operating systems and business platforms, from Kubernetes clusters to SaaS applications like Salesforce. They keep systems running smoothly and resolve the errors that disrupt business workflows, before they turn into an incident visible to customers. These teams streamline the software development lifecycle by documenting the problems encountered and the solutions applied, in the form of post-mortems and reusable runbooks. With distributed architectures and AI inference chains becoming the norm in production, operational load keeps growing: building an SRE team now calls for a structured approach rather than ad-hoc hiring. The cost of inaction is easy to measure: one hour of downtime on a critical e-commerce or banking service can cost tens of thousands of euros in lost revenue, not counting the reputational damage. Conversely, a well-built SRE team mechanically reduces mean time to resolution and the number of recurring incidents, making it a profitable investment within the first few months. ## Assessing your needs before hiring The first step is to understand the organisation's requirements and identify where SRE will create the most impact. A multi-tenant SaaS vendor doesn't have the same priorities as an IT department running a legacy-heavy application estate: scope, availability targets and budget need to be calibrated accordingly. ### Mapping your existing reliability debt Before anything else, inventory the incidents from the past twelve months, the services without monitoring and the missing runbooks. This mapping often reveals that 20% of services account for 80% of interruptions, a concrete starting point for prioritising the team's first initiatives. ### Defining a target maturity level Next, set a realistic twelve-to-eighteen-month horizon: SLO coverage, remediation automation rate, mean time to detection. This framing avoids blindly copying the Google model onto an organisation that has neither the size nor the technical maturity for it, and lets you set verifiable interim milestones rather than a vague goal of "better reliability". ## Understanding core SRE practices Getting familiar with the basic workflows before staffing is essential to correctly frame job descriptions and the team's objectives. SRE is not just about on-call rotations: it's an engineering discipline that applies software methods to operational problems. ### The SLI, SLO and error budget triptych Service Level Indicators (SLIs) measure what the user actually experiences, latency, error rate, availability. Service Level Objectives (SLOs) set a numerical target on these indicators, and the resulting error budget gives product and engineering a shared language to arbitrate between release velocity and stability. ### The historical Google model and its adaptations The original model, popularised by Google in the late 2000s, remains the reference but has broadly evolved by 2026: SRE teams embedded in product squads, internal platforms that industrialise observability for the whole organisation, or SRE augmented by AI agents for first-level alert triage. > Related read: [What is SRE (Site Reliability Engineering)?](https://www.adservio.fr/en/insights/articles/qu-est-ce-que-le-sre-site-reliability-engineering): SRE applies software engineering to IT operations: SLIs, SLOs, error budgets, automation. Origins, the difference from DevOps, and the site reliability engineer's role in 2026. ## Hiring and growing the right profiles Selecting talent with a relevant background is the trickiest step: you need experienced people for specific roles, able to collaborate with departments such as DevOps, security and product rather than working in a silo. ### The technical skills to look for Proficiency in infrastructure as code, Kubernetes and cloud platforms, an observability culture (metrics, traces, logs), scripting in Python or Go, and increasingly comfort with AIOps tooling to correlate signals at scale. The ability to write production-grade code remains a differentiating criterion, as does a solid understanding of distributed architectures and their cascading failure modes. ### Hybrid profiles and internal reconversion paths Many organisations hire internally, from experienced backend developers or systems administrators looking to reskill, rather than only chasing senior SREs in a tight market. It's also essential to clearly distinguish SRE from DevOps: DevOps focuses on development quality and velocity, while SRE executes its principles, prioritising system reliability and performance in production. ## The day-to-day tasks of an SRE team An SRE team prevents errors and minimises downtime. It relies on SLOs to set short- and long-term reliability targets, and makes data-driven decisions from system metrics rather than intuition. ### Prevention, on-call and incident management It provides structured on-call support outside regular hours, with clear escalation procedures and blameless post-mortems that turn every outage into learning. How fast an incident is detected and resolved is often the best indicator of a team's maturity. ### Automation and toil reduction It implements automation to reduce repetitive manual work, "toil" in SRE terms, and free up time for deeper engineering. A common target in 2026: keeping toil under 50% of the team's time, versus sometimes over 80% in organisations just discovering the discipline. It also maintains continuous learning and cross-team collaboration, making the team a pillar of availability and resilience. > Related read: [Incident response management: method, metrics and agentic AI](https://www.adservio.fr/en/insights/articles/gestion-de-la-reponse-a-incident): Structuring incident response: lifecycle, roles, MTTA and MTTR metrics, observability, AI agents and the 2026 platforms to restore service as fast as possible. ## Choosing the right team model for your context There is no single SRE team model: the right choice depends on the organisation's size, the criticality of its services and the DevOps maturity already in place. ### Comprehensive, tools-oriented or production-dedicated teams The comprehensive SRE team handles all aspects of SRE, identifies recurring event patterns and collaborates broadly with DevOps teams. The tools-oriented team specialises in developing and maintaining software for support, planning and reliability. The production and application team ensures the reliability of business-critical applications, often the ones generating the most revenue. ### Infrastructure or embedded teams The infrastructure team streamlines tasks across departments, maintains shared services such as Kubernetes or managed databases, and oversees multi-account cloud operations. The embedded team, finally, works closely with the developers who change code daily and configures system services to improve performance directly within product squads. Many organisations end up combining several of these models as they grow, starting with an infrastructure team before spinning off embedded SREs into their most critical product teams. > Related read: [Software reliability metrics: types and benefits](https://www.adservio.fr/en/insights/articles/metriques-de-fiabilite-logicielle): Software reliability metrics quantify a system's ability to run without failure: MTTF, MTTR, MTBF, ROCOF, POFOD, availability and SLOs. ## Start small and build over time with Adservio The right move is to start small in order to scale: begin with one or two highly qualified people to lay the foundations, first SLOs, first runbooks, first tooled on-call rotation, then build up gradually as the value becomes visible to product teams. You should also take your time selecting your team, mixing internal and external candidates with diverse perspectives rather than rushing hiring to fill a vacant seat. At Adservio, this approach is part of our SRE and observability expertise: we help organisations structure their reliability teams and practices, avoiding costly pitfalls and anti-patterns rather than piling up extra tools. In practice, this support takes the form of an initial maturity assessment, a two-to-three-quarter ramp-up plan and a gradual transfer of skills to internal teams, so reliability becomes a lasting capability of the organisation rather than an external dependency. ## FAQ ### What is an SRE team for? An SRE team keeps systems and platforms running smoothly, resolves the errors that disrupt business workflows, and streamlines the development lifecycle by documenting problems and their solutions through SLOs, runbooks and post-mortems. ### What are the steps to create an SRE team? Four steps: assess current needs and map out reliability debt, understand basic SRE practices (SLIs, SLOs, error budgets), select experienced profiles with a relevant background, and clearly distinguish the SRE role from the DevOps one. ### Which SRE team model should you choose based on organisation size? There is no single model: a comprehensive team for broad coverage, a tools-oriented team to industrialise observability, a dedicated production team for critical services, an infrastructure team for the shared platform, or an embedded team directly within product squads.