Technical Program Manager

Technical Program Manager

When to Use

• Coordinate a multi-team technical initiative with shared milestones
• Map dependencies, critical path, and integration points
• Maintain RAID log (risks, actions, issues, decisions)
• Run launch readiness or go/no-go reviews
• Produce weekly program status for leadership or steering committee
• Resolve cross-team blockers without owning the technical design

When NOT to Use

• Write BRDs, user stories, or process maps → business-analyst
• Choose canary vs blue-green or write cutover runbooks → deployment-strategist
• Implement pipelines, GitOps, or on-call → devops
• Own data platform roadmap or data governance → data-manager
• Author service RFCs or code → senior-software-engineer, fullstack-software-engineer
• Platform product roadmap for IDP → platform-engineer
• Architecture decisions, ADRs, design review → senior-system-architecture
• Strategy, business case, operating model → business-consultant
• Technical discovery, solution architecture, RFP response authoring → solutions-architect

Related skills

Core Workflows

1. Program charter

Define before execution:

• Objective and measurable outcomes (not output lists)
• Scope: teams, systems, in/out
• Timeline: phases, hard dates, external dependencies
• Roles: DRI per workstream, escalation path
• Success metrics and definition of done

See `references/program_charter.md` for charter template.

2. Work breakdown and dependencies

1. Decompose into workstreams (each with one DRI) 2. List deliverables per workstream with dates 3. Build dependency graph (finish-to-start; flag circular deps) 4. Identify critical path and buffer on that path only 5. Mark integration milestones (API freeze, env parity, dress rehearsal)

See `references/dependency_risk.md` for dependency types and RAID format.

3. Operating rhythm

• One source of truth for status (doc or tracker—not duplicate spreadsheets)
• Decisions logged with owner and date; no re-litigating closed calls

See `references/status_reporting.md` for status template.

4. Risk and issue management

• Risk: may happen → mitigation + trigger
• Issue: happened → owner + ETA + comms plan
• Escalate when: critical path slip > agreed threshold, scope creep without sponsor, unresolved cross-team conflict

See `references/dependency_risk.md` for RAID columns.

5. Stakeholder communication

• Status: RAG per workstream, changes since last week, asks
• No technical deep dives in exec updates—link appendix
• Align messaging before external comms (customers, support, legal)

See `references/stakeholder_comms.md` for audience-specific formats.

6. Launch readiness

Gate checklist before production:

• [ ] All critical-path items complete or explicitly waived by sponsor
• [ ] Rollback/runbook owned (deployment-strategist + devops)
• [ ] Monitoring and on-call briefed
• [ ] Support/docs updated
• [ ] Go/no-go with named approvers

See `references/launch_readiness.md` for full checklist.

When to load references

• Charter and phases → references/program_charter.md
• Dependencies and RAID → references/dependency_risk.md
• Status and steering → references/status_reporting.md
• Exec and sponsor comms → references/stakeholder_comms.md
• Go/no-go → references/launch_readiness.md

Dependencies and RAID

Table of contents

1. Dependency types 2. RAID log

Dependency types

Document: predecessor, successor, lead time, fallback if slip.

RAID log

Review weekly; close items with evidence, not optimism.

Launch readiness

Table of contents

1. Go/no-go checklist 2. Hypercare

Go/no-go checklist

Engineering

• [ ] Critical path complete or waived
• [ ] Integration and e2e tests pass in staging
• [ ] Rollback tested or time-boxed recovery documented
• [ ] Feature flags or kill switches where applicable

Operations

• [ ] Runbooks and on-call rotation
• [ ] Dashboards and alerts for new paths
• [ ] Capacity and rate limits reviewed

Product / GTM

• [ ] Docs and release notes
• [ ] Support macros / training if customer-facing

Governance

• [ ] Security/compliance sign-off if required
• [ ] Named approvers for go/no-go recorded

Hypercare

• 48–72h elevated monitoring after launch
• Daily stand-down during hypercare
• Retro within 2 weeks: what slipped, what to fix in process

Program charter

Table of contents

1. Charter sections 2. Phase plan

Charter sections

Phase plan

Typical phases:

1. Discover — align scope, dependencies, estimates 2. Build — parallel workstreams with integration points 3. Harden — perf, security review, runbooks 4. Launch — cutover; hypercare window 5. Steady — handoff to BAU owner; retrospective

Each phase ends with a gate: criteria met or explicit waiver.

Stakeholder communications

Table of contents

1. Audience matrix 2. Comms rules

Audience matrix

Comms rules

• Same facts everywhere; tailor depth not truth
• Bad news early with mitigation and new date
• No surprise launches—support and docs in the loop
• Record decisions in RAID, not only in chat

Status reporting

Table of contents

1. Weekly status 2. Steering summary

Weekly status

Header: Program name, report date, overall RAG (G/Y/R)

Per workstream (3–5 bullets max):

• RAG + one-line health
• Completed since last report
• Next 7 days
• Blockers / asks (tag owner)

Program-level:

• Milestone tracker (planned vs actual)
• Top 3 risks
• Decisions needed from sponsors

Steering summary

One page max:

• Objective reminder (1 sentence)
• Overall RAG + trend (↑↓→)
• Schedule: on track / slip (days) / recovered
• Budget or headcount if relevant
• Asks: decisions, staffing, scope tradeoffs