Delivery Manager

Delivery Manager

The agent acts as an expert delivery manager coordinating continuous software delivery. It plans releases, selects deployment strategies, manages incidents, evaluates change requests, and tracks SLA compliance with error budget calculations.

Core Capabilities

• Delivery maturity assessment — locate the team on a 5-level scale (Manual → DevOps Excellence) and target one level at a time.
• Release planning — scope, exit criteria, rollout strategy, and a T-7/T-1/T-0/T+1 communication plan; Go/No-Go requires all exit criteria met.
• Deployment strategy — blue-green, canary, rolling, big-bang selection with matching rollback paths and canary success thresholds.
• Incident response — DETECT→TRIAGE→RESPOND→RESOLVE→REVIEW with SEV-1–SEV-4 severity, response times, and mandatory post-mortems.
• Change & SLA governance — CAB/Standard/Expedited/Emergency change types, SLA/error-budget burn-rate tracking, and DORA metrics.

When to Use

• Planning a release and running a Go/No-Go against exit criteria
• Choosing a deployment strategy and its rollback plan
• Responding to a production incident or running a post-mortem
• Evaluating a change request or calculating SLA/error-budget burn
• Assessing delivery maturity or interpreting DORA metrics

Clarify First

Before generating the plan or report, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• [ ] Which task — release readiness/Go-No-Go, deployment strategy, incident response, or SLA/error-budget tracking (each is a different workflow and artifact)
• [ ] Exit criteria or SLA target — the bar the release or service is measured against (Go/No-Go requires all criteria met; SLA math needs the target)
• [ ] Deployment strategy — blue-green, canary, rolling, or big-bang, when shipping (sets the rollout gates and rollback path)
• [ ] Incident severity — SEV-1 through SEV-4, when responding (sets response time, escalation, and whether a post-mortem is mandatory)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Quick Start

python scripts/release_checker.py --version v2.5.0            # release readiness vs exit criteria
python scripts/deploy.py --env production --strategy canary    # coordinate a deployment
python scripts/sla_calculator.py --service portal --period month  # SLA + error budget
python scripts/incident_report.py --id INC-2024-0125           # incident report from timeline

Tools

References

• references/release_process.md -- Delivery maturity levels, release planning + exit criteria, change-request types, the release-readiness example, DORA metrics, cross-skill integration, troubleshooting, and success criteria. Read when planning a release or improving the pipeline.
• references/deployment_patterns.md -- Blue-green, canary, rolling, and big-bang strategies with rollback paths and canary stage thresholds. Read when selecting how to ship.
• references/incident_management.md -- Severity matrix (SEV-1–SEV-4), the 5-step incident workflow, and post-mortem requirements. Read during incident triage and response.
• references/sla_management.md -- SLA framework, error-budget calculation example, and burn-rate freeze thresholds. Read when tracking reliability budgets.
• references/red-flags.md -- Bad-vs-good examples of delivery-management output. Read this to review a release/incident plan before committing to it.

Scope & Limitations

In Scope: Release planning and readiness assessment, deployment strategy selection and coordination, incident response process management, change request evaluation, SLA/error budget tracking, DORA metrics monitoring, post-mortem facilitation, delivery maturity assessment.

Out of Scope: Infrastructure provisioning and CI/CD pipeline engineering (hand off to DevOps/SRE), sprint-level planning and backlog management (hand off to scrum-master/), strategic program governance (hand off to program-manager/), feature prioritization and roadmapping (hand off to senior-pm/).

Limitations: Error budget calculations assume accurate incident duration tracking -- manual time entry introduces measurement error. Deployment strategies (blue-green, canary) require infrastructure support that the delivery manager recommends but does not implement. DORA metrics are trailing indicators; improvement requires upstream changes in engineering practices.

Integration Points

Example: Northwind SaaS — Coordinating a Multi-Team Black Friday Release

Real-world scenario showing how to apply this skill end-to-end.

Context

Northwind SaaS (Series-B logistics + payments platform) processes 12-15x normal volume during the week of Black Friday and Cyber Monday. The 2026 BF/CM window is 2026-11-27 to 2026-12-02. The product team has three releases that need to land before the freeze on 2026-11-21:

• Payments v3.2 — a new retry-policy engine to reduce false declines
• Logistics v4.0 — a major rewrite of the carrier-rate cache
• Identity v2.1 — multi-factor enrollment for merchant admin accounts

Three product teams. Three release trains. One shared incident response model. A single missed exit criterion in any one of them can blow the freeze window. The delivery-manager skill is being applied to plan the coordinated release, deployment strategies, rollback paths, and comms.

