1) Role Summary

The Head of Site Reliability Engineering (SRE) owns the reliability, availability, performance, and operational excellence of the company’s production systems and customer-facing services. This role sets the SRE strategy, operating model, and reliability standards while leading teams that build scalable automation, observability, incident response capabilities, and resilient infrastructure patterns across the engineering organization.

This role exists in software and IT organizations because modern products depend on always-on platforms, complex distributed systems, and rapid change; without a dedicated reliability leader, incident risk, customer impact, and operational toil rise as the business scales. The Head of SRE creates business value by reducing downtime and customer-impacting incidents, protecting revenue and brand, enabling faster and safer releases, improving engineering efficiency through automation, and ensuring measurable reliability through SLOs/SLAs.

• Role horizon: Current (widely established in software and IT organizations)
• Typical reporting line (inferred): Reports to VP Engineering or CTO (depending on org structure)
• Typical teams/functions interacted with:
• Platform Engineering / Infrastructure
• Application Engineering (product teams)
• Security / Information Security
• Architecture (enterprise or solution architecture)
• Product Management (for availability commitments and customer impact)
• Customer Support / Customer Success
• IT Operations / Corporate IT (where applicable)
• Compliance / Risk (where regulated)
• Finance / Procurement (for cloud/vendor cost controls and contracts)

2) Role Mission

Core mission:
Establish, lead, and continuously improve a reliability engineering function that ensures production services meet defined availability, latency, and quality targets—while enabling high-velocity delivery through automation, standardization, and strong operational discipline.

Strategic importance:
The Head of SRE protects the company’s ability to scale and compete. Reliability is a product feature and a revenue enabler: stable systems reduce churn, increase conversion and retention, improve enterprise credibility, and minimize operational cost. This leader defines reliability commitments, institutionalizes SLO-based engineering, and ensures the organization can detect, respond to, and learn from incidents effectively.

Primary business outcomes expected: – Reduced frequency and severity of customer-impacting incidents – Measurable reliability via SLOs, error budgets, and operational KPIs – Faster, safer delivery (improved deployment frequency with lower change failure rate) – Improved operational efficiency (reduced toil; repeatable automation) – Strong incident readiness (clear ownership, on-call maturity, and resilience testing) – Predictable service performance (latency, throughput, capacity) aligned to growth plans

3) Core Responsibilities

Strategic responsibilities

1. Define the reliability strategy and multi-year roadmap aligned to business priorities, product growth, and platform maturity (e.g., SLO adoption, observability consolidation, resilience patterns).
2. Establish service reliability standards (SLOs/SLAs/SLIs, error budgets, production readiness requirements, operational acceptance criteria).
3. Shape the SRE operating model (engagement model with product teams, on-call model, incident severity taxonomy, reliability governance, shared ownership).
4. Lead reliability planning for scale including capacity management strategy, load forecasting, and performance targets tied to business events (launches, peak seasons, enterprise onboarding).
5. Own reliability investment decisions by quantifying risk and trade-offs; partner with Product/Engineering leadership to balance feature delivery with reliability work.
6. Build the business case for reliability initiatives (customer impact reduction, revenue protection, reduced toil, cloud cost optimization through efficiency).

Operational responsibilities

7. Own incident management and response maturity including on-call readiness, escalation paths, incident communications, and incident tooling.
8. Drive post-incident learning through blameless postmortems, corrective action tracking, systemic remediation, and trend-based prevention.
9. Establish operational health reporting for executives and stakeholders (reliability scorecards, SLO compliance, incident trends, top risks).
10. Implement production change governance (release risk management, change windows when appropriate, deployment health gates, rollback standards).
11. Ensure service continuity including backup/restore testing, disaster recovery planning, business continuity inputs, and resilience game days.

Technical responsibilities

12. Set observability direction across logs/metrics/traces, alert quality, dashboards, and standard instrumentation practices.
13. Sponsor and review reliability architecture for critical systems (multi-region strategies, fault isolation, redundancy, graceful degradation, rate limiting).
14. Drive automation and toil reduction (self-healing, automated runbooks, CI/CD safety checks, infrastructure automation).
15. Oversee performance engineering practices (load testing strategy, latency budgets, capacity testing, profiling and performance regression detection).
16. Guide platform reliability engineering (Kubernetes/platform stability, network reliability, storage reliability, dependency management, third-party risk).

Cross-functional / stakeholder responsibilities

17. Partner with Product, Support, and Customer Success to set availability expectations, incident communication standards, and customer escalation processes.
18. Collaborate with Security on secure-by-default operational controls (secrets management, access controls, auditability, vulnerability response during incidents).
19. Coordinate with Finance/Procurement on reliability-related vendor selection and cost controls (e.g., observability vendors, incident tooling, cloud spend optimization linked to efficiency).

Governance, compliance, or quality responsibilities

20. Ensure reliability controls meet governance needs (audit trails, access and change logging, evidence for SOC 2/ISO 27001 where applicable).
21. Define and enforce production readiness reviews for critical launches, including risk assessments and rollback/mitigation plans.
22. Maintain reliability documentation standards (runbooks, playbooks, service catalogs, ownership and escalation metadata).

Leadership responsibilities

23. Lead and grow the SRE organization (hiring, performance management, coaching, workforce planning, and career development).
24. Set technical direction and standards through principal-level leadership, design reviews, and clear decision frameworks.
25. Build a reliability culture that values learning, measurable outcomes, calm execution during incidents, and shared ownership across engineering.
26. Manage budgets and vendor relationships relevant to SRE tools, platform investments, and reliability programs.

4) Day-to-Day Activities

Daily activities

• Review production health dashboards (availability, latency, saturation, error rates) and top alerts; validate alert quality and actionability.
• Triage ongoing incidents or elevated error rates; support incident commander with decision-making and escalation when needed.
• Review and unblock high-impact reliability work (automation PRs, SLO definition, instrumentation, capacity fixes).
• Provide quick guidance to engineering teams on production readiness, risk, and operational constraints.
• Monitor key operational queues (postmortems due, corrective actions aging, high toil reports, pending access/change approvals).

Weekly activities

• Run or chair reliability review: SLO compliance, error budget burn, incident trend analysis, top risks, and prioritized remediation.
• Meet with platform and product engineering leads to align on reliability priorities, upcoming launches, and known constraints.
• Review on-call health metrics (pages per shift, time-to-acknowledge, escalations, after-hours load) and adjust staffing/rotations if needed.
• Conduct design/architecture reviews for high-risk changes (multi-region shifts, data migrations, major dependency integrations).
• Audit operational readiness: runbooks completeness, service ownership metadata, alert coverage, DR readiness status.

