Release Lead

A Release Lead at Cadence OneFive is a team member who takes on ownership of getting releases out the door. The role exists alongside the Tech Lead because the two jobs pull in different directions: the Tech Lead keeps the team focused and moving forward; the Release Lead keeps the pipeline flowing and production up to date. Like the Tech Lead, the role rotates so everyone builds firsthand familiarity with the full release process.

Release Leads don’t own the code. They own the pipeline.

Regular routine

These are the things a Release Lead stays on top of every release cycle.

Keeping the pipeline moving

PRs that are ready to merge get merged. The queue doesn’t pile up. A backed-up main becomes a backed-up release.
Staging gets pushed to regularly — not just at release time. Let’s aim to do this every day. Getting code onto staging early gives QA time to catch problems before they compound.
Before promoting to production, the Release Lead does a gut check: what’s in this release, what’s the blast radius, and does anything touch a core flow?

Release execution

Releases happen at a time when interested team members can join. Having others present — especially during the early rotations — helps everyone build comfort with the process.
The Release Lead follows the Release v[x] checklist ticket for step-by-step execution. If something fails, they call it out in Discord and loop in the team — not silently debug alone.
After the release, the Release Lead confirms the deploy is live and stable before signing off.

Communication

QA and Product know what’s going into staging and which areas of the app are at risk. This doesn’t need to be exhaustive — just enough to focus testing on the right places.
The team knows when a release is coming and roughly what’s in it.

Situational

These aren’t part of every cycle, but they come up and the Release Lead owns them when they do.

Promote or hold: If staging is accumulating changes and main is backing up, the Release Lead makes the call. Holding off indefinitely creates its own risk — it’s not a safe default.
Cherry picking: Sometimes you can’t promote all of main. The Release Lead identifies what’s ready, what’s been tested, and what’s too entangled to ship safely. This takes judgment and usually a conversation with QA, Product and the Tech Lead — not a solo decision. Track the list carefully: what’s a candidate, what’s been tested, what has dependencies that haven’t been tested.
Handling release failures: The automated release process occasionally fails — token issues, oversized release notes, infrastructure hiccups. The Release Lead figures out what happened, not just that it happened, and documents it.
Regression risk communication: When new code lands on staging during an active regression cycle, the Release Lead flags the risk areas so QA isn’t starting from scratch. A brief note on what changed and what flows might be affected is enough.
Tooling: If an opportunity arises to improve the release process, catch regressions, or create tooling that can help in some other part of the process, it is the Release Lead’s responsibility to make the change/create that tooling. (Ex. tooling to identify the changes and flag priority areas for testing)

Owning the process itself

Being Release Lead is the best time to evaluate whether the release process and tooling are still right for us. You’re closest to the friction. You’re the one who feels where things are slow, error-prone, or just more manual than they need to be.

It comes down to asking: Does the checklist still reflect how we actually release? Is the tooling we rely on still the best fit? Are there steps we do out of habit that no longer serve us?

If you spot something, do one of the following:

Fix it now if it’s small and clearly an improvement.
Propose it in Discord or a ticket if it needs team input or more thought.
Document it so the next Release Lead can pick it up if there’s no bandwidth this cycle.

The goal is that every rotation leaves the process slightly better than it was found.