It is 2026-05-22; this is the early planning, 6 months out. The actual deploy will be 2026-11-19 (Wednesday before freeze).

Inputs

• 3 release trains, 3 owning EMs, 3 owning PMs
• Shared on-call rotation (SRE), 4 on-call engineers
• Production traffic profile: 7M req/day baseline, projected 90-100M req/day peak BF
• Existing maturity: Level 3 (continuous delivery, push-button deploys, but no automatic rollback)
• Constraint: code freeze at 2026-11-21 00:00 UTC; no deploys 11-21 through 12-03 except security patches
• Constraint: rollback must be possible within 5 minutes for any of the three releases
• VP Eng directive: "If we are not ready, we don't ship. The cost of a bad release on Black Friday is higher than the cost of slipping."

Applying the skill

1. Assessed maturity per team. Payments at Level 3, Logistics at Level 2 (still has a manual smoke test step), Identity at Level 3. Logistics' Level 2 forced a different rollout decision. 2. Picked deployment strategy per release. Payments and Identity get canary (Level 3). Logistics gets blue-green because the carrier-rate cache rewrite is high-risk and Level 2 maturity demands instant rollback. 3. Wrote one shared exit-criteria checklist. Every release uses the same checklist. No team-specific exceptions. This is the single biggest lever for coordinated releases. 4. Defined Go/No-Go gates at T-7 and T-1. Every team presents in the same 60-minute meeting. Any No-Go in any one team pulls the whole train. 5. Drafted rollback runbooks per release. Each runbook is testable; each was dry-run at least once in pre-production. 6. Customer comms split into 3 audiences. Merchants, internal support, internal exec. 7. Wrote the incident response model. During BF/CM, severity definitions shift. P3 becomes P2; P2 becomes P1. Three on-call engineers are dedicated to BF/CM volume only.

The artifact

================================================================
  NORTHWIND BLACK FRIDAY 2026 — COORDINATED RELEASE PLAN
  Window:    Deploy 2026-11-19 (Wed); freeze 11-21 to 12-03
  Owner:     Delivery Manager
  Sponsors:  VP Eng, VP Product
  Last update: 2026-05-22
================================================================


PART 1 — SCOPE PER RELEASE

[1] PAYMENTS v3.2 — Retry Policy Engine
    Team:           Payments (5 eng, 1 PM, 1 EM)
    PM:             Priya Rao
    EM:             Marcus Lee
    Risk:           MEDIUM. Touches the hot path; well-tested.
    Goal:           Reduce false declines by 4-6%.
    Strategy:       Canary
    Feature flag:   pmt.retry_v3.2.enabled (default off)
    Rollback:       Flag off + revert deploy (~3 min)

[2] LOGISTICS v4.0 — Carrier-Rate Cache Rewrite
    Team:           Logistics (8 eng, 1 PM, 1 EM)
    PM:             Tomas Lewandowski
    EM:             Yusuf Diallo
    Risk:           HIGH. Schema change + cache layer rewrite.
                    Last attempt 2 quarters ago was rolled back.
    Goal:           Carrier rate calculation latency p99
                    from 380ms -> <80ms.
    Strategy:       Blue-Green
    Feature flag:   N/A (architecture-level, not flaggable)
    Rollback:       Switch traffic blue<->green (<1 min)

[3] IDENTITY v2.1 — Merchant Admin MFA Enrollment
    Team:           Identity (4 eng, 1 PM, 1 EM)
    PM:             Maria Chen
    EM:             Sara Kim
    Risk:           LOW. Additive; no path removed.
    Goal:           Enable MFA enrollment for ~800 merchants.
    Strategy:       Canary
    Feature flag:   id.mfa_v2.1.enabled (default off, opt-in)
    Rollback:       Flag off (~30 sec)


PART 2 — SHARED EXIT CRITERIA CHECKLIST

EVERY release must satisfy ALL of the following before Go.
No release-specific exceptions.

  Code & test
  [ ] All P1/P2 bugs in scope resolved
  [ ] Unit test coverage maintained or improved
  [ ] Integration test suite passing on main
  [ ] Load test at 10x baseline passed
  [ ] Soak test (4 hours) passed on staging
  [ ] Security scan clean (no new high/critical)

  Operational
  [ ] Runbook reviewed by SRE on-call
  [ ] Rollback procedure dry-run within last 14 days
  [ ] Monitoring + alerting wired before deploy
  [ ] Dashboards published on shared SRE channel
  [ ] On-call EM signed off on deploy plan

  Comms
  [ ] Release notes drafted
  [ ] Customer notification drafted (if customer-visible)
  [ ] Support team briefed (mandatory walkthrough)
  [ ] Exec stakeholders notified (T-7 + T-1)

  Compliance
  [ ] PCI-DSS impact assessed (Payments only)
  [ ] Data residency unchanged
  [ ] Audit log entries for the deploy itself enabled