Monthly or quarterly activities

• Quarterly reliability planning: roadmap reprioritization, capacity forecasts, resilience testing schedule, reliability OKRs.
• Executive reporting: reliability scorecard, top incidents, systemic risks, program progress (SLO adoption, observability, DR).
• Vendor/tooling reviews: cost, coverage gaps, consolidation opportunities, renewal negotiations.
• Run game days or resilience exercises (fault injection, regional failover drills, dependency failure simulations).
• Mature governance: production readiness criteria adjustments, change management tuning, evidence collection improvements (if regulated).

Recurring meetings or rituals

• Incident review / postmortem review board (weekly)
• Reliability steering committee (monthly; VP Eng/CTO + Product + Security + Support)
• Platform architecture review (weekly/biweekly)
• SRE team planning (weekly) and retrospective (biweekly)
• On-call handoffs (per shift/rotation) and weekly on-call health review

Incident, escalation, or emergency work

• Act as executive-level escalation point for P0/P1 incidents:
• Ensure incident command structure is followed (IC, Ops, Comms, SME roles)
• Make trade-off calls (feature flags, traffic shifting, degradation, rollback)
• Align internal/external communications (status page, enterprise customers)
• Ensure follow-through on corrective actions and leadership reporting
• Participate in major incident communications to executive leadership with clear timeline, impact, mitigation, and next steps.

5) Key Deliverables

• Reliability strategy and roadmap (12–24 months) with prioritized initiatives and measurable outcomes
• SRE operating model documentation
• Engagement model (embedded/consultative), escalation paths, on-call principles
• Severity taxonomy and incident lifecycle definition
• SLO/SLI framework and templates
• SLO definitions per service tier
• Error budget policies and decision triggers
• Service catalog / ownership registry (system owners, dependencies, runbooks, on-call rotations, escalation contacts)
• Observability standards and reference implementations
• Standard dashboards (golden signals)
• Alert rules, alert quality rubric, paging policies
• Logging and tracing instrumentation guidelines
• Incident management program artifacts
• Incident commander guide, comms templates, war room procedures
• Postmortem template and corrective action tracking mechanism
• Production readiness checklist and review process
• Launch readiness gate requirements and evidence expectations
• Disaster recovery and resilience artifacts
• DR tiers, RTO/RPO targets, runbooks, and test schedules
• Game day plans and outcome reports
• Automation portfolio
• Automated runbooks, self-healing workflows, auto-scaling policies
• CI/CD safety checks (deployment health gates, canary analysis)
• Reliability dashboards and executive scorecards
• SLO compliance, incident metrics, operational toil, change risk
• Training and enablement
• On-call training curriculum, incident simulations, reliability engineering workshops

6) Goals, Objectives, and Milestones

30-day goals (orient, assess, stabilize)

• Build a clear picture of current reliability posture:
• Top services by business criticality and incident history
• Current monitoring coverage, alert quality, and on-call pain points
• Current change delivery performance (DORA + ops metrics)
• Confirm or establish:
• Incident severity definitions and escalation paths
• A minimal incident command process for P0/P1
• Identify top 5 systemic risks and present an initial mitigation plan to VP Eng/CTO.
• Align with Product and Support on incident communications expectations.

60-day goals (standardize, prioritize, execute early wins)

• Launch a reliability review cadence (weekly) and executive scorecard (monthly).
• Implement a postmortem program with measurable compliance:
• Target: ≥90% of P0/P1 incidents have postmortems within agreed SLA (e.g., 5 business days).
• Deliver initial SLOs for the most critical services (e.g., Tier 0/Tier 1).
• Reduce top sources of operational toil with 2–3 automation initiatives (e.g., repetitive deploy rollback steps, noisy alerts).

90-day goals (scale practices, embed with teams)

• Expand SLO coverage to a meaningful portion of critical services (e.g., 60–80% of Tier 0/Tier 1).
• Establish production readiness reviews for high-risk launches and infrastructure changes.
• Improve alert quality:
• Reduce paging noise (e.g., 20–40% reduction in non-actionable pages)
• Define paging policy and alert standards
• Present a 12–18 month reliability roadmap with staffing plan, tooling plan, and budget.

6-month milestones (institutionalize reliability)

• Mature incident command with trained incident commanders and clear rotations.
• Implement error budget policy that influences release decisions for critical services.
• Establish DR tiers and execute at least one DR test for each Tier 0 service (or equivalent criticality).
• Standardize observability baseline (metrics/logs/traces) across a defined percentage of services (e.g., 70% of Tier 1).

12-month objectives (business impact and scale readiness)

• Achieve measurable improvements in reliability outcomes:
• Reduced customer-impacting incident count and/or severity
• Improved MTTR and change failure rate
• Demonstrate consistent SLO compliance and transparent reporting:
• SLO attainment with agreed targets and exceptions managed via roadmap
• Reduce toil and improve engineering efficiency:
• Quantify toil reduction (hours saved), improved on-call health, and reduced repeat incidents
• Deliver resilience and scale improvements aligned to growth (new regions, major customer onboarding, peak events).

Long-term impact goals (18–36 months)

• Reliability becomes “built-in”:
• Product teams own SLOs with SRE partnership; SRE focuses on platform reliability, enablement, and hard problems
• Predictable operational performance:
• Mature capacity planning, resilience testing, and safe delivery practices
• A high-performing SRE org with strong talent pipeline and clear career architecture.

Role success definition

The role is successful when the organization can ship quickly without breaking production, reliability is measured and managed using SLOs and error budgets, incidents are handled with calm operational excellence, and reliability improvements are delivered as repeatable systems rather than heroic efforts.

What high performance looks like

• Reliability priorities are explicitly tied to business outcomes and risk reduction.
• Incident frequency and severity trend downward; repeat incidents are eliminated systematically.
• SRE is a trusted partner to Product and Engineering, enabling speed through standards and automation.
• On-call is sustainable, with low noise, clear ownership, and strong training.
• Tooling and platforms are cohesive, cost-effective, and widely adopted.

7) KPIs and Productivity Metrics

The Head of SRE should be measured on a balanced set of outcomes (customer impact), operational performance, delivery health, and organizational maturity. Targets vary by business, scale, and baseline maturity; example benchmarks below are illustrative and should be calibrated.

