I made these 5 programme management mistakes, so you don’t have to

"The only way to atone for being occasionally a little over-dressed is by being always absolutely over-educated in the art of management."

Most program managers fail in predictable ways. This isn't because they're incompetent. It's because the role itself is poorly understood. People think program management is just project management at scale. It's not. It's closer to being a systems architect for human organizations.

I've watched hundreds of program managers over the years, and the good ones all avoid the same basic mistakes. The bad ones make them over and over, like tragic characters in a very boring play. Here's what actually matters.

1. Not Managing Interdependencies Between Projects

"We are all in the gutter, but some of us are looking at interdependencies."

This is the big one. Programs aren't just collections of projects. They're networks. The value comes from the connections, not the nodes.

When you ignore interdependencies, you get what I call "project island syndrome." Each project looks healthy in isolation, but the program dies anyway. It's like optimizing individual functions without understanding the system they're part of. The result is almost always the same: late delivery, blown budgets, and a final product that nobody actually wants.

The math is simple but brutal. If you have five projects with dependencies and each has a 90% chance of hitting its milestone, your program has roughly a 60% chance of success. Miss those dependencies entirely, and you're basically flipping coins.

What to do: Start every program with a dependency mapping session. Get all project leads in a room and map out what each project needs from the others and when. Update this monthly. Create a simple tracker showing which dependencies are at risk and who owns resolving them. When projects slip, immediately assess downstream impact and communicate changes to affected teams within 24 hours.

2. Talking Only in Email

"I can resist everything except temptation, and the temptation to solve everything by email."

Email scales poorly for complex decisions. It's like trying to debug code through comments. Technically possible, but you're going to miss things.

The program managers who succeed have figured out that their job is fundamentally about information flow and decision-making. Email creates artificial delays in both. A five-minute conversation can resolve what takes twenty messages to even approach.

But here's what most people miss: it's not just about speed. Email strips out all the metadata that humans use to make decisions. Tone, urgency, confidence levels, political context. When you're managing interdependent projects, that metadata is often more important than the actual content.

What to do: Institute a "15-minute rule." If an email thread hits three back-and-forth exchanges without resolution, pick up the phone or schedule a quick call. Set up weekly 30-minute office hours where anyone can drop in with questions. Use Slack or Teams for real-time coordination, but follow up important decisions with written summaries. Reserve email for information sharing, not decision making.

👋 Want to Learn More?

If you want to go deeper, I've put together resources to help:

• LinkedIn Guide: Optimize Your Profile for Success

• ChatGPT Resume Creation Guide (Full prompts)

• How to use the 80:20 rule to get more done in less time.

3. Not Knowing the Detail of Projects

"A little sincerity is a dangerous thing, and a great deal of it is absolutely fatal, but complete ignorance of project details is merely unprofessional."

There's this persistent myth that program managers should stay "strategic" and avoid getting into the weeds. This is complete nonsense, like saying a compiler shouldn't understand syntax.

You can't manage risks you don't understand. You can't make trade-offs without knowing what you're trading. And you definitely can't maintain credibility with project managers who are living in the details every day.

The trick is knowing which details matter. Not all of them do. But the ones that do matter a lot. Dependencies matter. Blockers matter. Technical debt that affects timelines matters. Resource constraints matter.

What to do: Spend one hour per week in each project's working sessions (not status meetings). Ask three questions: What's your biggest risk right now? What would you need to go 20% faster? What decisions are you waiting on? Create a simple "blocker board" that tracks issues across all projects. Review it weekly with project leads and commit to resolving at least one blocker per project per week.

4. Not Knowing What Is Important to Senior Leadership

"When the gods wish to punish us, they make us focus on deliverables while leadership cares about outcomes."

This one kills more programs than technical problems do. You can execute perfectly and still fail if you're solving the wrong problem.

Leadership priorities aren't always obvious, and they change more often than anyone admits. What seemed important six months ago might be irrelevant now. If you're not plugged into that context, you're building the wrong thing.

The best program managers I know spend significant time understanding the business context around their work. They read board decks. They attend strategy meetings. They ask questions like "What happens if we're six months late?" and "What's the cost of not doing this at all?"

What to do: Schedule monthly 20-minute sessions with each key stakeholder. Ask them: What's keeping you up at night? How will you measure success for this program in six months? What would make you want to kill this program? Create a simple one-page "leadership dashboard" that shows progress on what they actually care about, not just project milestones. Update your program goals quarterly based on these conversations.

5. Thinking It Is Project Management

"Program management is not project management wearing evening dress. It is an entirely different species of beast."

This is the fundamental confusion that creates most other problems. Project management is about execution. Program management is about orchestration.

Project managers ask "How do we build this?" Program managers ask "Should we build this, and if so, how does it fit with everything else?" Different questions, different skills, different mindset.

The transition from project to program management is like the transition from coding to architecture. You need to think in systems, not just components. You need to understand emergence, how complex behaviors arise from simple interactions. You need to optimize for the whole, not the parts.

What to do: Stop attending project status meetings. Instead, run monthly "program health checks" focused on alignment, dependencies, and outcomes. Spend 50% of your time on coordination between projects, not within them. Create a simple "program charter" that explains how individual projects contribute to overall goals. Review and update it quarterly. When projects request changes, always ask: "How does this affect the other projects?"

Bonus: Not Using Your Influence

"We live in an age when unnecessary authority is our only authority, and the only influence we have is the influence we fail to use."

Program managers are in a weird position organizationally. They have responsibility without authority. They're accountable for outcomes they can't directly control. This makes influence their primary tool.

But influence isn't magic. It's a skill you can develop systematically. It starts with being right about important things, consistently, over time. It grows when you help other people be successful. It compounds when you become known as someone who makes good decisions under uncertainty.

The program managers who struggle with influence are usually making one of two mistakes: they're either too passive (waiting for someone else to make decisions) or too aggressive (trying to force outcomes through process and escalation).

What to do: Start a "decision log" tracking what you predicted and what actually happened. Share wins publicly but take blame privately. When problems arise, come with solutions, not just status updates. Build relationships before you need them by helping people with small requests. Create a monthly "program newsletter" highlighting team wins and lessons learned. Always give credit to others for successes.

Why This Actually Matters

"We are all in the gutter, but some of us are managing programs."

The dirty secret of most organizations is that their big initiatives fail not because of technical problems, but because of coordination problems. They have smart people, good technology, and adequate resources. What they don't have is effective program management.

This matters more than most people realize. In a world where competitive advantage increasingly comes from execution speed and organizational learning, program management becomes a core competency. Companies that are good at it ship faster, waste less money, and adapt more quickly to changing conditions.

The program managers who understand this, who see themselves as systems architects for human organizations, end up being unusually valuable. They become the people you call when you have a really important, really complex initiative that absolutely has to work.

That's a good place to be.

All the best,

Jonathan