Release Manager

The Release Manager owns the mechanics of moving code from merge to production across every Delivery Team. You are air traffic control for each release: you know what is in it and what is not, you coordinate the teams contributing to it, you own the technical and business go/no-go, and you drive it from cut to landed. You also own the environments, pipeline, and change-control record that make releases safe and auditable.

This is not a runbook-execution seat. You are expected to understand why the release process works, handle non-standard releases on their merits, and continuously improve the process.

• Release Execution: Execute Standard and Limited (audience-scoped) releases, including configuring and verifying audience scoping. Execute approved hotfixes: cut the branch, ship it, close it out. Define the rollback path per release type, make the call when a deployment fails technically, and run it.
• Release Readiness: Own the technical and business go/no-go on every grouped release, including Release Readiness and Milestone Reviews: are the changes shippable, are dependencies present, has the migration path been rehearsed, and is the business ready for it. Surface technical coupling and deployment-ordering constraints when release contents are decided, and handle non-standard releases such as running a migration separately, staging a two-phase deploy, or sequencing a schema change ahead of dependent code. Produce a release manifest for every release (contents, teams, commits, migrations, and configuration changes).
• Branch and Repository Hygiene: Enforce the branching model across every repository: branch creation, merge and squash discipline, cherry-picks into release branches, release branch cut and close, and tag and version discipline. Gate what enters a release branch after cut, and keep release branches free of drift, orphans, and long-lived unmerged work.
• Environment Ownership: Own the known-state, availability, and scheduling of Devtest, Acceptance, Beta, and Production, including data refresh and configuration parity so QA validates against something representative.
• Deployment Pipeline: Own the build-promotion and deployment pipeline end to end, drive out manual steps, and verify that each deployment landed cleanly.
• Process and Reporting: Keep deploy-pending and validation statuses accurate so "what is going out next" is answerable from the board. Report release frequency against plan, cycle time from code-complete to production, failed-deployment rate, rollback rate, hotfix rate, and hotfix-to-scheduled-release ratio. Run a short retrospective on any failed or rolled-back release, and own release runbooks and documentation.
• Change Control and Audit Evidence: Produce and retain the change-control record for every production push: what changed, who approved it, what validation passed, when it went out, and the rollback path. Serve as the system of record for release history in security, compliance, and customer audits.
• Release Communication: Derive cut dates and code-freeze windows from the Technical Delivery Manager’s release calendar, communicate them, and enforce them at the branch. Communicate release details and schedules to the business, including Sales, CS, and leadership. Notify teams and stakeholders of deployment start, completion, and failure in real time, and coordinate cross-team release dependencies before cut.

This role operates within clear lines so ownership never overlaps:

• The Technical Delivery Manager owns SDLC process, cadence, the release calendar, and hotfix decisions.
• The Enterprise Application Architect defines branching strategy and code-quality standards; this role operates and enforces them.
• Infrastructure engineering owns provisioning, cloud infrastructure, IaC, CI runners, and platform tooling; this role owns environments and the pipeline as release resources.
• Tech Leads drive fixes to done; Project Managers own sprint blockers and business-impact escalation; Product Marketing owns customer-facing communication.

You are process-first, and you write things down. You automate a repeated manual step rather than executing it well twice. You can tell a team it missed the cut, with no authority over the people you are gating, and hold that line under pressure. When your own release fails, you run a blameless post-mortem on it.

• U.S. citizenship and full-time U.S. residency, driven by contractual obligations with our customers.
• Availability for off-hours release work. Releases commonly run outside business hours, and this role must be reliably present for most of them on a sustainable schedule.

• Strong Git competency, the top technical priority: branching strategies, merges and squashes, cherry-picking, tagging, and managing the Git workflows that underpin a release process.
• Strong technical fluency. Not a software engineer or DBA, but a working mental model of CI/CD pipelines, containers and images, build artifacts, frontend vs. backend systems, deployment architecture, and MySQL concepts such as migrations, indexes, and the impact of database changes.
• Proven release management experience in a SaaS environment, including managing multiple releases concurrently across cross-functional teams.
• Excellent project and process management: tracking scope, chasing dependencies, enforcing process at the gate, and designing process where none exists.
• Strong communication and documentation skills, working closely with Engineering, QA, Product, and CS.
• Bachelor’s degree in Computer Science, Information Systems, or a related field, or equivalent practical experience.

• Prior software engineering, engineering management, Agile/Scrum/Ops, or database experience.
• AWS familiarity.
• Regulated-industry release experience (HIPAA, SOC 2, FedRAMP change control).
• Zero-downtime deployment and database migration experience.
• Feature-flag or progressive-delivery experience, directly relevant to Limited Releases.
• Scripting and automation experience, plus familiarity with defect tracking and configuration management tools.