Release manager (QA)

Required Qualifications:

● 3+ years in QA management, release management, or build/release engineering

— or project management on a testing-heavy software product — including

responsibility for at least 3–4 releases end to end: you held the dates, you

chased other teams for their status, and you were the person management asked

are we ready to ship.

● Strong organisational discipline — the core of this role: calendars, checklists,

entry criteria, follow-through. You are the person who notices that one team

never sent their sign-off.

● Working knowledge of branching strategies (feature branches,

integration/product branches, release branches), merge windows, and code

freeze — and how testing maps onto them (feature-level testing vs.

integration/regression on the shared branch).

● Understanding of QA processes: test planning, test execution and sign-off,

regression scoping, severity/priority triage, defect exit criteria. Able to read and

challenge test status, not just collect it.

● Sufficient CI/CD literacy to follow build pipelines, build status, and artifact

promotion (Jenkins, TeamCity, GitLab CI, or similar).

● Able to chase, escalate cleanly and keep everyone informed; comfortable

holding an unpopular date or criteria position with evidence — the final

go/no-go rests with the VP of QA.

● Upper-intermediate level in English

● Comfortable using AI tools (e.g., LLM assistants connected to Jira/Confluence)

to automate release reporting, with enough JQL and data literacy to define the

metrics and validate the output

● Note to applicants: this is not a delivery or project management role — you

will not own scope, schedules or a delivery team. Equally, hands-on testing or

participation in releases is not enough on its own: this role is about coordinating

other people's work to a date. The test task is the main filter for this role

Desired Qualifications:

● Prior background in QA or software engineering before moving into

release/program management (QA background is a strong plus given the

gatekeeping mandate).

● Experience releasing on-premises / enterprise software: installers, multi-OS

builds, upgrade paths, long support lifecycles — not only SaaS.

● Experience with Early Access / beta programs feeding into GA.

● Familiarity with the backup, storage, or virtualization domain (VMware,

Hyper-V, Proxmox, physical, cloud workloads).

● Certifications: SAFe RTE (Release Train Engineer), ITIL (Release &

Deployment Management), PMP/PRINCE2.

Responsibilities:

NAKIVO ships NAKIVO Backup & Replication on a quarterly Release Train. The

Release Manager owns that train: the calendar, the entry criteria, and the gate. The core

mandate is — no feature boards the Release Train unless it has passed all required

testing, first on its feature branch and then on the product branch. Features that are not

ready by the cutoff wait for the next train; the train always leaves on schedule.

1. Release Train ownership

● Own and publish the quarterly release calendar: feature-complete cutoff,

feature-branch QA sign-off deadline, merge window to the product branch,

regression window, code freeze, Beta and GA milestones.

● Run the release cadence — kickoff, mid-cycle checkpoints, readiness

reviews, and prepare the VP's go/no-go review — and keep all product-area

teams aligned to the dates.

● Hold the line on the train model: dates do not move for individual features;

features move to the next train.

2. Quality gate definition and enforcement

● Together with QA and Dev leads, define explicit, verifiable entry criteria for

each gate: feature-branch test completion and QA sign-off, successful merge

to the product branch, integration/regression results on the product branch,

blocker/critical defect thresholds, documentation and upgrade readiness.

● Verify gate evidence directly — test execution status (Jira/Xray), build

results, open defect counts. Sign-offs are based on data, not verbal

assurances.

● Flag and escalate features that have not cleared their gates, with the evidence,

and prepare the defer recommendation for the VP of QA.

3. Readiness tracking and reporting

● Maintain a single source of truth for release scope and per-feature status:

which features are committed, at which gate, at risk, or deferred.

● Report release health to management on a regular cadence: scope, risks,

slippage, gate failures.

● Flag at-risk features early so teams can recover before the cutoff rather than

fail at the gate.

4. Branch and merge coordination

● Coordinate with Dev leads on the branching model in practice: when feature

branches are eligible to merge into the product branch, merge order and

windows, code freeze enforcement, and what (if anything) is permitted after

freeze.

● Escalate every post-freeze exception to the VP of QA with a written risk

assessment — exceptions are not granted at this level

5. Go/No-Go and release execution

● Chair release readiness and go/no-go reviews with QA, Dev, PM and PjM

● Drive the release execution checklist through Beta and GA: final regression

sign-off, release notes, upgrade testing, build promotion, support handoff.

● Run post-release retrospectives; trace escaped defects and hotfixes back to

gate weaknesses and improve the process accordingly.

6. Patch / hotfix governance

● Apply a lightweight version of the same gating model to interim patch

releases and hotfixes between quarterly trains.