Release Management Is a Risk Function - Measure the System, Not the Meeting

This is Post 1 of 12 in Risk, Readiness, Reality - a Null Expected series on modern release leadership, readiness signals, and delivery risk in complex software environments.

📋 A lot of release governance still runs on ritual. People gather. Status turns green enough. Someone asks whether everyone is comfortable. The decision lands where it usually lands - with the loudest voice, the most senior person, or the team best able to defend itself in the room.

That is not governance. It is folklore.

A release process is not just a sequence of approvals, checklists, and date changes. It is a risk model, whether you admit it or not. Every release decision already makes a set of assumptions about speed, exposure, recoverability, dependency health, operational readiness, and what level of failure the organisation is willing to tolerate. The question is not whether you have a risk model. The question is whether it is visible, measurable, and good enough to trust. DORA now frames software delivery performance through throughput and instability, and positions those signals as a way to understand delivery performance across different technologies and contexts.

This is where a lot of release management still gets stuck in the past. Readiness is treated as a meeting outcome rather than a property of the system. Teams arrive with updates, someone compresses them into red-amber-green language, and the room mistakes tidy reporting for actual control. But a clean status summary does not tell you how fast change moves, how often it lands safely, how often it breaks, or how hard recovery is when it does. It mostly tells you how well people can narrate uncertainty.

📊 That gap matters because the strongest delivery organisations are not the ones with the most ceremonies. They are the ones with the clearest signals. DORA's current guidance is blunt on this point: throughput tells you how many changes your system can move, instability tells you how well those changes go, and the metrics are meant to be tracked over time so teams can see whether performance is improving or degrading. Just as importantly, DORA's research continues to show that speed and stability are not a forced trade-off for most teams. High performers do well across both.

That should challenge one of the laziest assumptions in software delivery: that slowing down is automatically the responsible move. It often is not. Sometimes a slow release process is simply a poorly instrumented one. Sometimes it is a dependency problem wearing a governance badge. Sometimes it is a control model that cannot tell the difference between a risky change and a badly understood one. When leaders respond to uncertainty by adding more meetings, more sign-offs, and more manual coordination, they may feel safer while making the system harder to read.

❓The better question is not, "Do we feel confident?" It is, "What evidence says this change is low risk, what evidence says it is not, and what does the system usually do when changes like this go live?"

That is a different standard. It moves the discussion away from confidence theatre and toward decision quality.

It also changes what release leadership is for. If you are still treating release management as administrative coordination, this shift will feel uncomfortable. But the job is getting more strategic, not less. Modern delivery performance measures are system-level on purpose. Google Cloud's DORA research argues that these measures focus on system outcomes and help avoid the usual trap of functions optimising locally at the expense of overall results. That matters because most release risk is not created by a single team in isolation. It is created in the joins - handoffs, dependencies, late integration, weak rollback paths, unclear ownership, brittle environments, and poor recovery capability.

🧩 This is also why release leaders should stop accepting aggregated comfort metrics as proof of control. DORA is clear that context matters, and that delivery metrics are best suited to measuring one application or service at a time. Blend too much together and you lose the signal that matters. A large platform with heavy compliance demands should not be judged the same way as a low-risk internal service. A team managing a high-volume customer journey should not disappear inside a portfolio average. Governance gets weaker, not stronger, when measurement becomes too abstract to support decisions.

🚦 The interesting part is that this is not a call for reckless speed. Quite the opposite. DORA defines continuous delivery as the ability to release changes on demand quickly, safely, and sustainably, and it explicitly notes that these principles apply beyond web apps, including regulated and safety-critical domains. In other words, mature delivery is not about pushing faster for the sake of it. It is about being able to change without guessing.

That distinction matters for senior leaders because it reframes what good control looks like. Good control is not a crowded go-no-go call. Good control is a delivery system that produces evidence early enough, clearly enough, and consistently enough that the decision is grounded before the meeting starts. The meeting might still matter, especially for high-risk changes. But it should be where evidence is interpreted, not where evidence is invented.

🔧 So what should change in practice?

First, stop using release status as the primary language of risk. A green release can still be sitting on slow recovery capability, unstable dependencies, or poor rollback options. An amber release can be perfectly shippable if the risk is well understood, tightly scoped, and operationally manageable.

Second, separate flow from failure. Review how quickly work moves and how often change causes pain as two related but distinct parts of the same picture. The point is not to worship metrics. The point is to expose the trade-offs your delivery system is actually making.

Third, treat every failed, delayed, or heavily negotiated release as data. Not as an isolated drama, and not as a blame exercise. As data. Which signal was missing? Which assumption failed? Which dependency was invisible until the end? Which control existed on paper but not in the system?

💡 That is where release management becomes useful to leadership. Not because it creates prettier dashboards, but because it turns delivery friction into decisions the organisation can act on.

📌 A practical place to start is a monthly release risk review for one service or product area at a time.

• Review four core signals together: lead time, deployment frequency, change fail rate, and recovery time. Do not discuss them as separate KPIs. Discuss what they say about the same system. See DORA's software delivery performance metrics.

• Bring one recent failed, delayed, or contentious release into the room. Map the problem to a missing signal, weak control, or structural dependency - not to a person.

• Ask one hard question: where is instability being created right now, and what is the next smallest change that would reduce it?

• Set one measurable improvement target for the next cycle. Then review it properly next month. DORA's guidance on organisational transformation is explicit here: understand the current condition in measurable terms, set targets, run experiments, and iterate in small steps rather than betting on one big transformation move.

That is a much better use of leadership time than another status round.

Release management does not become strategic because the title changes. It becomes strategic when it helps the organisation see risk clearly enough to make better delivery decisions under pressure. If your release process cannot show where risk is building, where instability is coming from, and what evidence supports the call, then it is not governance.

It is just ceremony with a calendar invite. 📆

Disclaimer: The perspectives expressed herein are personal interpretations intended to foster professional dialogue; they do not represent any official stance of current or former employers.