Project Managers Don't Deliver Projects—Teams Do

Early in my career, I measured my own performance by how much I personally did, how many status updates I wrote, how many meetings I ran, how visibly busy I looked. It took a few years of leading delivery teams to realize that's almost the opposite of what actually correlates with successful projects.

The projects that went best were the ones where the team barely needed me day to day, because I'd already done the less visible work: removing ambiguity from priorities, clearing blockers before they became escalations, and making sure the team had what they needed to make good decisions without waiting on me. On those projects, my value showed up in decisions I made two weeks before they mattered, not in activity anyone could see on a given Tuesday.

The projects that struggled had the opposite pattern - a PM (often me, earlier on) inserting themselves into decisions the team was better equipped to make, out of a desire to feel useful or to protect against blame if something went wrong. That instinct is understandable. It's also corrosive: it slows decisions down, and it quietly signals to the team that their judgment isn't fully trusted, which makes them less likely to exercise it the next time.

The reframe that changed how I lead: my job isn't to deliver the project. It's to build the conditions under which the team can deliver it - clear priorities, fast decisions, protected focus, and psychological safety to flag problems early. Delivery is the team's accomplishment. My accomplishment is whether those conditions existed.

This doesn't mean disappearing or being passive. A team without active leadership drifts just as badly as one that's micromanaged. It means being deliberate about which decisions genuinely need you and which ones you're only involved in out of habit. Most PMs, myself included, are surprised how long that second list turns out to be once they actually look at it.