The Part of Program Leadership the Job Title Never Mentions
Years ago, during a network migration at Level 3, a client VP asked if I'd personally join the overnight maintenance windows when we cut his company's circuits over to our network. He didn't need another engineer on the call. He needed someone who could sit between his anxiety and our engineers' technical reality and tell him the truth in a way he could actually use.
That's most of the job. It's also the part I've never once seen written into a program manager's job description.
Schedules, status decks, the standing sync: that's the visible layer, and it's the layer that gets automated first. The work that actually keeps a program alive is translation. Taking a technical team's reality and making it legible to a nervous stakeholder. Taking that stakeholder's fear and turning it into something the technical team can act on. The programs that survive bad news usually have someone doing this quietly in the background, before the fear or the technical reality curdles into something worse.
I relearned this with a Japanese telecom client who came into a migration already skeptical, burned by a bad experience on the same infrastructure years earlier. Reassurance would have been easy and useless: trust us, it's better now. What worked instead was going through the specific concerns one at a time, with the actual reasoning behind why this migration would go differently, answering the worry instead of talking past it.
The same instinct matters more when the news is genuinely bad. I once ran a program consolidating eight acquired companies' back-office systems into one. Every company told us their systems were clean and well-documented going in. Several weren't. What mattered in that moment wasn't the mess itself, it was whether I said so immediately or let it sit. I've never had patience for what I call watermelon reports: green on the outside, red in the middle. Say the real state of things early and a program can still adjust around it. Sit on it, and you find out how much worse it got only after it's too late to do much about it.
None of this shows up in a resume bullet. It shows up in whether a client's executives believe what you tell them, whether an engineering team trusts you to represent their constraints upward accurately, and whether a program in real trouble gets solved instead of turning political.
This is the actual job, whether or not it's in the description. Translating in both directions. Telling the truth early enough that it's still useful. Holding a program together when the easier move is to let it drift and hope.
If that gap sounds familiar, I'd like to hear about it.
