A release manager is accountable for getting releases out safely: coordinating dependencies, chasing sign-offs, holding freezes and making the go/no-go call, often as the last person to find out what is actually in the release.
A release manager is the person accountable for getting releases into production safely. They coordinate what is in each release, the order it ships in, the approvals it needs and the windows it can ship in, and they make or facilitate the go/no-go call. It is a coordination role that spans the tracker, source control, the pipeline, the incident tool and a lot of chat.
The title is used differently from one company to the next, but the work usually includes:
Rebuilding a dependency order that already existed in Jira links nobody joined up. Chasing an owner who never saw the gate. Reconstructing evidence before an audit. Finding out at 2am which deploy caused the incident. The common thread is that the information existed; it just was not joined up.
The boundaries blur, so it helps to say what is different about the seat:
Most release tooling is either a portfolio planning suite aimed at executives or a CI system aimed at engineers. The release manager sits in between, and the gap is a layer that joins the signals into one view.
ArcRelease is built for exactly this seat: it assembles the release picture from the tools your teams already use, so the release manager walks into the go/no-go with the answer already there.
Checks what is in upcoming releases and what each depends on, follows up on missing sign-offs, watches the calendar for freezes and clashes, runs the go/no-go, and stays close to the deploy and the first hours after it. Between releases, they review what went wrong and update the checklist.
No. A DevOps or platform engineer builds and operates the pipeline and infrastructure. A release manager decides what goes through it, in what order and with whose approval. Small teams often combine the two seats in one person.
It depends on the organisation. Often the release manager makes or facilitates the call, with the service owners and, for risky releases, a more senior approver. What matters is that the decision-maker is named and that the decision and its reasons are recorded.
The role changes shape rather than vanishing. With small, frequent deploys, much of the checking moves into automation, and the release manager spends more time on cross-team dependencies, freezes, risky changes and evidence than on scheduling a weekly release.
Enough technical depth to read a pipeline and an incident, clear communication across teams, calm under time pressure, and a habit of writing down decisions and their reasons.
Commonly by the DORA keys at the level of the services they cover (deployment frequency, lead time, change failure rate and time to restore), alongside whether releases can be shown to have followed the agreed process.
Tell us about your release process. Connect your stack in ten minutes, run a Gaja preflight on a real release, and see the reasons behind the verdict.
Free plan · ten minute setup · we reply in one to two business days