A Shipping Cadence the Team Can Keep
A steady rhythm of small releases beats a heroic quarter: the team gets a pace it can hold, and stakeholders get a calendar they can plan around instead of a date they have to chase.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
What rhythm of shipping can this team hold for a year, and what does holding it buy?
The head of product, ten weeks before the holiday season: "We need the new checkout, gift cards and saved carts live before Black Friday. I know it is a lot. Whatever it takes — we can rest in January."
Treat it as a sprint to the line. Longer days, a big integration branch, one coordinated release two weeks before Black Friday, a code freeze, then recover in January. It has worked before.
The big release two weeks out bundles three features into one change. When conversion dips on the first day, nobody can tell which of the three did it, and the freeze stops anyone fixing it.
- The big release two weeks out bundles three features into one change. When conversion dips on the first day, nobody can tell which of the three did it, and the freeze stops anyone fixing it.
- Nothing ships for eight weeks, so support, marketing and finance learn about all three features in the same fortnight — training, copy and reconciliation all squeezed into the busiest weeks of the year.
- January is not rest. It is the bug backlog from the crunch, the on-call load from rushed code, and one or two people who have quietly started interviewing.
- Stakeholders learn that dates move under pressure. The next quarter opens with a bigger ask and "whatever it takes" again, because it worked last time.
What is really going on
- A team's capacity is a rate, not a reservoir. Overtime borrows from the next quarter at interest: tired engineers ship bugs that take longer to fix than the extra hours bought.
- A cadence is a promise about rhythm rather than dates: small changes go out continuously behind flags, something customer-visible ships every week or two, and there is a predictable moment — a weekly demo, a short written note — when stakeholders see what changed.
- Small batches make each release cheap to read and cheap to undo. One feature per release means a dip has one suspect; three features in one release means a meeting.
- For stakeholders, a cadence turns "when will it be ready?" into "which week will I see the first piece?" — a question the calendar can answer. Marketing plans copy per release, support trains per release, finance knows when numbers might shift.
- For the team, a cadence makes the next release unremarkable. Releases stop being events that need heroes, the week after a launch stops being the worst on-call week, and recovery stops needing its own month.
A rate, not a reservoir
The heroic plan treats the team's capacity as a tank to be drained before the deadline and refilled in January. It does not refill that way. The hours are spent, the code written in them is worse, and the next quarter starts with a backlog and fewer people.
A cadence treats capacity as a rate and plans against it. The same ten weeks produce smaller releases, earlier — and the result on Black Friday is three features that have each had weeks of real traffic.
Weeks 1–8: all three features on an integration branch, evenings and a couple of weekends. Week 8: one release, everything on. Weeks 9–10: freeze, dip in conversion, nobody sure which feature caused it. January: bug backlog.
Weekly visible releases. Week 2: new checkout at 10%. Week 4: gift cards (first version). Week 6: saved carts. Each ramps on its own flag. Weeks 9–10: freeze on risky changes; everything live has weeks of data. January: planned work.
The cadence version lands the same features with more real-traffic time, one suspect per problem, and a team that still exists in January. The heroic version concentrates all the risk into the two weeks when it is hardest to act.
What a cadence buys, per person
The case for a cadence is easiest to make one role at a time. Each person around the team has a question they keep asking, and the cadence answers it with a calendar instead of a status meeting.
| Who | Without a cadence | With a cadence |
|---|---|---|
| Head of product | "When will it be ready?" — answered with a date that moves | "Which week do I see the first piece?" — answered by the calendar |
| Marketing | Copy written against a big-bang date, rewritten when it slips | Copy per release, for things already live |
| Support | Trained on three features in the busiest fortnight | Trained on one change at a time, with its own note |
| Finance | Numbers shift all at once, cause unclear | Knows which week each change landed, can attribute shifts |
| The team | Releases are events; on-call is worst after launch | Releases are routine; recovery needs no special month |
Holding the rhythm under a deadline
The cadence gets tested exactly when a big date appears. Holding it is not refusing the date; it is showing how the date is met more safely at the pace the team can keep, and being plain about what does not fit (Options, Not Answers).
The head of product has asked for the new checkout, gift cards and saved carts before Black Friday, ten weeks out, with "we can rest in January".
"That is a lot for ten weeks. We will do our best — might need some late nights, but we will get it done."
"We can have all three live before Black Friday as first versions, each with at least a month of real traffic: new checkout in week two, gift cards in week four, saved carts in week six. What does not fit is corporate bulk gift-card orders — that moves to January. I would rather ship one feature at a time than all three in week eight, because if sales dip on a combined launch we will not know which one caused it, and we will be in the freeze. You will get a note every Thursday."
Choosing the rhythm
There is no single right cadence. The right one is the fastest rhythm the product allows that the team can keep up all year and that stakeholders can plan against.
What cadence should the checkout team publish?
when Web product, flags in place, one team owning the area.
cost Needs mature flags and monitoring; the weekly note has to be written every week.
when Less automation, or stakeholders who prefer fewer, larger updates.
cost Bigger batches and slower feedback; a missed sprint means a month between releases.
when Several teams change the same surface and need to coordinate.
cost A missed train waits for the next one; some coordination overhead every cycle.
when Native apps, or enterprise customers who contract for announced changes.
cost Slow feedback from customers; flags inside each version do most of the risk work.
The Thursday note
The cheapest part of a cadence and the one stakeholders notice most is the predictable update. It does not need a meeting. It needs to arrive at the same time every week, say what changed for customers, and say what slipped before anyone has to ask (Writing for Stakeholders).
1**Checkout — week 4**2 3**Live for customers**4- Gift cards (first version): buy and redeem, single card per order. On for 10%.5- New checkout: raised from 25% to 50%. Conversion and payment errors within normal range.6 7**What we saw**8- Gift-card buyers mostly buy one card for themselves; bulk orders not yet asked for.9 10**Next week**11- Gift cards to 25%. Saved carts to staff.12 13**Slipped / risks**14- None this week.The "Slipped / risks" line is there every week, including when it says none. That is what makes the week it does not say none believable.
How to do it
Most important first.
- Choose the cadence from what the product allows — for web checkout, continuous deploys with a weekly customer-visible release is a common shape — and publish it so stakeholders can plan against it.
- Put all three holiday features on the cadence: each gets a first version early, behind its own flag, ramped separately (The First Version That Teaches You Something, Feature Flags as Product Tools).
- Sequence so the feature riskiest to revenue ramps earliest, giving it the most weeks of real traffic before the peak (Sequencing Work So Value Lands Early).
- Keep a fixed demo or written update on the rhythm even when there is little to show; predictability is what stakeholders are buying (Running a Demo That Ends With a Decision, Writing for Stakeholders).
- When the ask exceeds the rate, say which part moves instead of absorbing it with overtime (Saying No Well).
- Freeze risky changes before the peak, not everything. By then each feature has been live for weeks, so the freeze protects code that has proven itself rather than trapping code that has not.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Lead with what the stakeholder gets earlier, not what they lose: "You will see the new checkout on real customers in week two, gift cards in week four, saved carts in week six. Each has a month of real traffic before Black Friday."
- Name the risk the heroic plan hides: "If all three go live together two weeks out and sales dip, we will not know which one did it — and we will be frozen and unable to fix it."
- Put the capacity question plainly: "At a pace we can hold, all three land as first versions. Corporate bulk gift-card orders do not; they move to January. I would rather tell you that now than in week nine."
- Offer the rhythm as something they can rely on: "Every Thursday you get a two-minute note: what shipped, what we saw, what is next. If something slips, you hear it on a Thursday, not on launch day."
- "The board wants all three for Black Friday, no negotiation." Then let us ship first versions of all three early, so they have the most time at real traffic to be fixed. That is the plan most likely to have all three working on the day.
- "Weekly updates are overhead." A two-minute note on Thursday replaces the "where are we?" messages every stakeholder is sending now.
- "We have always done a big release before the holidays." And a rough January after it. I would rather have a quiet November.
What can go wrong
- Cadence as theatre: a weekly release that ships only internal changes so the rhythm looks alive, while the customer-visible work still lands in one big batch at the end.
- The cadence becomes the goal: a feature that needed a month is chopped into pieces nobody can use, to hit the weekly beat.
- A cadence without flags. Weekly releases of half-finished features straight to customers are not small batches; they are frequent disruption.
- The exception becomes the norm: "just this quarter" crunches repeated every quarter, with the cadence surviving only in the plan.
- "Sustainable means slow." It usually means earlier first versions and fewer lost weeks to recovery. Where it does mean less, the shortfall shows in week one instead of week nine.
- "Cadence is an engineering concern." Much of its value goes to support, marketing and finance, who can finally plan against something.
- "Crunch is sometimes necessary, so cadence is naive." A rare, real deadline can justify a push. A push planned every quarter is not a push; it is the cadence, and it cannot be kept.
Knowing whether it worked
- Stakeholders plan against the cadence — marketing asks "which Thursday?" rather than "when?".
- The weeks before a peak are quieter than the weeks at the start of the quarter, because the risky work shipped early.
- Rollbacks and incidents per release stay small and boring; nobody remembers individual releases.
- People take normal leave around launch season, and nobody's resignation follows the holiday peak.
- On a small team a cadence is a habit and a calendar invite. At 10x team size it becomes a release train or an agreed deploy policy, because several teams changing checkout in the same week need to see each other's changes.
- At 10x customers, a quiet period before a peak matters more — and so does having shipped the risky work early enough to see it at volume.
- At 10x revenue, the cost of a bad release rises and the argument for small batches gets stronger, not weaker. "Fewer, bigger releases to be safe" is the instinct to resist.
- Fewer headline launches. A cadence produces a stream of small changes, and some stakeholders want a big moment to announce.
- Overhead per release: notes, demos, ramp monitoring and flag cleanup for many small things instead of one big one.
- Honest capacity means saying no sooner. The heroic plan lets everyone believe for eight weeks that it all fits; the cadence tells the truth in week one, and that is an uncomfortable conversation to have early.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- PRODUCT-SPECIFICWeb checkout can ship several times a day. Native apps are paced by app review and by customers updating, so the visible cadence is per app version; enterprise B2B customers may contractually want fewer, announced changes, and there the cadence is frequent internal releases plus scheduled customer-facing ones.
- STAGE-SPECIFICPre-product-market-fit, a small team shipping daily is the cadence and the risk is shipping without looking. At scale the risk is coordination — many teams, one checkout — and the cadence has to be agreed across teams, not chosen by one.
- GENERALThat overtime borrows from the next quarter holds broadly. A genuinely one-off deadline — a regulatory date, a contract penalty — can justify a push; the claim here is about pushes that repeat.
Where the depth lives
This domain teaches the product-side judgement and hands the mechanism off.