Release Manager

The Release Manager is the person who controls the gate between software that has been written and software that runs in production. The gate has keys. The Release Manager has the keys. Everything else — the sprints, the ceremonies, the backlogs, the standups, the Gantt charts, the status reports — is theatre performed in front of a locked gate. The Release Manager decides when the gate opens. This makes the Release Manager either the most dangerous bottleneck in the organisation or the most valuable ally on any project, and the difference is not the role but the person.

The role is simple: manage releases. Coordinate deployments. Ensure that what goes to production has been tested, approved, and scheduled. Maintain the environments. Keep the calendar. Open the gate.

The power is not simple. In an enterprise running Water-Scrum-Fall — where the official deployment cadence is measured in months or quarters, where the Change Advisory Board meets fortnightly, where a release requires seventeen approvals and a risk assessment — the Release Manager is the person who determines whether software ships this quarter or next quarter. This is more power than most VPs have, exercised more quietly, with less visibility, and with greater consequence.

“The CEO sets the strategy. The CTO sets the architecture. The Release Manager sets the date. Of the three, only the date is real.”
— The Lizard, who deploys by blinking

The Two Release Managers

Every enterprise has encountered both.

The Gatekeeper

The Gatekeeper Release Manager believes the gate exists for a reason. The reason is risk. The gate prevents bad software from reaching production. The gate prevents untested changes from breaking the system. The gate prevents developers — who are, in the Gatekeeper’s cosmology, chaotic agents of destruction — from touching the thing that works.

The Gatekeeper is not wrong. Production systems have been broken by untested deployments. Databases have been corrupted by midnight hotfixes. The Gatekeeper has seen these things. The Gatekeeper has been paged for these things. The Gatekeeper’s caution is earned, not theoretical.

But the Gatekeeper’s solution — make the gate harder to open, less frequent, more documented, more approved — has a side effect: software does not ship. Features that are “done” in the sprint remain un-deployed for weeks or months. Bugs that are fixed in development persist in production because the release window is in Q3 and it is currently February. The Gatekeeper has eliminated the risk of bad deployments by eliminating deployments.

The Gatekeeper is a bottleneck shaped like safety.

The Enabler

The Enabler Release Manager believes the gate exists to be opened. Not recklessly — the Enabler has also been paged at midnight, has also seen databases corrupted, has also learned that production is sacred. But the Enabler’s conclusion is different: the solution to risky deployments is not fewer deployments but better deployments. Smaller. More frequent. More tested. More reversible.

The Enabler maintains the environments. The Enabler automates the pipeline. The Enabler creates the side door — the process by which a team that is ready to ship can ship, without waiting for the quarterly release window, without seventeen approvals, without the Change Advisory Board, because the Enabler has built a process that is safe enough to run weekly and has quietly arranged the permissions to allow it.

The Enabler is the Release Manager who believes software should run.

“The Gatekeeper asks: ‘What could go wrong?’ The Enabler asks: ‘What is going wrong by not deploying?’ Both are valid questions. Only one of them has a visible cost on the Grafana dashboard.”
— The Caffeinated Squirrel, who has been on both sides of the gate

The Conspiracy

At a famous camera manufacturer running a Water-Scrum-Fall ERP implementation, riclib was brought in to rescue a BI workstream that was producing five-week “sprints” of fiction. The rescue required one-week sprints. One-week sprints required weekly deployments. Weekly deployments required the gate to open every Friday.

The official process opened the gate every twenty-five weeks.

The Release Manager — an Enabler, a kindred spirit, a person who had gone into IT because he enjoyed software that runs — conspired. The conspiracy was quiet, professional, and effective: the Release Manager would open the gate every Friday for the small changes team. The official process would continue to exist on paper. The Change Advisory Board would continue to meet. The Gantt chart would continue to show quarterly releases. And every Friday, working software would flow through a side channel into production, tested by users against real spreadsheets, deployed by a Release Manager who had decided that the gate should serve the software, not the other way around.

Without the Release Manager, the rescue would have been a design exercise — a proposal, a PowerPoint, a discussion in the next steering committee. With the Release Manager, it was a deployment pipeline. Eight teams. Weekly releases. Working software. All of it flowing through a gate that was officially closed but practically open, managed by a person whose job title said “control” but whose instinct said “enable.”

“The most powerful person on the project was not the programme director, not the CTO, not the steering committee. It was the person with the keys to production. He opened the gate every Friday. Nobody told him to. Nobody told him not to. He just did it, because the software was ready and the users were waiting and the gate was his to open.”
— riclib, on the Release Manager who made the rescue possible

The DevOps Question

DevOps was supposed to eliminate the Release Manager. CI/CD pipelines automate the gate. Infrastructure as code removes the environment bottleneck. GitOps makes deployment a pull request. The gate becomes a script. The gatekeeper becomes unnecessary.

In theory.

In practice, the gate still exists. It has moved from a person to a pipeline, but the pipeline has approvals, and the approvals have owners, and the owners have meetings, and the meetings have agendas, and the Release Manager — now called “Platform Engineer” or “DevOps Lead” or “SRE” — still holds the keys. The title changed. The gate did not.

The good ones still open it on Friday.

Measured Characteristics

Official title:                             Release Manager
Actual power:                               controls whether software happens
Power relative to CTO:                      greater (the CTO decides what; the RM decides when)
Types:                                      2 (Gatekeeper, Enabler)
Gatekeeper deployment cadence:              quarterly (if you're lucky)
Enabler deployment cadence:                 weekly (if you ask nicely)
Conspiracy deployment cadence:              every Friday (if you find a kindred spirit)
Change Advisory Board awareness:            low (by design)
Official process compliance:                maintained (on paper)
Actual process:                             the side door
DevOps pipelines that replaced the RM:      0 (the RM was renamed, not replaced)
Most valuable trait:                        believes software should run
Rarest trait:                               same

See Also

• Water-Scrum-Fall — The environment in which the Release Manager’s power is most visible. The five-week sprint runs on the Release Manager’s schedule, not the Scrum Guide’s.
• DevOps — The practice that was supposed to automate the gate. The gate is now a YAML file. The YAML file has an approver. The approver is the Release Manager.
• Enterprise — The condition in which the gate exists. Startups deploy on push. Enterprises deploy on schedule. The schedule is the Release Manager’s.
• The Consultant — The person who finds the Enabler Release Manager, befriends them, and builds the side door. The consultant leaves. The side door remains. The Release Manager keeps opening it on Friday.