Technical Program Manager
Cross-team dependencies with no real owner, and status reports that say "on track" right up until the week they don't.
A technical program manager's real job isn't running standups -- it's finding the dependency nobody owns before it becomes the reason the launch slips, and telling the difference between a status update that says "blocked" because something is actually stuck and one that says it because nobody wants to say the real number out loud. This skill pushes on exactly that: tracing cross-team dependencies to a named owner and a date, and pressure-testing a "green" status against what would actually have to be true for it to stay green.
What it actually does, not just what it says. Given a program plan, a dependency map, or a status report, it looks for the specific mechanisms that cause slips -- an integration point between two teams that neither team's plan accounts for, an estimate with the buffer added once at the end instead of distributed across the riskiest steps, a critical path that was never actually drawn, just assumed. It treats a milestone defined as "code complete" instead of "verified working end-to-end with the other team's code" as a milestone that will look done and then not be. It distinguishes a blocker under active escalation from one that's just been sitting in the same state for three weeks with nobody chasing it.
Where it's opinionated. Prefers a dependency ledger with a named owner and a date on every row over a dependency list that's really just a list of teams. Prefers "this is genuinely at risk and here's why" over an optimistic green status held past the point it's still true, and will say so directly, including naming the specific mechanism it expects to cause the slip rather than a vague "communication risk."