Responding, not reacting
Good judgement isn't about always acting quickly. It's about knowing when to act, when to wait and when not to step in at all.
There's a difference between responding and reacting. It's one I've learnt the hard way, more times than I'd care to admit.
When something changes unexpectedly - a session needs rescheduling, a facilitator has to cancel, a learner raises a concern, the instinct is to deal with it immediately. It feels proactive. It feels like good programme management. But responding and reacting aren't the same thing.
The urgency trap
Reacting is driven by the urgency of the moment. Something happens, and you act. There's no pause. No question. Just motion.
And sometimes that's exactly what's needed. If a joining link hasn't arrived and a session starts in ten minutes, you don't sit and reflect. You fix it.
But not every unexpected change requires an immediate response. In fact, many of them benefit from something slower.
A different question
Responding starts by asking a different question: "What actually needs to happen here?"
It sounds simple, but it's surprisingly easy to skip. The urgency of the moment pushes you straight past it and into action. When you pause to ask that question, the answer isn't always what you expect.
Sometimes the answer is to act straight away. The problem is clear, the fix is obvious and the fastest route is the best one.
Sometimes the answer is to gather a little more information. The full picture isn't visible yet and acting now might create more problems than it solves.
Sometimes the answer is to leave people to resolve something themselves, because they already have everything they need. Stepping in would only undermine their confidence or create unnecessary dependency.
What experience teaches you
This is one of the biggest differences experience makes. Not in knowing what to do in every situation, but in knowing which situations need you to act and which don't.
Early in my career, I thought good programme management meant being on top of everything. If something changed, I wanted to be the first to know and the first to respond. I thought speed was the measure of reliability.
I've since learnt that reliability isn't about speed. It's about judgement.
A colleague once described it as the difference between putting out fires and knowing which fires will burn out on their own. Not everything that looks urgent actually is. And not everything that looks like a problem needs you to solve it.
When not to step in
The hardest skill to learn is knowing when not to step in at all.
If a facilitator is perfectly capable of rescheduling a session themselves, stepping in doesn't help. It takes something off their plate, yes, but it also takes it onto yours. And it sends an unspoken message: "I don't trust you to handle this."
If a learner has all the information they need to find an answer, answering the question for them doesn't save time in the long run. It creates a habit of dependency.
Good programme management isn't about doing everything. It's about creating a system where most things happen without you.
A practical test
Next time something changes unexpectedly, try this before you act:
Pause. Just for a moment. Long enough to ask the question.
Ask: "What actually needs to happen here?" Not "what can I do?" but "what needs to happen?"
Check who it belongs to. Is this your problem to solve, or does it belong to someone else? If it's theirs, your job might be to support, not to take over.
Act with intention. If you've decided to act, act. If you've decided to wait, wait. If you've decided to leave it, leave it. The worst option is to act without deciding.
Good programme management isn't about always acting quickly. It's about knowing when to act, when to wait and when not to step in at all.