I am a Release (noun) Manager, not Release (verb) Manager

I've been getting several calls from cold-calling recruiters for positions seeking a release manager. After a couple questions, I end up correcting most callers that they are looking for a release engineer. I rather call them deployment managers because most of them understand that rather than release engineer.

This site provides a good explanation of the difference between the two.

I am a release manager (release as a noun), not a release manager (release as a verb). In my line of work/responsibility, I do not actually release any code or compile any code or touch any code (except maybe to forward the package to the operations team which I really should not be doing).

Another way to look at it is that I am like a project manager who are managers on the project level while I am a manager on the release level. If a problem is on the project level (something wrong with project requirements) then it is managed via the project manager. If that same problem cannot be remedied within the release schedule, then it becomes a release level problem thus requiring a release manager to review the impacts.

A release (in my world) is a set of projects to be deployed within the same window. The projects may have weak or strong correlations with other projects within the same release. Not all companies require a release manager as most companies deal with only single project releases. There may be several projects but none are dependent on the other so can always be deployed independently, or small enough to be easily managed by the development teams or existing project managers.

Our releases typically have 2-4 large projects, several small projects, and other production issue patches. For us, releases require quite a bit of coordination due to limited resources including both human resource and hardware resources. Our environments are hardware dependent costing tens to hundreds of millions of dollars so we cannot just simply "spin" up another test environment.

The release manager does not (in my opinion) have the authority to make a final decision on how the new issue should be resolved. The release manager has to be capable of providing the different options and the recommended course. The product, customer, or client should make the ultimate decision.

Typical choices could be:

1. delaying all phases to accommodate the new timeline
2. removing the project from the release (there still exists risk that this still delay the deployment if there are issues removing the project)
3. do not fix and deploy with a known defect (adds risk to customer satisfaction and/or data integrety)
4. shorten the timeline of a future phase if possible (typically requiring a group to work overtime)
5. use the buffer time if one was implemented (typically adds risk to a shortened quiet period)

These terms are not set in stone as the position (to me) seems relatively new (within the last decade) as can be seen by all the recruiters that does not know the differences either. The terms have been around long enough for some stability in their usages. Truthfully, I did not know about this type of position until I was hired here, and didn't know about release engineers until the recruiters started giving me job descriptions that did not match my roles.

Reference

http://www.plutora.com/insights/2014/release-management-vs-release-engineering/