Metric name	What it measures	Why it matters	Example target / benchmark	Frequency
SLO attainment (per tier/service)	% of time service meets defined SLOs (availability/latency/error rate)	Converts “reliability” into measurable commitments	Tier 0: ≥99.9% availability; Tier 1: ≥99.5% (context-specific)	Weekly + monthly
Error budget burn rate	Rate of SLO budget consumption over time	Early warning for systemic issues; governs release pace	Burn rate thresholds trigger action (e.g., 2x over 1 week)	Weekly
Customer-impacting incidents (count)	# of incidents causing user-visible impact	Direct customer and revenue protection indicator	Downward trend QoQ; thresholds by service tier	Monthly
Incident severity mix	Distribution of P0/P1/P2 incidents	Reflects effectiveness of prevention and containment	Reduce P0/P1 proportion over time	Monthly
MTTA (Mean Time to Acknowledge)	Time from alert to human acknowledgement	Measures on-call responsiveness and alerting quality	P0 pages acknowledged <5 minutes (context-specific)	Weekly
MTTR (Mean Time to Restore)	Time to restore service after impact begins	Strong predictor of customer harm	Reduce by 20–40% in 6–12 months (baseline dependent)	Weekly + monthly
MTTD (Mean Time to Detect)	Time to detect incidents	Measures observability and alerting maturity	Reduce via better SLO-based alerting	Monthly
Change failure rate	% of deploys causing incidents/rollback/hotfix	Reliability of delivery pipeline	<10–15% (context-specific; high performers lower)	Monthly
Deployment frequency (critical services)	How often production changes ship	Paired with failure rate to show safe velocity	Increase without raising failure rate	Monthly
Production rollback time	Time to rollback/correct after bad change	Measures operational readiness	Minutes to <1 hour for common cases	Monthly
Paging noise ratio	% of pages that are non-actionable	Indicates alert hygiene and on-call sustainability	Reduce non-actionable pages by 30–50%	Weekly
On-call load (pages per shift)	Volume of pages per on-call rotation	Signals staffing, alerting, stability	Sustainable threshold defined per team (e.g., <10 pages/shift)	Weekly
Postmortem compliance	% of P0/P1 incidents with postmortem completed on time	Drives learning and accountability	≥90–95% within SLA	Monthly
Corrective action closure rate	% of actions closed by due date; aging distribution	Prevents repeat incidents and risk accumulation	≥80–90% on-time; minimal >60-day aging	Monthly
Repeat incident rate	Incidents caused by known unresolved issues	Measures systemic improvement	Downward trend; explicit reduction OKR	Monthly
Availability minutes / downtime	Total downtime minutes weighted by tier	A concrete measure of reliability for exec reporting	Tiered budget aligned to SLOs	Monthly
Latency p95/p99 (key endpoints)	Tail latency for user journeys	Impacts UX, conversion, and enterprise SLAs	Defined per product; track regressions	Weekly
Capacity risk index	Headroom vs forecast (CPU/mem/db connections/queue depth)	Prevents saturation-induced outages	Maintain headroom targets (e.g., 30% at peak)	Weekly
DR readiness coverage	% of critical services with tested DR plans	Reduces catastrophic risk	100% Tier 0 tested annually; Tier 1 tested per schedule	Quarterly
RTO/RPO achievement (tests)	Results of DR tests against targets	Validates recovery assumptions	Meet RTO/RPO for Tier 0	Quarterly
Toil percentage	% of SRE time spent on manual repetitive work	Core SRE productivity metric	<50% (Google SRE guideline)	Monthly/quarterly
Automation ROI	Hours saved / incidents prevented by automation	Justifies investment and prioritization	Track top automations; positive ROI	Quarterly
Cost-to-serve reliability overhead	Cost associated with running reliable services (tooling + infra overhead)	Balances reliability with financial efficiency	Stable or reduced unit cost while improving SLOs	Quarterly
Stakeholder satisfaction (Engineering/Product)	Survey-based trust and usefulness of SRE	Indicates partnership quality	≥4.2/5 with actionable feedback	Biannual/quarterly
Customer comms timeliness	Time to first status update for major incidents	Impacts trust and support load	First update <30 minutes (context-specific)	Monthly
Team health / retention	Attrition, engagement, burnout indicators	Ensures sustainability; on-call risk	Healthy retention; address burnout early	Quarterly
Hiring plan delivery	Progress vs staffing plan and skill coverage	Ensures capability to meet roadmap	Fill priority roles within planned timeline	Monthly

8) Technical Skills Required

Must-have technical skills

1. Distributed systems reliability fundamentals
   – Description: Failure modes, partial failures, backpressure, load shedding, idempotency, retries/timeouts
   – Use: Design reviews, incident analysis, reliability patterns
   – Importance: Critical
2. SLO/SLI/error budget design
   – Description: Defining measurable reliability objectives aligned to user journeys
   – Use: Service tiering, governance, prioritization, release decisions
   – Importance: Critical
3. Incident management and production operations
   – Description: Incident command, escalation, communications, postmortems
   – Use: Major incident leadership and program design
   – Importance: Critical
4. Observability (metrics, logs, traces)
   – Description: Instrumentation strategy, alerting, dashboards, tracing, correlation
   – Use: Faster detection/diagnosis, SLO monitoring, alert hygiene
   – Importance: Critical
5. Cloud infrastructure fundamentals (AWS/Azure/GCP)
   – Description: Compute, networking, storage, IAM, managed services patterns
   – Use: Reliability architecture, DR, scaling and cost trade-offs
   – Importance: Critical
6. Container orchestration and platform reliability
   – Description: Kubernetes basics, cluster operations concepts, workload scheduling, autoscaling
   – Use: Platform stability, rollout safety, capacity management
   – Importance: Important (Critical if Kubernetes-first org)
7. Infrastructure as Code (IaC) and automation
   – Description: Terraform/CloudFormation concepts, configuration management, repeatable provisioning
   – Use: Standard environments, DR automation, reducing drift
   – Importance: Important
8. CI/CD and safe delivery practices
   – Description: Progressive delivery, canaries, automated rollbacks, deployment health checks
   – Use: Reduce change risk and improve release velocity
   – Importance: Important
9. Performance and capacity engineering
   – Description: Load testing, bottleneck analysis, capacity forecasting, tuning
   – Use: Prevent saturation outages; scale readiness
   – Importance: Important
10. Security fundamentals for production operations
    – Description: Access control, secrets handling, audit logs, secure incident response
    – Use: Maintain security posture during operations and incidents
    – Importance: Important

Good-to-have technical skills

1. Service mesh / traffic management (e.g., Istio/Linkerd, Envoy)
   – Use: Resilience patterns, retries/timeouts, mTLS, traffic shifting
   – Importance: Optional (context-specific)