This is the SAME checklist for every team. If it does not
fit your release, the release is changing, not the checklist.


PART 3 — DEPLOYMENT STRATEGIES IN DETAIL

[1] PAYMENTS v3.2 — CANARY

  Stage 1   1% traffic (5 selected non-merchant test accounts)
            Monitor 60 min
            Watch: payment_success_rate, decline_rate, p99 latency
            Block if: any metric moves >0.5%

  Stage 2   5% traffic (random selection across customer tiers)
            Monitor 2 hours
            Block if: payment_success_rate drops >0.2%

  Stage 3   25% traffic
            Monitor 4 hours
            Block if: any metric breach

  Stage 4   100% traffic
            Soak for 24 hours before BF freeze begins

  Total canary window: ~32 hours from start
  Start time: 2026-11-17 02:00 UTC (Tuesday off-hours)
  Full at:    2026-11-18 10:00 UTC

[2] LOGISTICS v4.0 — BLUE-GREEN

  Blue:    v3.9 (current, all traffic)
  Green:   v4.0 (deployed in parallel)

  Step 1   Deploy v4.0 to Green env, NO traffic
  Step 2   Smoke test Green via internal load generator
  Step 3   Shift 1% production traffic to Green
           Monitor 30 min
  Step 4   Shift 10% to Green
           Monitor 60 min
  Step 5   Shift 50% to Green
           Monitor 2 hours
  Step 6   Shift 100% to Green
           Blue remains warm for 24 hours
  Step 7   Decommission Blue after 24 hours soak

  Rollback: any breach -> shift all traffic Green->Blue <1 min

  Start time: 2026-11-18 02:00 UTC
  Full at:    2026-11-18 14:00 UTC

[3] IDENTITY v2.1 — CANARY

  Stage 1   Flag on for 3 internal Northwind staff merchants
            Monitor 24 hours
            Acceptance: zero auth-flow incidents
  Stage 2   Flag on for first 50 opt-in merchants
            Monitor 24 hours
  Stage 3   Flag on for all 800 merchants who opted in
  Stage 4   Make MFA available (still opt-in) to all merchants

  Start time: 2026-11-15 (gives 6-day soak window)
  Full at:    2026-11-19


PART 4 — COORDINATED TIMELINE

T-30 (2026-10-20)  Scope finalized for all 3 releases
T-21 (2026-10-29)  Load + soak testing completed for all 3
T-14 (2026-11-05)  Rollback dry-runs completed for all 3
T-7  (2026-11-12)  GO/NO-GO meeting #1 (90 min)
                   Each team presents exit criteria status.
                   Any No-Go pulls that release (or all if
                   inter-dependent).
T-2  (2026-11-17)  Identity canary begins (early start —
                   needs longest soak)
                   Payments canary begins
T-1  (2026-11-18)  GO/NO-GO meeting #2 (60 min)
                   Logistics blue-green begins after meeting
T-0  (2026-11-19)  All three releases at 100% by EOD
T+1  (2026-11-20)  Soak day; no other changes; war room open
T+2  (2026-11-21)  Code freeze begins 00:00 UTC


PART 5 — ROLLBACK CRITERIA & PROCEDURE

A rollback is triggered if ANY of the following observed:

  - payment_success_rate drops >0.5% sustained 10 min
  - carrier_rate_p99 exceeds 200ms sustained 5 min
  - auth_success_rate drops >0.2% sustained 10 min
  - any new error rate >1% in deploy-related code paths
  - on-call EM judgment call (single-person authority)

Rollback decision authority:
  Tier 1: On-call EM of the affected team can rollback their
          OWN release without escalation.
  Tier 2: If rollback of one release affects another (unlikely
          but possible), delivery manager makes the call.
  Tier 3: VP Eng informed within 15 minutes either way.

Rollback comms template (pre-written, fill-in-blanks):
  - Internal Slack #incidents announce within 5 minutes
  - Status page update within 15 minutes if customer-visible
  - Exec page if Tier 2 or higher within 30 minutes


PART 6 — INCIDENT RESPONSE MODEL (BF/CM WINDOW)

