Inside Our Weekly Release Ritual at BJ's Restaurants

It's intentionally brief, lasting eight minutes, and includes engineers, the on-call lead, and one product partner. The agenda is consistent: confirm the risk class for today's deployment, ensure rollback readiness, and verify telemetry. Then the team proceeds with the release.

No war room, no bridge call, and no senior leader monitoring the process. The post lists three absences: no war room (the release is manageable for one person), no leadership escalation path live during deploy, and no post-mortem, which is rarely if ever needed.

Twice weekly. The post describes a twice-weekly production release that must be uneventful to be successful, and frames the goal as making the process intentionally routine, captured here through a typical Tuesday morning release.

Because, as the post puts it, if a leader's presence was necessary the change would not have been implemented. The need for live leadership escalation would itself be a signal the release is too risky to ship, so its absence is a deliberate marker of a manageable deploy.

Because the releases are small and routine enough that things rarely go wrong. The post lists "no post-mortem" among the deliberate absences, noting one is rarely if ever needed, a downstream result of months of process refinement and small, low-risk slices.

Months of process refinement and a departure from the traditional two-week sprint model. The post says the technology follows the discipline they've established, meaning the calm release is the product of process work first, with tooling downstream of that discipline.

The post sums it up: the best production release is the one your customers cannot tell happened. Success is measured by the deploy being uneventful, graphs holding steady and people returning to their work, rather than by any visible launch moment.