2. Chaos engineering / fault injection
   – Use: Validate resilience assumptions and DR readiness
   – Importance: Optional (growing in importance at scale)
3. Database reliability patterns (replication, failover, sharding basics)
   – Use: Reduce data-layer outages and improve recovery
   – Importance: Important (Optional in managed DB-heavy orgs)
4. Network engineering fundamentals (DNS, BGP basics, CDN patterns)
   – Use: Diagnose latency/outages; multi-region design
   – Importance: Optional
5. FinOps fundamentals
   – Use: Reliability-efficiency trade-offs, unit cost visibility, tooling cost governance
   – Importance: Optional (often valuable)

Advanced or expert-level technical skills

1. Reliability architecture for multi-region / active-active systems
   – Use: Business continuity, global scale, low downtime migrations
   – Importance: Important to Critical (scale-dependent)
2. Advanced observability engineering
   – Use: High-cardinality metrics strategy, tracing sampling, correlated alerting, SLO-based alerting at scale
   – Importance: Important
3. Expert incident analysis and systemic remediation
   – Use: Identify deep root causes, remove classes of failure, improve engineering practices
   – Importance: Critical
4. Platform engineering leadership
   – Use: Building internal platforms, golden paths, reducing cognitive load for product teams
   – Importance: Important
5. Operational data analysis
   – Use: Trend analysis on incident data, alert data, capacity signals; reliability forecasting
   – Importance: Important

Emerging future skills for this role (next 2–5 years; label as such)

1. AIOps / AI-assisted operations design
   – Use: Event correlation, anomaly detection, summarization, automated triage workflows
   – Importance: Optional (becoming Important)
2. Policy-as-code for reliability and compliance controls
   – Use: Enforce production readiness, security controls, and change policies automatically
   – Importance: Optional
3. Reliability for AI/ML and data products (where applicable)
   – Use: Model serving latency, drift monitoring, pipeline reliability, feature store dependencies
   – Importance: Context-specific
4. Supply-chain reliability and dependency risk management
   – Use: Third-party outages, API dependency SLOs, resilience contracts
   – Importance: Important (increasingly)

9) Soft Skills and Behavioral Capabilities

1. Crisis leadership and calm execution – Why it matters: Major incidents require clear thinking, prioritization, and stable leadership under pressure. – On-the-job: Establishes incident command quickly; keeps teams focused; avoids thrash. – Strong performance: Shorter time-to-mitigation, clear roles, consistent comms, minimal panic-driven changes.

2. Systems thinking – Why it matters: Reliability problems are usually systemic (architecture, process, incentives), not isolated bugs. – On-the-job: Looks beyond symptoms to contributing factors (alerting, testing gaps, ownership ambiguity). – Strong performance: Prevents repeat incidents; produces durable improvements and better decision frameworks.

3. Influence without overreach – Why it matters: SRE depends on shared ownership with product engineering, platform, and security. – On-the-job: Sets standards and drives adoption through partnership rather than “central team mandates.” – Strong performance: High SLO adoption, low friction, and clear decision-making despite matrixed teams.

4. Executive communication – Why it matters: Reliability is business risk; leaders need crisp, non-technical clarity. – On-the-job: Communicates impact, mitigation, and risk in plain language; quantifies trade-offs. – Strong performance: Leadership trust increases; funding and prioritization decisions are faster and better.

5. Coaching and talent development – Why it matters: SRE requires specialized skills and a strong learning culture to scale. – On-the-job: Mentors incident commanders, develops SRE leads, builds career paths and standards. – Strong performance: Strong internal pipeline, reduced burnout, and consistent delivery quality.

6. Customer empathy – Why it matters: Reliability is only meaningful in terms of user experience and business impact. – On-the-job: SLOs reflect user journeys; incident comms match customer expectations. – Strong performance: Better prioritization, fewer “green dashboards but unhappy customers” outcomes.

7. Operational rigor and consistency – Why it matters: Reliability improves through repeatable routines (reviews, postmortems, action tracking). – On-the-job: Enforces follow-through, builds habits, maintains operational hygiene. – Strong performance: Postmortem completion stays high; corrective actions don’t rot; metrics improve predictably.

8. Pragmatic risk management – Why it matters: Zero risk is impossible; the leader must choose smart investments. – On-the-job: Uses error budgets, service tiering, and cost/impact analysis to guide decisions. – Strong performance: Reliability improves without paralyzing delivery; fewer surprise risks.

9. Conflict navigation – Why it matters: Release constraints, incident ownership, and prioritization often create tension. – On-the-job: Mediates between product urgency and operational safety; establishes fair governance. – Strong performance: Decisions feel consistent and principle-driven; fewer escalations and “blame cycles.”

10. Data-driven management – Why it matters: Reliability programs fail when they rely on anecdotes rather than measurable outcomes. – On-the-job: Uses dashboards and trends to prioritize work and evaluate effectiveness. – Strong performance: Investments align to impact; reliability metrics are trusted and actionable.

10) Tools, Platforms, and Software

Tools vary widely by company maturity and stack. The Head of SRE should be fluent in categories and capable of selecting/standardizing platforms.

