Running delivery day to day: 12 questions, answered

Question 1

How long should the window be?

Accepted Answer

Seven days by default, because it covers a full weekly cycle including the weekend and is short enough that people remember it is open. Shorten it only for changes with no customer-visible surface, and extend it only with a reason and a new closing date written in the ticket: a billing change needs the window to reach the next run, a seasonal feature needs it to reach the first real peak. A window with no end date is not monitoring, it is a browser tab left open.

Question 2

Is this the same as being on call?

Accepted Answer

No, and running them as one job is why post-release problems get missed. On call reacts to things that alert. Live monitoring goes looking for the things that do not: a journey that quietly completes at 54% instead of 61%, a support tag creeping up, a new error signature at ten a day. On call can hold the pager for the release, but somebody has to own the fixed-rhythm checks, the FAQ entry and the recorded decision, and that is a different piece of work.

Question 3

What if the change is behind a flag or a percentage rollout?

Accepted Answer

The window opens at first real user exposure, not at deploy, and your thresholds apply to the exposed cohort rather than to total traffic. A 2% error rate inside a 5% rollout is invisible in the overall number and is still the reason to stop. Write the ramp steps into the ticket with the check you run before each one, and treat turning the flag off as the cheap rollback it is, rather than waiting to pull the whole release.

Question 4

Who owns it, product or engineering?

Accepted Answer

One named person on the ticket, whichever function they sit in, with a named deputy. In practice the product manager tends to own the customer impact numbers, the FAQ entry and the macro, and the engineer who shipped the change tends to own the error and latency checks. Split the checklist between them if you like, but only one name carries the decision, and that person needs standing authority to roll back without convening a meeting.

Question 5

How long should this take each day?

Accepted Answer

Twenty to thirty minutes of passes, plus one forty-five minute decision window. Roughly ten minutes on the board and routing, ten on the approval queue, five on the close. If it reliably takes more, diagnose which part is swelling. A long morning pass means a stale board. A long approval queue means you are batching approvals that should clear daily, or tickets are arriving too thin to approve at all.

Question 6

What if I cover three teams?

Accepted Answer

One sequence per team, one pass covering all three, one shared decision window. The part that does not scale is the approval queue, because you are the constraint on it. If clearing it takes more than about forty-five minutes a day, delegate product approval to a named person per team with the gate rules unchanged, rather than approving faster and looking less closely.

Question 7

An urgent customer request just came in. Does it beat the sequence?

Accepted Answer

A live production incident does, and it goes into the RAID log as an issue rather than being quietly slotted into the roadmap. Everything else waits for your next sequencing pass. If it does beat the current next item, say out loud what it displaces and where that work now lands, because unnamed displacement is how a quarter goes missing.

Question 8

How is this different from stand-up?

Accepted Answer

Stand-up belongs to the team and covers what they are doing. This is your own loop, and most of it happens before stand-up so you arrive with decisions rather than questions. If you need stand-up to find out the state of the board, the board is the problem, and fixing that will save you more time than any change to the meeting.

Question 9

How is this different from a retrospective?

Accepted Answer

Different scope and different audience. The retrospective runs fortnightly, belongs to the team, and works on the last two weeks: what happened, what to try next. The health check is monthly, scored, and read by management as well as the team, and it works on the system the team sits inside: line of sight, tech debt, defects, safety, pace. Run both. Fold the health check into the retro and the structural problems get traded away for the nearest process tweak, while management never sees the card.

Question 10

Should the scores be anonymous?

Accepted Answer

Private until the reveal, not anonymous after it. Anonymous scores kill the only question worth asking, which is what did you specifically see that made you score it that way. Collect scores individually so nobody anchors, reveal them together, then discuss them attributed. If people will not put a red on the board with their name against it, that is your safety card answering itself, and it is a bigger finding than anything else in the session.

Question 11

What if every card comes back green?

Accepted Answer

Assume a measurement problem before you assume a healthy team. Check three things: whether a manager scored or spoke first, whether the data agrees (forecast against actual, bug budget burn, epics bouncing out of Ready for Dev), and whether the wording is soft enough that agreeing costs nothing. A card everyone can agree with in a bad month is a badly worded card. Fix it at the annual re-word, not mid-year, and mark the break on the chart.

Question 12

Who runs it and who attends?

Accepted Answer

The delivery lead owns and facilitates it, one team at a time: engineers, testers, designers, the product manager, and any contractor who has been there more than two weeks. Line managers of the people in the room do not attend, and no score is taken from anyone outside the team. If the delivery lead also line-manages half the room, borrow a facilitator from another team and have the lead abstain from scoring, because a score from the person who writes your review is not a score.

Running delivery day to day, answered in full.

How to run live monitoring after a release