During BF/CM, severity definitions ELEVATE by one level:

  Normal time     BF/CM time
  P1 critical     P0 - full-org war room
  P2 major        P1 - SRE + EM page
  P3 minor        P2 - business hours triage
  P4 low          P3 - backlog

Why: a "minor checkout glitch" in normal time is a brand
incident on Black Friday.

On-call structure:
  - SRE lead (primary, paged first)
  - Payments EM secondary
  - Logistics EM secondary
  - Identity EM secondary
  - Delivery manager on-call for cross-team coordination
  - VP Eng on call for executive decisions

Comms cadence during incident:
  Internal Slack:      every 15 min until resolved
  Status page:         every 30 min until resolved
  Customer email:      only if P0 sustained >2 hours


PART 7 — CUSTOMER COMMS

[A] PRE-RELEASE EMAIL TO MERCHANTS — 2026-11-12 (T-7)
    To:      All 12,400 active merchants
    From:    product@northwind.com
    Subject: Improvements landing before Black Friday

    Body:
    Three updates roll out before our Black Friday freeze:
      1. Smarter payment retries (no merchant action needed).
      2. Faster carrier rate calculations on checkout.
      3. New optional MFA for your admin accounts -- you
         can enroll any time at /security/mfa.
    Window: Nov 17-19. No expected downtime. Status page:
    status.northwind.com.

[B] PRE-RELEASE BRIEF TO SUPPORT — 2026-11-13
    Live walkthrough of all three releases, 90 minutes.
    Includes: what changes for the merchant, what tickets
    might increase, escalation path.

[C] EXEC PRE-RELEASE NOTE — 2026-11-18
    1-page summary, what is shipping, what is at risk, what
    the go/no-go decision was.


PART 8 — POST-FREEZE PROCEDURE

  2026-12-03 00:00 UTC  Freeze ends
  2026-12-03            Post-mortem schedule sent
  2026-12-05            BF/CM retro (cross-team)

  Three required post-mortems regardless of incidents:
    1. What worked in the coordinated release
    2. What worked in incident response
    3. What we should change for 2027

  Even with zero incidents, the retro happens. The lessons
  from a smooth release are as valuable as the lessons from
  a bad one.


PART 9 — RISK REGISTER

  R1  Logistics v4.0 fails for the same reason as last time.
      Mitigation: blue-green strategy, instant rollback. Plus
      a 4-hour soak in pre-production with synthetic peak load.

  R2  Identity MFA opt-in surge floods support.
      Mitigation: stage 1 only enables for opt-in merchants;
      support briefed; FAQ pre-published.

  R3  Payments retry policy creates duplicate transactions
      in edge case.
      Mitigation: idempotency key enforced at API layer;
      canary watches duplicate-charge metric specifically.

  R4  All three teams "Go" at T-7 but one slips at T-1.
      Mitigation: explicit policy that releases CAN ship
      independently; releases NOT inter-dependent by design.
      A late Logistics does not block Payments.

  R5  On-call burnout pre-BF.
      Mitigation: no SRE on-call for non-BF work the week
      of release; backup roster doubled for BF week.


PART 10 — SUCCESS CRITERIA

  - All three releases at 100% by 2026-11-19 EOD
  - Zero customer-visible incidents during BF/CM (11-27 to 12-02)
  - Payment false-decline rate measurably reduced
  - Carrier-rate p99 measurably reduced
  - MFA enrollment available to all merchants
  - No emergency security patches during freeze
  - Cross-team retro yields >=3 actionable improvements for 2027

Why this works

• One shared exit-criteria checklist. Three teams, three releases, one checklist. This is what prevents "we cleared it for our team" failure modes that doom coordinated releases.
• Deployment strategy chosen by maturity, not by preference. Logistics is at Level 2 and the change is high-risk — blue-green is the only acceptable strategy. Payments and Identity are at Level 3 with lower risk — canary is appropriate. The skill's maturity-to-strategy mapping is doing the work.
• Releases independent by design. Risk register R4 is the most important entry: the three releases are deliberately not interlocked. If Logistics slips, Payments and Identity still ship. Tightly-coupled releases are how multi-team programs fail.
• Severity elevation during BF/CM. Reclassifying P1 to P0, P2 to P1, P3 to P2 for the BF window is the operational discipline that distinguishes a delivery manager from a project manager. The same severity rubric does not work across all calendar moments.
• Rollback dry-runs at T-14, not T-1. Dry-runs at T-1 always reveal a step you forgot to test. Done at T-14 there is still time to fix the rollback procedure itself.
• Mandatory post-mortem even with zero incidents. Most teams only run a post-mortem after a bad release. The lessons from a smooth release are how you make the next release smoother.
• VP Eng has a written "slip > bad ship" directive. This is the political cover for the on-call EM who has to make a No-Go call at T-1. Without it, the call becomes career-risky.

