Modern engineering practice favours teams deploying independently and frequently, and that's correct for most changes — the CI/CD guidance elsewhere on this site makes the case for it clearly. Release management as a discipline exists for the smaller category of changes where independence stops being enough: when two teams' changes touch the same system in the same window, or when a change is significant enough that the business needs advance notice regardless of how well-tested it is.
The mechanism that works without recreating the slow approval gates continuous delivery was meant to remove is a release calendar that's visible rather than gatekeeping — a shared view of what's deploying when, so a team about to ship a change to the payment flow can see that another team is also touching adjacent infrastructure the same afternoon, and the two can coordinate voluntarily rather than colliding by accident.
Freeze periods deserve to be used sparingly and communicated well in advance, because overused they train teams to treat every non-frozen day as equally safe, which isn't true — the day after a freeze lifts, with several teams' queued changes landing at once, carries more risk than an ordinary day even though it isn't formally restricted.
The measure of whether release management is helping or just adding process is whether deployment-caused incidents are actually declining. If the calendar exists and incidents caused by colliding changes keep happening anyway, the coordination mechanism isn't working — either it's not being checked before deploying, or it's not surfacing the right information — and it's worth fixing before adding more process on top of a foundation that isn't functioning.