Category	Tool / platform	Primary use	Common / Optional / Context-specific
Cloud platforms	AWS / Azure / GCP	Hosting compute, storage, networking; managed services	Common
Container & orchestration	Kubernetes	Workload orchestration, scaling, service resilience patterns	Common (in modern stacks)
Container runtime/registry	Docker, ECR/GCR/ACR	Build and distribute container images	Common
IaC	Terraform	Provisioning infrastructure consistently	Common
IaC (alt)	CloudFormation / ARM / Pulumi	Cloud-native IaC alternatives	Context-specific
Config management	Ansible / Chef / Puppet	Configure hosts/services; legacy environments	Optional
CI/CD	GitHub Actions / GitLab CI / Jenkins	Build/test/deploy automation	Common
Progressive delivery	Argo Rollouts / Flagger / Spinnaker	Canary/blue-green, automated analysis	Optional (context-specific)
GitOps	Argo CD / Flux	Declarative deployment and drift control	Optional
Observability (metrics)	Prometheus	Metrics collection and alerting base	Common
Observability (dashboards)	Grafana	Dashboards and visualization	Common
Observability suite	Datadog / New Relic / Dynatrace	Unified metrics/traces/logs, APM	Common (vendor choice varies)
Logging	Elastic (ELK) / OpenSearch	Log aggregation and search	Common
Logging (enterprise)	Splunk	Enterprise logging, security + ops analytics	Common (larger enterprises)
Tracing	OpenTelemetry	Standard instrumentation and trace export	Common (increasingly)
Error tracking	Sentry	App-level error monitoring	Optional
Incident management	PagerDuty / Opsgenie	On-call scheduling, paging, escalations	Common
Status page	Statuspage / In-house	Customer-facing incident communication	Common
ITSM	ServiceNow / Jira Service Management	Incident/problem/change records (ITIL-aligned)	Context-specific
Collaboration	Slack / Microsoft Teams	Incident coordination, comms	Common
Documentation	Confluence / Notion	Runbooks, postmortems, standards	Common
Source control	GitHub / GitLab / Bitbucket	Code collaboration, reviews, audit	Common
Secrets management	HashiCorp Vault / AWS Secrets Manager	Manage secrets securely	Common
Policy-as-code	Open Policy Agent (OPA) / Kyverno	Enforce cluster/deploy policies	Optional
Security scanning	Snyk / Trivy	Image/dependency scanning	Common
Vulnerability mgmt	Tenable / Wiz (cloud security)	Cloud posture and vulnerability management	Optional (context-specific)
Load testing	k6 / Gatling / JMeter	Performance/load testing	Optional
Feature flags	LaunchDarkly / ConfigCat	Safer releases, controlled rollouts	Optional
Messaging/streaming	Kafka / SQS / Pub/Sub	Asynchronous workloads; reliability implications	Context-specific
Databases	Postgres / MySQL; DynamoDB/Spanner	Data layer dependencies for reliability	Context-specific
Analytics	BigQuery / Snowflake	Reliability analytics, event correlation	Optional
Automation/scripting	Python / Go / Bash	Tooling, runbook automation, integrations	Common
Project management	Jira	Reliability program execution	Common

11) Typical Tech Stack / Environment

The Head of SRE role is highly sensitive to scale and architecture. A conservative, broadly applicable modern software-company environment typically includes:

Infrastructure environment

• Public cloud-first (AWS/Azure/GCP) with:
• Multi-account/subscription structure (prod/non-prod separation)
• VPC/VNet-based networking; load balancers; WAF/CDN (context-specific)
• Kubernetes-based compute for microservices; some managed services (databases, queues)
• IaC-managed infrastructure with automated provisioning and drift detection (maturity-dependent)
• Hybrid/legacy components possible (VMs, on-prem) in enterprise contexts

Application environment

• Microservices and APIs (REST/gRPC), plus some monolith components in transition
• Event-driven components (Kafka/queues) where scale demands it
• Critical user journeys defined (login/auth, checkout/billing, search, messaging, etc.) to anchor SLOs

Data environment

• Mix of relational databases and managed NoSQL, caching (Redis), object storage
• Data pipelines (ETL/ELT) that affect product experiences (recommendations, reporting) in some companies
• Backups, replication, failover and migration strategies as part of reliability posture

Security environment

• SSO + RBAC; least privilege IAM
• Secrets management and key rotation expectations
• Audit logging and evidence collection (especially for SOC 2/ISO requirements)
• Coordinated vulnerability response and patch cadence integrated with change management

Delivery model

• CI/CD pipelines supporting frequent releases
• Progressive delivery patterns (feature flags, canaries) where mature
• “You build it, you run it” culture variants:
• Shared on-call with product teams, SRE enabling and handling platform components
• Or SRE as primary on-call for infra/platform plus consultative partnership for apps

Agile or SDLC context

• Agile teams (Scrum/Kanban variants) with quarterly planning
• Reliability work managed as a portfolio:
• Mix of roadmap initiatives, interrupts (incidents), and foundational platform work
• Strong dependency management and prioritization needed to prevent reliability debt accumulation

Scale or complexity context

• Common to support:
• Multiple environments (dev/stage/prod)
• Multiple regions or at least multi-AZ
• External dependencies (payment gateways, identity providers, cloud-managed services)

Team topology

• SRE org often includes:
• Incident/operations enablement (program + tooling)
• Observability platform (central instrumentation/tooling)
• Platform reliability (Kubernetes, networking, core runtime)
• Embedded/partner SREs aligned to critical product domains (optional)
• Works closely with Platform Engineering; sometimes SRE and Platform are the same org with different missions.

12) Stakeholders and Collaboration Map

Internal stakeholders

• CTO / VP Engineering (manager and executive sponsor)
• Collaboration: reliability strategy, investment decisions, executive escalation
• Decision authority: final prioritization trade-offs; budget and org design approvals
• Engineering Directors / Product Engineering Leads
• Collaboration: service ownership, SLOs, production readiness, remediation prioritization
• Escalation: repeated reliability issues, launch risk, error budget breaches
• Platform Engineering / Infrastructure
• Collaboration: shared platform roadmap, resilience patterns, cluster/cloud stability
• Escalation: platform-level outages, capacity constraints, systemic infra risk
• Security / CISO org
• Collaboration: secure operations, incident response coordination, audit evidence
• Escalation: security incidents, access breaches, compliance gaps
• Product Management
• Collaboration: availability promises, customer commitments, roadmap trade-offs
• Escalation: customer-impacting reliability risks affecting launches/SLAs
• Customer Support / Customer Success
• Collaboration: incident comms, customer escalations, root-cause summaries
• Escalation: high-impact customers, enterprise SLAs, repeated issues
• Data/Analytics Engineering (if applicable)
• Collaboration: data pipeline reliability, monitoring, incident response for data products
• Escalation: late/incorrect data affecting customers
• Finance/Procurement
• Collaboration: vendor contracts (PagerDuty/Datadog/Splunk), cost governance
• Escalation: tool spend spikes, cloud cost events related to incidents or scaling

External stakeholders (as applicable)

• Cloud provider support (AWS/Azure/GCP) for P0 escalations and service events
• Key vendors (observability, incident tooling, CDN) for reliability issues and renewals
• Enterprise customers (via CSM/Support) during critical incidents or SLA reviews
• Auditors / compliance partners in regulated contexts

Peer roles

• Head/Director of Platform Engineering
• Head of Security Engineering / SecOps
• Director of Engineering (Product domains)
• Head of Architecture / Principal Architect (where present)
• Head of Customer Support Operations (for incident comms alignment)

Upstream dependencies

• Product roadmap and launch schedule
• Architecture decisions and technical debt backlog
• CI/CD maturity and test coverage
• Cloud networking and identity standards
• Vendor reliability and third-party integrations

Downstream consumers

• Product engineering teams consuming SRE standards, tooling, and guidance
• Support/CS consuming incident updates and postmortem summaries
• Executives consuming risk reports and reliability scorecards
• Customers consuming SLO/availability commitments (directly or indirectly)

