You are reading a paid post from my newsletter — The Art of Doing Technical Program Management. I write with an aim to demystify the art of technical program management and deliver proven real-world strategies, practical advise and tips, and actionable frameworks to help you level up as a Technical Program Manager.
Upgrade To Paid - 20% OFF Annual Plans
If you already are a subscriber and found this essay helpful, please share it with your colleagues and network. I am sure others might find it useful as well.
🧭 Road to Staff+ TPM is my premium series on becoming the TPM your organization turns to when the playbook no longer works. We’ll explore the judgment, systems thinking, influence, and leadership required to thrive in increasingly ambiguous environments - one practical lesson at a time.
One Project. Three Different TPMs.
Every phase of a project asks you to become a different version of yourself.
The TPM I need during planning is completely different from the TPM I need three months later, and different again from the TPM I need closer to launch. Yet most of us try to operate exactly the same way from kickoff to launch.
We cling to our process playbooks and stay rigid. When the pressure becomes too much, cracks begin to appear and things go pear-shaped.
We run the same meetings.
Ask the same questions.
Escalate the same way.
Manage risk the same way.
And then wonder why a project suddenly feels harder than it should.
The project did not suddenly become something else. The environment changed, the expectations changed, the challenges changed. And when the environment changes the TPM must change with it.
This has become one of the biggest distinctions I notice between experienced TPMs and Staff+ TPMs. The latter aren’t just executing a project. They’re constantly changing how they lead it. As the project lifecycle progresses, they find opportunities to stay nimble, stay focused, stay on top of things by constantly switching their mindset.
TPM isn’t just a skill.
It’s an operating system. I used to think becoming a better TPM meant collecting more tools.
Better templates.
Better dashboards.
Better planning docs.
You wouldn’t be at fault thinking this way because the beginning portion of your TPM career as you acquire new skills and capabilities does come in the shape of these tools. But, climbing beyond mid-level TPM means, something different. Eventually I realized something: Two TPMs can use the exact same framework and produce completely different outcomes.
Why? Because frameworks don’t make things happen alone. Mindsets do.
Your mindset determines
what you pay attention to
what you ignore
how quickly you move
how much uncertainty you tolerate
what signals you amplify for the team
The methodology is often the least interesting part. The operating system underneath matters far more. As I often tell new TPMs that the Art of Doing Technical Program Management is:
Part knowledge.
Part application.
Part experience.
But almost entirely mindset.
The challenge is that most of us never consciously change our mindset. We simply carry yesterday’s operating system into today’s environment.
Staff+ TPMs don’t.
They recognize that every phase of a project demands something different from them. Here’s the simple framework I use.
I’ll walk through each phase, explain why the environment changes, and more importantly, how your mindset should change with it.
Phase 1 - Planning
This phase has an environment that is uncertain, ambiguous, filled with incomplete information.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.