What's next

• The post-release retros at T+14 use `../sprint-retrospective/` for the structure.
• Any incidents that occur use `../execution/post-mortem/` for blameless RCA.
• Customer-facing communications use `../execution/release-notes/` and `../execution/launch-playbook/`.
• Feature flag strategy details for Payments and Identity are anchored in `../execution/feature-flag-strategy/`.
• For Logistics' next release after Black Friday, escalate to `../agile-coach/` to bring the team's maturity from Level 2 to Level 3.
• Cross-team dependency tracking pre-release uses `../execution/dependency-map/`.

Deployment Patterns: Blue-Green, Canary, Rolling

Read this when selecting a deployment strategy and defining its rollback path and canary success thresholds. Moved verbatim from SKILL.md.

Select Deployment Strategy

Blue-Green deployment:

Load Balancer -> [BLUE v2.4 - Active] | [GREEN v2.5 - Staging]
SWITCH: Route traffic Blue -> Green
ROLLBACK: Route traffic Green -> Blue (instant)

Canary deployment progression:

Stage 1: 95% old / 5% new   -- Monitor for 30 min
Stage 2: 75% old / 25% new  -- Monitor for 1 hour
Stage 3: 50% old / 50% new  -- Monitor for 2 hours
Stage 4: 0% old / 100% new  -- Full rollout

Validation checkpoint: At each canary stage, check error rate (<1%), latency P99 (<threshold), and health checks. Any breach halts progression and triggers rollback.

Incident Management: Severity, Response & Post-Mortem

Read this when triaging or coordinating a production incident, or defining the severity and response-time policy. Moved verbatim from SKILL.md.

Manage Incidents

The agent follows the DETECT -> TRIAGE -> RESPOND -> RESOLVE -> REVIEW process:

Severity levels:

Incident workflow: 1. Detect -- Alert fires, monitoring triggers, user reports 2. Triage -- Assess severity, assign incident commander, notify stakeholders 3. Respond -- Incident commander coordinates, communicate status every 30 min (SEV-1/2) 4. Resolve -- Deploy fix, verify restoration, confirm with monitoring 5. Review -- Post-mortem within 48 hours, document timeline, root cause, action items

Validation checkpoint: Every SEV-1/SEV-2 incident must produce a post-mortem with action items, owners, and due dates.

Red Flags: Delivery Manager

Common ways this skill's output goes wrong — concrete examples, why they're bad, and how to fix them. Pair with the SKILL.md and Troubleshooting table.

How to use this document

When you have just produced a release plan, incident response, change-request evaluation, or maturity assessment, scan the red flags below. Each red flag shows a bad and good version.

---

Red Flag 1: Blame-Seeking Incident Handling

Symptom. Post-incident review focuses on "who did this" — naming individuals, assigning fault. Quiet rooms, defensive language, no candid contributions.

Why it's bad. Blame culture destroys reporting. Engineers stop flagging near-misses; small problems compound into outages. Allspaw's blameless post-mortem framing exists because the alternative empirically reduces safety. Naming a culprit is satisfying and counter-productive.

Bad example:

Post-incident: "Raj deployed without proper review. Action: written warning. Lessons: be more careful."

Good example:

Post-incident: "The deployment passed our review gate but our review gate did not catch the missing config flag. Root cause: review checklist did not include config-flag verification for canary deploys. Action: update checklist + add automated check. Raj's deploy followed our process; the process needs work."

How to catch it. Read the post-mortem. Does it name an individual as the cause? If yes, the framing is unsafe.

---

Red Flag 2: Missing Rollback Rehearsal

Symptom. Release plan documents a rollback procedure, but the procedure has never been tested in production-like conditions.

Why it's bad. Untested rollback procedures fail when needed. The 3am incident is not the time to discover that the rollback script depends on a tool no one has installed, or that the database migration is not reversible. Maturity Level 4-5 requires rehearsed rollback.

Bad example:

Release plan: "Rollback: revert deploy via Jenkins. DB migration is forward-only; data recovery via backup if needed."

Good example:

Release plan: "Rollback procedure tested in staging on 2026-05-15 (signed off by EM + on-call). Migration designed as expand-contract: new columns added in week 1, code switches to new columns in week 2, old columns removed in week 3 — fully rollback-safe at each step. Rollback target time: 15 min p50, 30 min p95."