Nature of collaboration

• Co-ownership model: SRE defines standards and provides platforms; product teams own service health with SRE partnership.
• Advisory + enforcement: SRE advises early in design and enforces critical production readiness gates for Tier 0 services.
• Shared incident leadership: SRE leads incident process; SMEs come from service-owning teams.

Typical decision-making authority

• SRE owns incident process, reliability standards, and tooling direction (within budget).
• Product engineering owns feature roadmap and service code changes, constrained by error budgets and production readiness requirements.

Escalation points

• Error budget breach or sustained SLO burn without remediation plan
• Repeated incidents from same root cause or missed corrective actions
• On-call health risks (burnout, unsafe staffing)
• Major launch readiness concerns (incomplete rollback/observability/DR)

13) Decision Rights and Scope of Authority

Decision rights should be explicit to prevent confusion during incidents and planning.

Can decide independently (typical)

• Incident process design:
• Severity definitions, roles (IC/Comms/SMEs), escalation runbooks
• Operational standards:
• Postmortem templates, corrective action tracking requirements
• Alerting standards (what pages vs tickets), on-call hygiene requirements
• Observability conventions:
• Dashboard standards, instrumentation guidelines, SLO measurement methods
• SRE internal priorities and execution approach (within agreed roadmap)
• Selection of team-level practices:
• Game day cadence, training curricula, incident simulations

Requires collaboration / alignment (peer approval)

• Service-tiering model and SLO targets (requires Engineering + Product agreement)
• Production readiness gates for product teams (shared governance)
• Deployment policy changes that affect engineering throughput (e.g., gating strategy)
• On-call model changes impacting product teams (shared ownership expectations)
• Cross-org tooling changes (e.g., switching observability stack) due to broad impact

Requires VP/CTO or executive approval

• Budget increases and major vendor contracts/renewals beyond thresholds
• Org structure changes (new teams, significant staffing changes)
• Major architecture transformations (e.g., multi-region redesign) requiring substantial investment
• Reliability commitments in enterprise contracts (SLA terms) when risk is material
• Any policy that materially changes risk posture or business commitments (e.g., formal change freeze policy)

Budget, architecture, vendor, delivery, hiring, compliance authority

• Budget: Owns/controls SRE program/tooling budgets within delegated limits; proposes annual budget.
• Architecture: Influences and approves reliability architecture for Tier 0 services; final architecture authority may rest with Architecture Council/CTO depending on org.
• Vendors: Leads evaluation and recommendation; procurement signs contracts; security reviews risk.
• Delivery: Can pause launches for Tier 0 services if production readiness criteria are not met (should be defined and agreed in governance).
• Hiring: Owns hiring decisions for SRE org; influences hiring profiles for reliability champions in product/platform teams.
• Compliance: Ensures operational controls and evidence exist; partners with Security/GRC for formal compliance ownership.

14) Required Experience and Qualifications

Typical years of experience

• 12–18+ years in software engineering, systems engineering, infrastructure, or reliability engineering
• 5–8+ years leading technical teams/managers (scale-dependent)
• Substantial on-call/production operations experience is expected (hands-on background)

Education expectations

• Bachelor’s degree in Computer Science, Engineering, or equivalent practical experience is common.
• Advanced degrees are optional; not typically required.

Certifications (relevant but not mandatory)

Labeling reflects real-world variability: – Common/recognized (optional): – Kubernetes certifications (CKA/CKAD) – Optional – Cloud certifications (AWS Solutions Architect, Azure Architect, GCP Professional Cloud Architect) – Optional – Context-specific (regulated/enterprise): – ITIL foundations – Context-specific – Security certs (e.g., CISSP) – Optional (more relevant if also leading operational security response)

Certifications should not substitute for demonstrated experience in reliability leadership, incident management, and scaling systems.

Prior role backgrounds commonly seen

• SRE Manager / Director of SRE
• Principal/Staff SRE with leadership responsibilities
• Head/Director of Platform Engineering with strong operations focus
• Infrastructure Engineering Manager with deep incident management experience
• Production Engineering leader (in product companies with “prod eng” orgs)

Domain knowledge expectations

• Strong grounding in:
• Distributed systems reliability
• Observability and operational metrics
• Cloud operations and scalable infrastructure
• Release engineering and safe delivery practices
• Domain specialization (e.g., fintech, healthcare) is context-specific and primarily affects compliance, audit, and SLA expectations.

Leadership experience expectations

• Proven ability to:
• Build and scale teams (hiring, leveling, performance management)
• Set strategy and execute multi-quarter roadmaps
• Influence product engineering behavior and standards
• Lead through incidents with executive communication responsibilities
• Establish governance that improves outcomes without crushing velocity

15) Career Path and Progression

Common feeder roles into this role

• Director of SRE / SRE Manager (multi-team scope)
• Principal/Staff SRE (with cross-org leadership and program ownership)
• Director of Platform Engineering (when SRE and Platform functions converge)
• Senior Engineering Manager, Infrastructure/Operations (with modern SRE practices)

Next likely roles after this role

• VP Engineering (Platform/Infrastructure)
• VP Reliability / VP Platform (in larger organizations)
• CTO (in smaller or reliability-centric businesses)
• Head of Engineering Operations / Production Engineering (org-dependent)
• GM/Head of Technical Operations (in enterprises blending IT + product ops)

Adjacent career paths

• Security leadership: Head of SecOps / Production Security (if incident response and controls are a major focus)
• Architecture leadership: Head of Architecture / Chief Architect (if the role leans heavily into reliability architecture at scale)
• FinOps/platform economics leadership: if cost-to-serve and platform efficiency become primary mandates

Skills needed for promotion (to VP-level scope)

• Portfolio and investment leadership: tying reliability investments directly to revenue and strategic risk
• Multi-org operating model design (platform + product + security alignment)
• Strong executive presence with board-level communication (for major outages and risk)
• Vendor strategy and contract negotiation at scale
• Talent system building: career ladders, succession planning, leadership bench development

How this role evolves over time

• Early phase: stabilize incidents, improve observability, define SLOs, reduce toil.
• Mid phase: embed reliability into SDLC (gates, golden paths), mature DR, reduce systemic risk.
• Mature phase: SRE becomes an enablement function; product teams own reliability; SRE focuses on platform resiliency, complex incidents, and continuous improvement.

16) Risks, Challenges, and Failure Modes

Common role challenges

