Lead Principal Technical Program Manager

Opening Statement (~60 sec)

On the Prime Video ad-tier launch — a rollout touching 260M members with $1.8B–$3B in incremental revenue on the line — I built a single executive dashboard fed by live telemetry, then layered a reporting agent on top of it that checked the numbers against pre-agreed thresholds every cycle instead of waiting for a person to notice a trend%%. That automation paid off directly: the agent flagged a slow upward trend in one platform's rebuffer rate about two hours before it actually crossed our guardrail threshold, giving engineering a head start most monitoring setups wouldn't have provided. A reporting cycle that used to take about four hours a week came down to twenty minutes of review, and not one quality regression reached a member as a surprise across the entire rollout.

Situation

1. The program's quality guardrails — rebuffer rate, playback-start failures, ad-load pacing — were the difference between a rollout that stayed invisible to members and one that became a public complaint, at a scale where a single regression would read as a broken promise, not a normal bug. 2. Manual, weekly status reporting couldn't catch a trend forming between review cycles, and a steering committee spanning multiple orgs needed one trustworthy answer to "are we on track," not five reconciled versions of it.

Task

My task was to design a reporting system that surfaced a risk while it was still a trend, not after it crossed a threshold, and to do it without leadership relying on someone manually pulling numbers every week.

Action

1. 1.Built one executive dashboard, not five, pulling live from the same systems quality telemetry, entitlement/billing, and support-ticket volume ran on — so what a VP saw matched what engineering saw in real time.
2. 2.Defined pre-agreed quality guardrail thresholds for each metric, so a wave only advanced after holding within all three for a full week of live traffic, and any single breach auto-paused expansion with no manual sign-off required.
3. 3.Layered a lightweight reporting agent on top of the same telemetry pipeline — each cycle it checked the numbers against thresholds and drafted the narrative, with me reviewing and signing off on every draft before it reached leadership.
4. 4.When the agent flagged Fire TV's rebuffer rate trending upward, still inside the threshold, I had engineering start root-causing it immediately instead of waiting for a breach to force the conversation.

Result

1. The trend flag gave engineering a ~2-hour head start on a fix before the guardrail would have auto-paused the rollout. 2. The program held 99.99% availability through the entire global rollout, and not one quality regression reached a member as a surprise. 3. The reporting cycle dropped from ~4 hours a week to ~20 minutes of review.

Closing Statement (~60 sec)

The distinction I'd draw is between a dashboard that shows what's true right now and a system that tells you what a trend means before it becomes a threshold breach. At OCI's scale — server fleets, technician workflows, hardware readiness — the same principle applies: instrument the leading indicator, not just the incident, and use automation to remove the manual pull, never the judgment call about what to do with what it finds.