How to catch it. Has the rollback been rehearsed in the last 90 days, with measured target time? If not, the plan is theoretical.

---

Red Flag 3: Error Budget Treated as Reliability Theater

Symptom. Team has SLOs and an "error budget" but never actually slows feature work when the budget is burned.

Why it's bad. The point of error budgets is to create an automatic tension between reliability and feature velocity. Budgets that never bite are decorative. Maturity Level 4-5 organizations enforce budget consequences: when burned, feature freeze until reliability work restores it.

Bad example:

SLO: 99.9% uptime. Budget for the month: 43 min. Actual downtime: 4 hours. Action: noted in monthly report, continued feature work."

Good example:

SLO: 99.9% uptime. Budget: 43 min/month. Actual: 4 hours (budget exceeded by 5x). Action triggered by policy: feature work paused, 100% of capacity to reliability for 2 weeks. Restoration plan: 3 named items, ETA documented. Restart criteria: budget restored to <50% consumption for 30 days."

How to catch it. Has your team ever paused feature work because the error budget was burned? If never, the budget is decorative.

---

Red Flag 4: Deployment Strategy Mismatch

Symptom. Team uses blue-green deployment for a high-traffic, stateful service where canary would surface bugs earlier. Or rolling deployment for a service where blast-radius needs full isolation.

Why it's bad. Each strategy has a profile: blue-green = fast switch, double infrastructure cost, hard for stateful; canary = gradual exposure, slow validation, requires monitoring sophistication; rolling = simple, partial exposure during rollout. Mismatched strategy produces either (a) bigger blast radius than necessary or (b) unnecessary cost.

Bad example:

"We use blue-green for everything." (One service has 200 GB of stateful in-memory cache; blue-green requires warming the green environment for 90 min before switch.)

Good example:

"Deployment strategy per service: stateless APIs use rolling (simple, fast). Customer-facing UI uses canary (5% -> 25% -> 100% over 4 hours, with auto-rollback on error-rate spike). Stateful cache service uses blue-green with pre-warming. Documented per-service in runbook."

How to catch it. Can you justify the deployment strategy per service? If not, you are using one strategy for everything.

---

Red Flag 5: Communication Plan Missing T-7/T-1/T+1

Symptom. Release plan covers T-0 (the deploy itself) but no pre-deploy comms, no go/no-go gate, no post-deploy follow-up.

Why it's bad. Surprises break trust with stakeholders. A release that ships without T-7 scope-finalization and T-1 go/no-go feels chaotic to support, sales, and customer-facing teams. A release without T+1 follow-up leaves customers and stakeholders wondering whether it landed safely.

Bad example:

Release plan: "Deploy v2.5.0 on Tuesday at 10am. Slack post when done."

Good example:

Release plan: "T-7 (Tue prior): scope frozen, release notes drafted, internal preview posted. T-1 (Mon): go/no-go meeting at 4pm with eng, product, support, marketing. Owner has authority to delay. T-0 (Tue 10am): deploy, monitoring on, status updates every 30 min in #release. T+1 (Wed): customer comms (changelog, release email if customer-facing), retro scheduled for following week."

How to catch it. Does the plan cover all four checkpoints? Missing any is a process gap.

---

Red Flag 6: Change Advisory Board (CAB) as Rubber Stamp

Symptom. CAB meets weekly, approves every change request in <2 minutes per request, never blocks or modifies a change. Or, CAB blocks every change, becoming a velocity tax.

Why it's bad. Both ends are anti-patterns. A rubber-stamp CAB is bureaucratic theater — it adds delay without adding safety. A blocking CAB is risk-averse paranoia — it slows the org without proportionate risk reduction. Healthy CABs are exceptions-based: standard changes auto-approve, only high-risk changes need real review.

Bad example:

CAB approves 100% of 47 requests this month, average 90 seconds per request.

Good example:

Change taxonomy: Standard (pre-approved, automated, no CAB) = 80% of changes. Normal (CAB review) = 18%. Major (executive review + customer comm) = 2%. CAB only sees 'Normal' and 'Major' — about 10 requests per month, each with a real review. Standard changes flow through CI/CD."

How to catch it. What % of changes does CAB see? If above 50%, the taxonomy is broken. If 100% approved, the review is fake.

---

Red Flag 7: Incident Severity Inflation or Deflation

Symptom. Every minor issue gets logged as Sev-1 (inflation), or genuine outages stay at Sev-3 (deflation) because higher severity triggers paperwork.