• Ambiguous ownership: “Who owns production?” confusion between SRE, platform, and product teams.
• Tool sprawl: multiple monitoring/logging stacks creating inconsistent visibility and high costs.
• Alert fatigue: noisy paging causing burnout and missed real incidents.
• Prioritization conflict: reliability work loses to feature delivery without clear governance (error budgets, tiering).
• Legacy constraints: older systems without good instrumentation or automation increase toil.
• Inconsistent incident discipline: ad hoc responses, poor comms, and weak postmortem follow-through.

Bottlenecks

• Limited SRE capacity leading to “ticket queue SRE,” slowing product teams.
• Lack of standardized instrumentation blocking meaningful SLO measurement.
• Slow CI/CD pipelines and weak test coverage increasing change failure rate.
• Lack of environment parity or IaC maturity causing configuration drift and surprises.

Anti-patterns

• SRE as the “prod janitor”: SRE becomes the default owner of every operational problem.
• Hero culture: rewarding firefighting over prevention and automation.
• Metric theater: dashboards that look good but don’t reflect user journeys or real reliability.
• Blameful postmortems: discourages learning and hides risks.
• Over-governance: excessive approvals and process that reduces delivery speed without improving outcomes.
• Under-investing in DR: written plans without tested execution.

Common reasons for underperformance

• Insufficient influence across engineering leadership; inability to drive adoption of standards.
• Over-focus on tooling instead of outcomes (buying platforms without behavior change).
• Poor prioritization discipline; chasing symptoms rather than root causes.
• Weak talent development; burnout and attrition in on-call roles.
• Lack of executive alignment on reliability trade-offs and customer commitments.

Business risks if this role is ineffective

• Increased downtime and customer churn; lost revenue and damaged brand trust
• Failure to win/retain enterprise customers due to weak SLA credibility
• Slower delivery due to unstable production and constant firefighting
• Higher cloud and operational costs due to inefficiency and lack of automation
• Regulatory/compliance exposure if evidence and controls are inadequate (context-specific)

17) Role Variants

This role is consistent in mission but varies significantly by maturity, industry, and operating model.

By company size

• Startup / scale-up (Series A–C-ish):
• Head of SRE may be the first dedicated reliability leader.
• More hands-on: building foundational observability, on-call, IaC, and incident processes.
• Focus: stabilize and enable rapid growth; reduce existential outage risk.
• Mid-size SaaS:
• Balances strategy with execution through teams.
• Strong emphasis on SLOs, error budgets, and progressive delivery.
• Large enterprise / hyperscale org:
• More governance, more stakeholders, more specialization (observability, incident response, capacity).
• Strong vendor management and compliance evidence needs.

By industry

• B2C consumer apps:
• Focus on peak traffic events, tail latency, and global performance.
• Often heavy on CDNs, mobile performance, and experimentation safety.
• B2B SaaS / enterprise:
• Strong SLA expectations, change management maturity, customer comms discipline.
• More integration reliability (SSO, APIs, data pipelines).
• Regulated (fintech/health/critical infrastructure):
• Higher rigor: audit evidence, change controls, DR testing, access governance.
• Incident handling includes regulatory timelines and formal reporting (context-specific).

By geography

• Global organizations:
• Need follow-the-sun support models, region-aware incident comms, multi-region routing.
• Single-region organizations:
• May focus first on multi-AZ and foundational redundancy before full multi-region.

Product-led vs service-led company

• Product-led SaaS:
• SLOs map to product journeys; reliability is a product feature.
• More collaboration with Product and UX.
• Service-led / internal IT org:
• SLOs map to internal services; may align more with ITIL/ITSM practices.
• More formal change and incident records; service catalogs are central.

Startup vs enterprise operating model

• Startup: fewer processes, more direct ownership; faster changes; higher initial incident risk.
• Enterprise: higher governance, more approvals, more complex stakeholder management; reliability standards must be negotiated and enforced carefully.

Regulated vs non-regulated environment

• Regulated: evidence collection, access logging, separation of duties, formal DR and change controls are stronger.
• Non-regulated: more flexibility, but still benefits from operational rigor; governance can be lighter-weight and principle-driven.

18) AI / Automation Impact on the Role

Tasks that can be automated (now and near-term)

• Alert enrichment and routing: automatic inclusion of recent deploys, runbook links, ownership tags, and likely causes.
• Event correlation: grouping related alerts into single incidents; reducing noise.
• Log/trace summarization: generating hypotheses and summaries for responders.
• Automated remediation for known issues: restart loops, cache flushes, scaling actions, traffic shifts (with guardrails).
• Postmortem drafting assistance: timelines from chat/incident tools, suggested contributing factors, action item templates.
• SLO reporting automation: generation of weekly scorecards and error budget updates.

Tasks that remain human-critical

• Defining reliability strategy and prioritization tied to business value and risk appetite.
• High-stakes incident leadership: decision-making under uncertainty, cross-team coordination, customer/executive communications.
• Architecture trade-offs: resilience vs cost vs complexity requires judgment and context.
• Culture and behavior change: driving shared ownership, blameless learning, and adoption of standards.
• Ethical and risk oversight: ensuring automation does not create unsafe changes or obscure accountability.

How AI changes the role over the next 2–5 years

• The Head of SRE will increasingly manage a socio-technical system that includes:
• AI-assisted triage workflows
• Automated change risk scoring (based on deploy diff, service health, historical patterns)
• Predictive capacity management and anomaly detection
• Expectations shift from “build dashboards” to “build closed-loop operations”:
• Detect → diagnose → remediate → learn, with automation where safe
• Tooling governance becomes more important:
• Model/tool evaluation, data privacy, auditability, and avoiding over-automation that increases systemic risk

New expectations caused by AI, automation, or platform shifts

• Ability to implement guardrails (policy-as-code, approval workflows) around automated actions.
• Stronger emphasis on data quality (telemetry consistency, service ownership metadata) to make automation reliable.
• Increased cross-functional partnership with Security and Legal for AI tool usage and data handling (context-specific).
• Leadership in adopting OpenTelemetry and standard schemas to enable scalable correlation and AI-assisted operations.

19) Hiring Evaluation Criteria

What to assess in interviews

• Reliability leadership depth
• Has the candidate owned reliability outcomes (not just tooling)?
• Can they articulate an operating model that scales?
• Incident leadership experience
• Evidence of leading major incidents, establishing incident command, and improving MTTR/MTTD.
• SLO and error budget competency
• Can they define meaningful SLIs and SLOs tied to user journeys?
• Can they operationalize error budgets into planning and release governance?
• Observability strategy
• Ability to standardize instrumentation and reduce alert fatigue.
• Architecture and systems thinking
• Can they identify systemic issues and propose durable improvements?
• Org design and talent development
• Hiring plan, leveling, coaching approach, on-call sustainability.
• Executive stakeholder management
• Clarity in communication, credible risk framing, and decision trade-off articulation.

