Evidence before the call
Delivery is a sequence, not a ticket
Name → calendar → prove → cut over
Intent, window, proof, and cutover are layers. Methods are lanes. Pipeline green is not the same as held in production — name rollback before anyone calls the change done.
INTENTOutcome — what this change is for, ownedWINDOWCalendars — platform, security, business freezePROOFEvidence — dependencies, blast radius, metricsCUTOVERSequence — rollback named before greenProblem → use → example
| If the real problem is… | Use | Example case |
|---|---|---|
| Platform, security, and business clocks disagree | Change window | Middleware patch waits for the freeze, then a named business-hours check — not a chat “we’ll find a slot” |
| Nobody can name who owns the dependency | Dependency map | Azure app change that needs a cert rotation: owner, blocker, and date on one plan; status names the wait |
| Must reverse without a weekend restore | Feature flag | New middleware route ships dark; flip on for one tenant, flip off if error rate moves — code deploy ≠ user release |
| Pipeline is green; ops is not ready | Done that survives the room | Rollback steps and who gets paged sit in the change note before anyone says green — tests passing is not held |
| Too many “ready” items, no sequence | Priority gate | Three Azure changes drafted in an afternoon; only the cert that blocks Friday’s window goes first — “not yet” is a decision |
| AI made drafts cheap; sequence got worse | Human Approve | Copilot wrote the runbook; a person still owns what next and why not yet — same gate Orbit uses for publish |
| After ship, nobody can tell if it held | Watch the service | Error rate and queue depth for 30 minutes post-cutover; if they move, rollback is already written |
| Snowflake middleware / env drift | Infra as code | App setting and network rule in Bicep (or Terraform); the next environment is a replay, not a memory |
| Status lives in a chat thread | Visible work | Blocker named on the board item; standup does not replace a written wait |
| Need fast feedback on main, not a long-lived branch | Small batches on trunk | Incomplete UI stays behind a flag; main stays releasable — Fowler’s CD test, not a two-week merge |
| Don’t know if delivery is actually getting healthier | Four keys | Lead time and change-fail rate next to the Azure ops pack; velocity theatre stays off this path |
Default order: name the intent and owner → calendars and dependencies → evidence pack → rollback + page path → small sequenced change (flag if you must reverse) → watch whether it held.
Tool picker
Trunk-basedSmall batches; main stays releasable
Feature flagsReversible cutover; deploy ≠ release
Azure MonitorDid the change hold after green?
Azure BoardsWork and blockers visible across teams
Approvals / checksHuman gate + business-hours window
Ready vs green
Ready · specified
Owner, window, blast radius, and rollback named. A ticket title is not an outcome.
Green · held
Pipeline pass is not ops done. Watch the service; keep the kill switch in reach.
Memory check
INTENT = outcome. WINDOW = whose clock. PROOF = evidence. CUTOVER = sequence + rollback.
Ladder + gates
- Named intent + owner
- Calendars + dependency map
- Evidence pack (blast radius, metrics)
- Rollback + page path written
- Small sequenced change / flag
- Watch whether it held
Kill switch
If you can’t name the owner, the window, and how to reverse, you don’t call it green.
Anti-patterns
- Ticket title as the outcome
- Calling pipeline green with no rollback
- Private AI speed as team capability
- Shipping while calendars still collide
- Chat-thread status with no named blocker
- Automating priority or the “not yet” call
- Long-lived branches instead of flags
- Framework shopping (SAFe/Scrum) before sequence
Always on
SecurityFreeze, access, and who can flip the flag
GovernanceWhose clock, whose change, whose rollback
ObservabilityWatch the service after green
EvalsHeld metrics — lead time, fail rate — not velocity theatre
Human ApproveRollback named before anyone calls it done