I had a program that was technically "on track." Every milestone was green. Every status update said "progressing." And yet, a critical requirement had been bouncing between three teams for three weeks — not because anyone was avoiding it, but because no one had actually made a decision about who owned it.
Program management has a dirty secret: the status of a milestone doesn't tell you whether your program is actually moving.
Milestones track outputs — documents written, meetings held, designs completed. They tell you what happened. What they don't capture is the decision that had to be made before any of that work could go forward. And in cross-functional programs — the kind where you're coordinating legal, policy, engineering, and product across ten or more teams — undecided decisions are the actual bottleneck, not undone work.
The trouble is that "decision pending" doesn't show up on a Gantt chart. It hides inside "in progress" and "blocked" and "under review." It takes up three lines in a weekly status update without changing the color of any cell.
I've run compliance and regulatory programs where a single unresolved ownership question — who is responsible for this? — held back six engineers for two weeks. Not because they couldn't do the work. Because no one had the authority to tell them to start.
Milestones track whether the train is at the station. Decisions determine whether the train is going anywhere.
Earlier this week, I had a requirement that had been technically "open" for nearly three weeks. It sat in the open column of my tracker. It appeared on agendas. It received status updates that said "progressing." It was assigned to "TBD."
The requirement was this: for sellers in certain markets to go live on regulated storefronts, they need to pass an identity verification check before streaming to buyers in those countries. Clear enough on paper. But in a multi-team regulatory program spanning platform engineering, product, and policy, "clear enough" is not the same as "owned." Three different teams knew about it. Nobody was driving it because nobody had been told they were the one.
My usual move: add to the weekly sync agenda, read out the status, ask for updates. The status updated. The ownership didn't.
What I did differently: I set up a fifteen-minute pre-sync call with three specific people — before the broader group convened. I came in with a draft RACI, not a question. I had already written down who I believed should be Responsible, Accountable, Consulted, and Supported, with a one-sentence rationale for each assignment. My opening line was: "I want to propose this, and I want us to either approve it or give me a counter before this call is over."
Seventeen minutes later, we had it. One team became the driver. Another became support. The requirement moved from "open" to "in progress" in the same meeting it was properly scoped — and the work that had been waiting behind it started within twenty-four hours.
The insight wasn't the RACI. RACIs are a tool, and tools don't drive outcomes. The insight was that I stopped treating this as an information problem — a status I needed to surface — and started treating it as a decision problem I needed to force.
Three weeks of "TBD" disappeared because I walked into a room with a draft answer.
This pattern shows up in every program I've run. That same week, I was reviewing a milestone plan for a major regulatory compliance project — forty-six milestones, some with dates filled in, seventeen with nothing. I didn't just add estimated dates; I flagged a structural problem: five implementation milestones had end dates that fell inside a code freeze window, meaning they implied work that was legally impossible to complete. Those weren't tracking failures. They were decisions that hadn't been made — specifically, the decision that "done by Nov 30" actually meant "done by Nov 14, because the code freeze starts Nov 20." Nobody had forced that conversation yet.
When I look back at the programs that slipped, the root cause was almost never a technical failure. It was an unresolved decision that calcified into a dependency, and a dependency that nobody was responsible for clearing.
Here's what I've started doing differently:
I run a separate decisions log alongside my milestone tracker. Not just a RACI — a running list of discrete choices that need to be made, each with a target date and a named decision-maker. When a milestone is blocked, my first question isn't "what's left to do?" It's "what decision hasn't been made?"
I've also gotten explicit about what kind of meeting I'm calling. Is this an information meeting or a decision meeting? Those are different things that require different prep. An information meeting needs an agenda. A decision meeting needs a draft answer — a proposal someone can react to, approve, or reject. "What do you think we should do?" almost always lands worse than "Here's what I think we should do — what am I missing?"
This shift requires being willing to be wrong in public. Walking in with a draft answer means someone can push back on it. That's the point. It forces the conversation from "let's discuss" to "let's decide." Most programs drift toward information sharing because decisions are uncomfortable — they require someone to commit, which means someone can be wrong.
The TPMs who move fastest aren't the ones with the best trackers. They're the ones who force decisions.
When did you make this shift — or are you still in the tracker-first mode? I'm curious whether this is something others have named explicitly or whether it just quietly changes how you run your programs over time. Drop a comment with the moment it clicked for you.
