Senior Technical Program Manager at Spotify: Comprehensive Interview Preparation Guide

Risk register structure/key fields: 1) ID; 2) Title; 3) Description; 4) Category (technical/operational/security/regulatory/financial); 5) Probability (low/med/high or %); 6) Impact (low/med/high or $/days); 7) Expected Loss; 8) Owner; 9) Mitigation actions; 10) Contingency plan/trigger; 11) Status; 12) Target dates; 13) Last updated. Example entry for security vulnerability: - ID: R-2026-001 - Title: Vulnerable dependency (libXYZ) with CVE - Description: Transitive dependency libXYZ has CVE-2026-XXXX allowing RCE in parsing path - Category: Security - Probability: Medium (30%) - Impact: High (possible customer data exposure, remediation 2 weeks) - Expected Loss: $150k - Owner: Security Lead (Jane Doe) - Mitigation: patch dependency, run regression tests, apply WAF rule - Contingency/Trigger: exploit detected in wild or failed patching → rollback and hotfix pipeline - Status: In progress - Target: Patch deployed by 2026-03-10.

Situation: I coordinated a launch that required two engineering teams, a data team, and a partner team, all with different release calendars.

Task: My job was to align the plan so we could hit the target date without forcing any team into a risky last-minute scramble.

Action:

• I built one integrated milestone plan with clear owners and dependencies.
• I held a weekly cross-functional sync and a separate working session for unresolved blockers.
• I translated engineering risks into business impact so stakeholders understood trade-offs.
• When priorities conflicted, I used a decision log to capture what we delayed and why.

Result: We shipped on time with no major launch-day blockers, and the shared tracker became the default planning tool for the next program.

What I learned was that alignment is less about constant meetings and more about making decisions visible early.

Scaling approach: combine automation, risk tiering, and lightweight governance. Tooling: portfolio risk registry (Confluence/Jira + reporting), automated ingestion from CI/CD and monitoring (alerts → risk signals), and dashboards (Power BI/Grafana) with heatmaps. Processes: 1) Tier projects (Critical, Important, Low) using impact & exposure; TPM resources focus on Critical (top 20%). 2) Standardize risk templates and acceptance criteria so project teams self-report using owners and mitigations. 3) Automate monitoring: map alerts to risk entries; runbooks auto-trigger reviews. 4) Monthly portfolio review with RAG scoring and exception management. Prioritization heuristics: expected value of risk (probability × impact), centrality (cross-project dependencies), regulatory deadline proximity, and mitigation cost-to-benefit. Staffing: create risk champions embedded in teams to decentralize day-to-day activity; TPMs handle orchestration and escalations. Metrics: number of active high risks, time-to-mitigation, and residual risk trend. This enables coverage of 50 projects with limited central resources while maintaining governance.

I’d build a capacity-constrained portfolio roadmap by first mapping all initiatives against shared platform and infrastructure dependencies.

Step 1: Classify demand

• Break initiatives into must-do, should-do, and could-do
• Identify which ones need the same scarce teams, environments, or release windows
• Estimate effort and dependency criticality

Step 2: Sequence by constraint

• Put foundational platform work first if it unlocks multiple programs
• Avoid stacking two high-load initiatives on the same infra team
• Use dependency-driven milestones so downstream teams are not blocked late

Step 3: Manage contention

• Create a capacity model showing committed vs. available bandwidth
• Reserve a buffer for production support and unplanned work
• Negotiate timing early rather than overcommitting and renegotiating later

Step 4: Communicate clearly

• Publish a portfolio roadmap with assumptions, constraints, and decision points
• Review it monthly with engineering, product, and infrastructure leaders
• Call out what is explicitly not happening yet so expectations stay realistic

The biggest trade-off is between maximizing throughput and preserving stability. In a constrained environment, I’d optimize for sequencing that reduces blocked work, protects critical teams, and keeps leadership aware of the capacity bottleneck before it becomes a delivery failure.

Rubric: score Probability (1–5) and Impact (1–5); risk score = Probability × Impact (1–25). Probability levels: 1 (Rare, <1%/year), 2 (Unlikely, 1–5%), 3 (Possible, 5–20%), 4 (Likely, 20–60%), 5 (Almost Certain, >60%). Impact levels (applies across technical, financial, regulatory): 1 (Negligible: no service impact, <$10k), 2 (Minor: small degradation, $10–100k), 3 (Moderate: customer experience affected, $100k–$1M), 4 (Major: sustained outages or material financial loss, $1M–$10M or regulatory notice), 5 (Critical: breach, legal action, multiyear reputational/regulatory harm, >$10M). Define thresholds: 1–6 Green (accept), 7–12 Yellow (monitor/mitigate), 13–25 Red (action required). Align with risk appetite by mapping acceptable maximum scores per domain (e.g., regulatory risks: appetite low -> any score ≥7 triggers legal review). Use qualitative descriptors and examples so stakeholders consistently score risks; include periodic calibration sessions and require documented owner and mitigation for Yellow/Red.

