You are not deciding the outcome. You are deciding who needs to see the problem clearly enough to help decide it.
Every program leader eventually faces the same quiet question: escalate, or absorb? A dependency slipped three weeks before a planned cutover. The team closest to it worked the technical angle for two days, found a workable path, and had a recommendation ready before anyone outside the team knew there had been a problem. It was a good recommendation. It was also missing something nobody in that room could have seen: the staffing plan for a partner team that had built its schedule around the original date, and a budget line that assumed the old timeline held. Both surfaced a week later, after the recommendation had already hardened into a plan. Neither was a surprise to the people who owned them. They were only a surprise to us, because we never asked.
The real question is not escalate or absorb
Every program leader faces some version of this moment. Something breaks, or is about to. The instinct is to treat the choice in front of you as a binary about risk tolerance: push it up, or handle it here. That framing feels practical, but it skips a step that matters more than either option. Both versions of that question assume the job is to decide the outcome. It is not. The job is to decide who needs to see the problem clearly enough to shape the decision with you, before any outcome gets decided at all.
Get that step right and escalate-or-absorb mostly answers itself later. Skip it, and it does not matter which one you picked. You already made the mistake.
Solving in isolation feels like competence
It rarely looks like a mistake in the moment. You have the expertise. You can see the technical shape of the problem faster than anyone else, and looping in four or five other leaders feels like it will slow down a decision that needs to move now. So you work it through with the two or three people closest to the detail, and you arrive at a clean recommendation. It feels efficient. It feels like ownership.
The moment you have a preferred outcome before the impacted people are in the room, you have stopped being a steward of the message and started being an advocate for a conclusion.
That distinction, steward versus advocate, is the whole framework. A steward’s job is to make sure the people who will live with a decision have an accurate, complete picture of the situation in time to shape it. An advocate’s job is to get a particular answer approved. Both can look like leadership from the outside. Only one of them holds up when the problem turns out to be more complicated than it looked from where you were standing, and it almost always is, because you were never standing where everyone else was.
What pulling people in actually looks like
This is not a call for consensus by committee, and it is not about slowing every decision down until everyone has signed off. It is about being deliberate, early, about who is impacted, and getting them the same picture you have before the path forward hardens into something that is socially expensive to change.
- Map every area the problem touches, not just the area where it started. A dependency issue is rarely only a technical issue. It is a staffing issue, a partner-communication issue, sometimes a budget issue, and the people who own those angles will see risk in the first ten minutes that would take the technical team a week to find alone.
- Bring the problem before the recommendation. Share what you know and what you still do not know. Showing up with the answer already built makes it socially expensive for anyone to raise something you missed, even when they can see it clearly.
- Ask the people closest to each impacted area what they see that you do not. Not as a formality. Some of the best catches on this program have come from someone whose piece of the puzzle looked unrelated, right up until they said the one sentence that reframed the whole problem.
- Decide together what happens next, even if you are the one who ultimately carries it forward or escalates it further. The value is not in a vote. It is in the decision being shaped by everyone who has to live with it.
Escalate or absorb becomes an easier question once you have done this
Here is the part that surprised me the first few times I actually practiced it. Once the right people are in the room with an accurate picture, the escalate-or-absorb question mostly answers itself. If the impacted leaders look at the full picture and see something the group can handle within its own authority, you absorb it together, and everyone downstream already understands why. If they look at the same picture and see something that needs a decision above your collective authority, escalation is not a failure or an admission you could not handle it. It is the natural next step for a group of people who already did the hard work of understanding the problem the same way, clearly enough to hand it up in a form someone else can act on.
Either way, nobody is blindsided later. Nobody finds out secondhand that a decision touching their team was made in a room they were never invited into.
Where AI actually helps here
This is not a step to automate. Deciding who belongs in the room is a judgment call, and the value of that call comes from actually talking to the people in it, not from a checklist that generates itself. What a thinking partner is genuinely good for is stress-testing the map before you convene anyone. Describe the problem and ask it to push back on your list of impacted areas: what teams, budgets, or partner relationships touch this that you have not named yet. You want the gaps in your own picture surfaced in private, before the meeting, not live in front of the people you invited.
It is also useful after the fact, on the discipline itself. Feed it your notes from a recommendation that hardened before the right people saw it, and ask what would have looked different if the impacted leaders had been in the room three days earlier. That kind of after-action read is easy to skip when the outcome turned out fine anyway. It is exactly the pattern that catches up with you on the next one.
None of that replaces the room. It only makes sure you know who belongs in it before you start.
Being a steward of the message means the people affected by a decision never learn about it after the fact. They were in the room while it was still a question.
More essays like this one live on the Between Mondays articles page.
Further reading: the Project Management Institute on governance and escalation paths in program management, and the U.S. Government Accountability Office, which publishes extensively on risk oversight and reporting discipline in large public programs.