Practical exercises or case studies (recommended)

1. Incident case study (60–90 minutes) – Provide a scenario: elevated error rate, partial outage, recent deploy, noisy alerts. – Ask candidate to:
   • Establish incident command roles and first actions
   • Decide what to rollback/disable/mitigate and why
   • Draft executive update (timeline, impact, next update time)
   • Propose postmortem focus areas and corrective actions
2. SLO design workshop (45–60 minutes) – Given a service description and key user journeys:
   • Define SLIs and SLOs
   • Propose alerting strategy (burn-rate, paging vs ticket)
   • Define error budget policy implications for release planning
3. Reliability roadmap prioritization (45–60 minutes) – Provide a backlog: observability consolidation, DR testing, Kubernetes upgrade, automation, performance improvements. – Ask for prioritization rationale, ROI framing, and staffing plan.
4. Org operating model design (30–45 minutes) – Choose: embedded SRE vs platform SRE vs centralized ops. – Ask how they would implement without creating bottlenecks.

Strong candidate signals

• Clear examples with metrics (MTTR reduced, paging noise reduced, SLO coverage increased).
• Demonstrates balanced mindset: customer impact, engineering velocity, and sustainability.
• Has built durable mechanisms: governance, standards, automation, training programs.
• Can explain trade-offs without dogma; adapts SRE principles pragmatically to context.
• Strong communication artifacts: crisp incident updates, clear strategy docs, effective stakeholder narratives.

Weak candidate signals

• Tool-first thinking without business outcomes (“We installed X” rather than “We reduced incidents by Y”).
• Blurry accountability model (“SRE owns all production problems”).
• Limited incident leadership exposure; avoids high-pressure responsibility.
• Overly rigid process orientation that would slow delivery without measurable benefit.
• Dismissive of product/customer needs or unable to translate reliability into business value.

Red flags

• Blame-centric postmortem mindset; focuses on individual fault rather than system improvement.
• Normalizes unsustainable on-call (“burnout is part of the job”).
• Unwilling to be accountable for outcomes; only comfortable as advisor.
• Overconfidence in automation without guardrails; proposes auto-remediation broadly with weak risk controls.
• Cannot articulate how to measure reliability beyond uptime.

Scorecard dimensions (for structured evaluation)

Use a consistent rubric (e.g., 1–5) across interviewers.

Dimension	What “excellent” looks like	Evidence sources
Reliability strategy & roadmap	Connects reliability investments to business outcomes; realistic sequencing	Strategy discussion, roadmap exercise
Incident leadership	Runs incident command effectively; strong comms; learns and improves	Incident case study, past examples
SLO/error budget mastery	Defines meaningful SLOs; uses error budgets to drive behavior	SLO workshop, prior implementations
Observability & alerting	Standardizes telemetry; reduces noise; improves detection and diagnosis	Architecture discussion, metrics examples
Architecture & systems thinking	Identifies systemic failure modes; proposes resilient designs	Design review simulation
Automation & toil reduction	Targets high-ROI automation; reduces manual ops sustainably	Examples, automation portfolio discussion
Cross-functional influence	Gains adoption across product teams; avoids bottlenecks	Collaboration stories, stakeholder references
Talent & org leadership	Builds healthy on-call culture; develops leaders and ICs	People leadership interview
Executive communication	Clear, concise risk framing; strong written/verbal updates	Incident comms exercise
Operational governance	Right-sized controls; improves outcomes without bureaucracy	Operating model design exercise

20) Final Role Scorecard Summary

Category	Summary
Role title	Head of Site Reliability Engineering
Role purpose	Lead the reliability engineering function to ensure production services meet measurable availability/performance targets while enabling rapid, safe delivery through automation, observability, incident excellence, and resilient architecture.
Top 10 responsibilities	1) Define reliability strategy and roadmap 2) Establish SLO/SLI/error budget framework 3) Own incident management maturity 4) Drive postmortems and corrective actions 5) Set observability and alerting standards 6) Reduce toil via automation 7) Partner with product teams on production readiness and launch risk 8) Lead DR and resilience testing programs 9) Provide executive reliability reporting and risk management 10) Build and lead the SRE organization (hiring, coaching, budgeting).
Top 10 technical skills	1) Distributed systems reliability 2) SLO/SLI/error budgets 3) Incident management/command 4) Observability (metrics/logs/traces) 5) Cloud infrastructure (AWS/Azure/GCP) 6) CI/CD and progressive delivery principles 7) IaC and automation (Terraform; scripting) 8) Kubernetes/platform reliability (context-dependent) 9) Performance/capacity engineering 10) Security fundamentals for production operations.
Top 10 soft skills	1) Crisis leadership 2) Systems thinking 3) Influence and stakeholder alignment 4) Executive communication 5) Coaching and talent development 6) Operational rigor 7) Pragmatic risk management 8) Customer empathy 9) Conflict navigation 10) Data-driven decision-making.
Top tools or platforms	Cloud (AWS/Azure/GCP), Kubernetes, Terraform, CI/CD (GitHub Actions/GitLab/Jenkins), Observability (Prometheus/Grafana + Datadog/New Relic/Dynatrace), Logging (ELK/OpenSearch/Splunk), Paging (PagerDuty/Opsgenie), OTel, ServiceNow/JSM (context-specific), Slack/Teams, Confluence/Notion.
Top KPIs	SLO attainment, error budget burn, customer-impacting incidents, MTTR/MTTD/MTTA, change failure rate, paging noise, postmortem compliance, corrective action closure rate, repeat incident rate, DR readiness coverage/RTO-RPO achievement, toil percentage, stakeholder satisfaction.
Main deliverables	Reliability strategy/roadmap, SRE operating model, SLO templates and service tiering, service catalog/ownership registry, observability standards, incident program artifacts (playbooks, comms templates), postmortem system with action tracking, DR plans and test reports, automation/runbooks, executive reliability dashboards and scorecards, training curriculum.
Main goals	Stabilize production operations; institutionalize incident command and learning; implement SLO/error budget governance; reduce customer-impacting incidents and MTTR; improve safe delivery; reduce toil and improve on-call sustainability; mature DR/resilience readiness.
Career progression options	VP Engineering (Platform/Infrastructure), VP Platform/Reliability, CTO (smaller org), Head of Production Engineering/Engineering Operations, or adjacent paths into Security Operations leadership or Architecture leadership (context-dependent).