Programs are about the seams
A program is a set of projects whose value only appears when they land together. My job is the seams between teams: the handoffs, shared dependencies and mismatched assumptions where programs actually fail. I spend most of my time where two teams meet, not inside any one of them.
One source of truth
Every program I run has a single, current status that anyone can read in two minutes: what is on track, what is at risk, and what decision I need from whom. Status that lives in five people's heads is how programs drift for a month before anyone notices.
Escalate early, escalate small
I would rather raise a risk while it is cheap to fix than protect a green status until it is a crisis. I make escalation normal and blame free, so teams flag problems to me instead of hiding them. A program manager who only delivers good news is useless.
Sequencing beats speed
Most program delays come from doing the right things in the wrong order. I map the critical path and protect it ruthlessly, letting non blocking work flex around it. Going faster on a non critical task feels productive and changes nothing.
Real example
At SmartNews I ran a cross-team Ads program spanning product, data and sales enablement. Each week a single dashboard and a 30 minute sync replaced scattered updates, and decisions that used to take a week were made in the room. The launch hit its advertiser-cycle date.