If an outage can move your stock price, why isn’t Reliability on the Board agenda?

Background: Though there is a lot of rhetoric from CXOs, by and large SRE (Site Reliability engineering) has been considered Operational and not strategic. Unlike Cyber Security, SRE as a discipline does not garner sufficient attention and focus leading to poor governance, half baked adoptions and questionable value realization. This brief note attempts to highlight the top reasons for this state of affairs and what it takes to get to the next level of maturity. Across industries, the cost of weak reliability practices is rarely confined to IT; it shows up as grounded aircraft from a data-center power failure, mass cancellations from an outdated crew-scheduling system, a widespread cloud outage triggered by an operational error at a major infrastructure provider, a global internet disruption caused by a DNS dependency failure, and a catastrophic software-update incident that knocked millions of endpoints offline and disrupted airlines, hospitals, banks, and retailers. Each of these events reflects the same underlying truth: when resilience is not engineered into SDLC, operations, and infrastructure, a single defect, misconfiguration, or dependency failure can rapidly become an enterprise-wide and even industry-wide crisis.This article is an extension of my previous article — https://medium.com/@svshyam/untangle-blockers-that-impede-site-reliability-engineering-sre-adoption-1980ef3db3e5?sharedUserId=svshyam

Top 5 Reasons

1. Structural Misalignment: Most of the enterprises are quite confused on where to position SRE. While some put SRE under Infra org, some under Platform engineering and some establish their own model such as embedded SRE. In most of the above situations, with no central team that has independent autonomy to oversee reliability practices, focus on reliability gets adopted in pockets.
2. Regulatory Compliance: While Cyber security garnered lots of attention from a Regulatory compliance standpoint, the same cannot be said about SRE. To cite a few, in the world of cyber security, we have generic standards such as ISO 27001, SOC2 and industry specific compliance requirements such as PCI, HIPAA etc. However, direct applicability to map compliance requirements for Reliability has not been straightforward.
3. Reliability not addressed holistically: As current SRE teams have limited sphere of influence and control, all aspects of reliability do not get addressed. This deprives organizations of the true value which SRE can provide. Though Product owners have high aspirations for reliability, without the commitment from engineering teams, the reliability related NFRs do not translate to reality and become wishful aspirations.
4. 3rd Party dependencies: Many of the critical services offered by enterprises are now heavily dependent on 3rd parties. Exclusion of reliability related clauses in contracts impacts service level assurances for the companies dependent on these 3rd parties.
5. Quantifying Reliability: While there are excellent mechanisms to monitor and measure reliability, these measures are rarely internalized beyond engineering teams. Unlike cyber risk or financial risk, which reach the Board in a quantified form, reliability has no equivalent index that leadership can track quarter over quarter.

What does it take:

1. Reliability Assurance Council: As team topologies are evolving, it may be quite some time before we have SRE organizations headed by CRO(Chief Reliability officer). In the interim, one of the approaches would be to establish a reliability council with members drawn from all the relevant parts of the organization. This council should identify all aspects of what SRE encompasses, draw the agenda and drive actions that result in measurable outcomes.

1. Board Level Reliability metrics: There is a need for exactly knowing where the organization fits in the overall SRE Maturity Index and the specific details of Reliability scores across all dimensions such as Business (User experience), Development and Operations including 3rd party dependencies. One of the foundational pillars of SRE is SLO and further details can be found in https://medium.com/@svshyam/the-ten-commandments-of-service-level-objectives-slo-8b8f1dfa03b?sharedUserId=svshyam
2. Industry wide initiatives: It is almost a quarter century now since Google pioneered SRE and its adoption in the current form. Fast forward — after ten years, the second edition of the SRE book is due for publication this year (2026) https://www.oreilly.com/library/view/site-reliability-engineering/9798341607675/ . To gain further momentum, we also need vendor neutral bodies, similar to SANS (sans.org) to further the cause of enabling and promoting SRE learning across organizations.

If you are a technology leader reading this, here is a simple test. Ask yourself what reliability number your Board saw last quarter. If the answer is none, that is where the journey begins — form the council, define the metric, and put Reliability on the agenda before the next outage puts it there for you.