To detect schedule drift early, I’d monitor leading indicators, not just milestone dates.

Signals I’d track

• Task aging and cycle time by workstream
• Percent of critical-path items completed on time
• Dependency slip rate and unresolved blockers
• Scope churn, reopened work, and defect inflow
• Capacity vs. plan, including unplanned work

Thresholds

• Yellow: one critical dependency slips by > 3 days or cycle time trends up for 2 weeks
• Red: multiple critical-path items slip, forecast confidence drops, or recovery actions are not closing
• I’d also compare actual burn-down against planned burn-down, not just end dates

Making it actionable

• Put the metrics into a simple dashboard with RAG status and trend arrows
• Require each red signal to have an owner, mitigation, and next review date
• Review exceptions in weekly execution meetings, not in a separate reporting ritual

For example, if testing throughput drops while scope stays flat, I’d flag a likely slip weeks before the launch date and force a decision on scope, staffing, or sequencing. The key is turning data into a decision, not just a report.

Framework: produce three scenarios (best/base/worst) with clear inputs, stakeholders, and outputs to show timeline impact and decision levers.

Inputs:

• Regulatory trigger events and timelines (draft rules, consultation periods)
• Internal readiness (engineering effort, testing, certification time)
• External dependencies (third-party approvals, legal review durations)
• Probability estimates and mitigation options

Stakeholders: Legal/Regulatory, Product, Engineering, Compliance, Sales, TPM.

Approach:

• Best-case: regulation delayed/clarified quickly; only minor code changes; timeline slip = 0–2 weeks.
• Base-case: expected rule adoption with medium changes; timeline slip = 4–12 weeks; requires prioritized feature work and compliance sprint.
• Worst-case: additional certification or product redesign required; timeline slip = 3–6 months; potential market hold.

Outputs:

• Timeline Gantt variants showing critical path shifts
• Cost estimates for catch-up effort and resource reallocation
• Risk register entry with triggers (e.g., publication date) and contingency plans

Use: present to execs with recommended trigger-based actions and contingency budgets tied to each scenario.

I would sequence work by combining business value, dependency order, and capacity reality.

My approach:

• Identify what is on the critical path versus what can run in parallel.
• Rank work by risk reduction and customer impact.
• Check whether a team’s bandwidth makes parallel work unsafe.
• Delay lower-value work if it protects a launch-critical milestone.

How I communicate it:

• I explain the trade-off in plain language: what moves, what slips, and what risk we avoid.
• I use a short decision note or roadmap update so stakeholders can see the rationale.
• I make sure teams know the sequencing is intentional, not arbitrary.

For example, if integration work blocks all testing, I would prioritize that over feature polish, even if polish is visible. TPM credibility comes from making the trade-offs explicit and consistent.

Approach: quantify residual risk per project, roll up to portfolio, surface KPIs and dashboards that inform executive trade-offs (funding, scope, acceptance).

Measurements & KPIs:

• Residual Risk Value (RRV): sum of expected-loss after mitigations ($) per project
• Risk Density: RRV / Project Budget
• Top-10 Risks by RRV and by probability
• % Projects above Appetite: count where RRV > project-specific appetite
• Trend: 30/60/90-day change in total portfolio RRV
• Mitigation Coverage: % of top risks with active mitigation plans and assigned owners
• Time-to-Mitigation: median days to implement high-priority mitigations

Dashboards:

• Executive Summary: total portfolio RRV, change vs last period, top 5 risk drivers
• Project View: drillable card per project with RRV, top risks, mitigation status, ETA, owners
• Heatmap: probability vs impact buckets across portfolio
• Forecast: projected RRV after planned mitigations + cost to reduce to appetite

Ensure executive utility:

• Tie RRV to dollars and strategic objectives (revenue, regulatory exposure)
• Provide decision options: accept, fund mitigation (cost & ROI), or de-scope
• Monthly governance: present 3 scenarios (status quo, fund top N mitigations, accept risk) with one recommended action
• Data quality: enforce mandatory fields in PM tool; periodic audit; link to tickets for traceability.

I’d run the recovery in three phases: triage, replan, and decision.

1) Triage immediately

• Confirm the missed dependency, quantify the downstream block, and identify the critical path impact.
• Pull together the upstream team, downstream leads, QA, and release management in a short war room.

2) Replan fast

• Break blocked work into what can continue, what can be parallelized, and what must wait.
• Re-estimate the recovery path and identify whether a partial release is possible.

3) Communicate clearly

• Tell stakeholders what happened, what is impacted, and when the next update will come.
• Avoid speculation; share facts, options, and recommendations.

Decision-making

• If the blocker is recoverable within the release window, I’d recommend a focused recovery plan with daily check-ins.
• If not, I’d propose slipping the train or scoping down the release to protect quality.

For example, if one upstream API is late, I’d ask whether downstream teams can stub or decouple against a contract. If yes, we preserve velocity; if no, I’d make the delay explicit and reset expectations immediately. Speed matters, but clarity matters more under pressure.