Why it's bad. Severity inflation desensitizes the team — "another Sev-1, ignore the page." Severity deflation hides real problems — customers experience outages while the dashboard says "green." Both produce wrong investment in reliability.

Bad example:

Last 30 days: 42 Sev-1 incidents declared. 38 were minor support tickets escalated by frustrated users.

Good example:

Severity rubric documented: Sev-1 = >5% of customers impacted, revenue impact, or data loss. Sev-2 = degradation affecting >1% customers. Sev-3 = isolated. Quarterly severity review by senior on-call to recalibrate. Sev-1 rate stable at 1-3 per month."

How to catch it. Sample 10 recent Sev-1 declarations. How many actually meet the documented criteria? Below 80% match means severity is misused.

---

Red Flag 8: Runbook That No One Has Run Recently

Symptom. Runbook for database failover, dated 2022, never tested. When the failover is needed, half the commands fail because the tool changed.

Why it's bad. Runbooks rot faster than code. A runbook untested in 6+ months should be treated as fiction. The fix is game-day exercises — scheduled runbook executions on staging or production with safety net.

Bad example:

"We have a comprehensive runbook for database failover." (Last executed 2022. Tools referenced are deprecated.)

Good example:

"Quarterly game-day: rotation of critical runbooks tested by on-call engineer in staging or controlled production. Last database-failover game-day: 2026-04-10, all steps executed, 3 commands updated, runtime measured (12 min vs 18 min target). Runbook freshness tracked per item."

How to catch it. For your top 5 critical runbooks, when were they last executed end-to-end? If any over 6 months, that runbook is suspect.

---

Red Flag 9: Feature Flags Used Without Cleanup

Symptom. Codebase has 400+ feature flags, half of them set to 100% on for 2+ years. Conditional logic everywhere, nobody knows which flags are still meaningful.

Why it's bad. Feature flag debt is real debt. Every flag is conditional complexity, a potential bug surface, and a cognitive tax on engineers. The discipline is flag-with-end-date.

Bad example:

Feature flag inventory: 412 flags. 187 at 100% on for >18 months. 23 at 0% with no documentation on why.

Good example:

Flag policy: every flag has an owner, a creation date, and a target sunset date. Monthly flag-cleanup ritual: flags past sunset date either removed or re-justified. Current inventory: 41 flags, all under 6 months old or actively managed."

How to catch it. How many flags are over 12 months old? If above 20, you have flag debt.

---

Red Flag 10: Deploy Frequency Without Lead Time

Symptom. Team reports "we deploy 50 times per week" but lead time from commit to production is 8 days.

Why it's bad. Deploy frequency without lead time hides the real bottleneck. DORA's four metrics work together: deploy frequency, lead time, change failure rate, MTTR. Reporting one without the others paints a misleading picture.

Bad example:

Quarterly delivery report: "Deployments: 287 (industry-leading). Reliability: high."

Good example:

Quarterly delivery report (DORA): Deploys per week = 50, lead time p50 = 8 days (target 3), change failure rate = 12% (target <15%), MTTR = 42 min (target <60). Improvement area: lead time — root cause is review queue depth, action plan in place."

How to catch it. Does your delivery report show all four DORA metrics? If not, one or more is being hidden.

---

Red Flag 11: SLA Promises Without Capacity to Meet Them

Symptom. Sales promises 99.99% uptime in customer contracts. Engineering has not staffed for that SLO; actual uptime is 99.5%.

Why it's bad. Promised reliability without engineering capacity produces breached contracts, SLA credits, and customer churn. SLOs must be co-owned by sales and engineering, with cost implications visible to both.

Bad example:

"We promise 99.99% in enterprise contracts." (Engineering team of 5 supporting one region, no 24/7 on-call, last quarter uptime 99.5%.)

Good example:

"SLO tiers: 99.9% standard (covered by current capacity), 99.95% premium (requires multi-region, costs $X/month, dedicated on-call rotation), 99.99% enterprise (requires both + active-active, costs $Y, contract minimums). Sales authorized to promise tier matching customer commitment."

How to catch it. Are your contractual SLAs aligned with your engineering capacity? If not, you are pre-paying penalties.

---

Red Flag 12: Maturity Score Inflation

Symptom. Team self-assesses at Level 4 (Continuous Deployment) but actual deploys are manual, monitoring is uptime-only, and rollback is not automated.

Why it's bad. Inflated maturity assessments hide real gaps. Leadership invests based on the inflated number ("we're already great at delivery, invest elsewhere") while real risks accumulate. The SKILL.md's level criteria exist precisely to prevent this.

Bad example:

"Self-assessment: Level 4. We deploy a lot." (No automation, no canary, no auto-rollback, basic uptime monitoring.)

Good example:

"Self-assessment: Level 2 (Automated Build/Test). Evidence: CI passing, automated unit tests, manual deploys via Jenkins, basic uptime monitoring. Target Level 3 by Q4: deploy automation + comprehensive monitoring. Investment plan: $X, 2 engineers for 1 quarter."

How to catch it. For each level claim, name the specific evidence required by the SKILL.md's level criteria. If evidence is missing, downgrade the level.

---

Red Flag Quick Reference

Related Reading

• SKILL.md Troubleshooting section (for symptom -> root cause -> resolution)
• references/release-checklist.md (if present)
• references/incident-response.md (if present)
• agile-coach/references/red-flags.md (for adjacent maturity-assessment patterns)

Release Process: Maturity, Planning, Change Management & DORA

Read this when assessing delivery maturity, building a release plan and exit criteria, evaluating change requests, or interpreting DORA metrics. Also contains the release-readiness worked example, the cross-skill integration map, the troubleshooting matrix, and success criteria — all moved verbatim from SKILL.md.

1. Assess Delivery Maturity

The agent evaluates the team's delivery pipeline against 5 maturity levels:

Validation checkpoint: Identify current level and target level. Focus improvement efforts on one level at a time.

2. Plan Release

The agent creates a release plan covering:

1. Scope -- Features (with status), bug fixes, dependencies (DB migrations, API versions, SDK updates) 2. Exit Criteria -- All P1/P2 bugs resolved, performance benchmarks met, security scan passed, load testing complete, UAT sign-off, documentation updated, runbook reviewed 3. Rollout Strategy -- Deployment window, method (blue-green, canary, rolling), rollback plan 4. Communication Plan -- T-7 (scope finalized), T-1 (go/no-go), T-0 (release notes), T+1 (customer notification)

python scripts/release_checker.py --version v2.5.0

Validation checkpoint: Go/No-Go decision requires all exit criteria met. Any unmet criterion triggers a risk assessment and potential delay recommendation.

3. Evaluate Change Requests

Each change request requires: description, justification, impact analysis (systems, services, users, downtime), implementation plan, rollback plan, testing plan, and scheduled window.

Validation checkpoint: No Normal or Expedited change deploys without a documented rollback plan.

Example: Release Readiness Check

$ python scripts/release_checker.py --version v2.5.0

Release Readiness: v2.5.0
=========================
Type: Minor Release (new features)
Target Date: January 25, 2024

Exit Criteria:
  [PASS] All P1/P2 bugs resolved (0 open)
  [PASS] Performance benchmarks met (P99: 320ms < 500ms target)
  [PASS] Security scan passed (0 critical, 0 high)
  [PASS] Load testing complete (sustained 2x peak traffic)
  [PASS] UAT sign-off received (Jan 23)
  [WARN] Documentation: 2 pages pending review
  [PASS] Runbook reviewed and updated

Recommendation: CONDITIONAL GO
  - Complete documentation review before T-0
  - Deployment strategy: Blue-green (recommended for this release size)
  - Rollback plan: Instant switch to blue environment
  - Monitoring period: 24 hours post-deploy

DORA Metrics

python scripts/deploy.py --env production --strategy canary

Cross-Skill Integration

Troubleshooting

Success Criteria

• Change failure rate stays below 5% measured over a rolling 30-day window
• Mean time to recovery (MTTR) for SEV-1/SEV-2 incidents is under 1 hour
• 100% of SEV-1/SEV-2 incidents produce a post-mortem with action items within 48 hours
• Error budget consumption stays below 80% in any given month
• Release cadence meets or exceeds the target deployment frequency (weekly or better)
• Zero deployments proceed without a documented rollback plan
• DORA metrics show quarter-over-quarter improvement across all four measures

SLA & Error Budget Management

Read this when calculating SLA compliance, error budgets, and burn rates, or setting deployment-freeze thresholds. Moved verbatim from SKILL.md.

Track SLA and Error Budget

python scripts/sla_calculator.py --service portal --period month

Error budget calculation example:

SLA: 99.9% availability
Error Budget: 0.1% = 43.8 minutes/month

Budget Consumption:
  Incident 1: 15 min
  Incident 2: 5 min
  Maintenance: 0 min (scheduled, excluded)
  Total used: 20 min

Remaining: 23.8 min (54% remaining)
Burn rate: 0.8x (on track)

Validation checkpoint: If error budget burn rate exceeds 1.5x, freeze non-critical deployments until burn rate normalizes.