Learn

👨‍🏫 The TPM Craft Newsletter is moving to Substack

I'm writing to share some news about this newsletter!

I’m in the process of moving The TPM Craft to a new platform called Substack to improve your experience.

This post is the last one to be sent from the platform Beehiiv.

You can find the Substack version of The TPM Craft here.

The main reason for this change is to make the newsletter even better for you. Substack offers:

• A cleaner reading experience with in-app reading. This is an alternative choice to reading direct in your email inbox.

• A great in-app community with features like chat and comments. This will make it easier for us to connect and for you to engage with the content and with each other.

• If you consume other newsletters from Substack, it makes it easier for you to manage all your reading.

Don't worry, your subscription will be carried over automatically and the newsletter will remain completely free. You don't need to do anything at all.

👉 Target Date for migrating all existing subscribers is September 8, 2025.

Upcoming 3-part Series on AI System Design

Exclusive on the Substack version of The TPM Craft, I’ll be publishing a 3 part series on AI System Design.

• Part 1: Do you REALLY understand how ChatGPT works? Scalability Innovations

• Part 2: Do you REALLY understand how ChatGPT works? Inputs and Encoding

• Part 3: Part 2: Do you REALLY understand how ChatGPT works? Decoding and Outputs

This series will be shared on September 9, 10, and 11.

If you want to make sure you get these, subscribe today to the new Substack-hosted TPM Craft Newsletter.

Additional Context

I don’t want this to make Beehiiv look like a lesser product.

In reality, it is an amazing product! I was an early adopter of the platform and am extremely optimistic about the future of the product.

However, I don’t think the low-volume content style newsletter that I have here is the best fit for Beehiiv.

When I started the TPM Craft Newsletter, I was uncertain what it would become. Beehiiv offers an incredible platform for turning a newsletter into a sustainable business. It caters email marketing blended with personable newsletters and has really amazing, high-margin monetization capabilities.

However, The TPM Craft newsletter was never really intended to turn into a sustainable business. Monetization hasn’t been the core motive for me to write this content.

In fact, I love the fact that I can continue providing this free content!

Seeing how the trajectory of The TPM Craft newsletter isn’t full monetization and pay-walled content, the community-focused experience of Substack is more aligned with the direction I want to take this newsletter.

Beehiiv, it’s not you…it’s me. 😅

Opt Out

If you don’t want to move to the Substack version of this newsletter, now is your chance to unsubscribe so that you’re not moved over. No hard feelings if you choose to unsubscribe!

Sad to see you go, happy and grateful that you joined The TPM Craft newsletter for a bit!

Learn

👨‍🏫 Context Mapping for Better Collaboration

Story Time: From My Deep Context to Their Confusion

I remember a time when I was deep in the trenches, responsible for driving the remediation of compliance and security gaps across hundreds of repositories spanning several different products.

I was extremely familiar with the nuances of these gaps from a technical perspective and a compliance control perspective.

I was living, breathing, and dreaming of those nuances. My closest collaborators, the ones working alongside me day in and day out, were in the same boat. Our context was crystal clear.

But…this wasn’t the case for everyone who needed to be involved.

When we scaled this work beyond our core group and began pulling in hundreds of other engineers, that consistent context simply wasn't shared across everyone. (surprised, surprise!)

The request we made to these teams for remediation was, on the surface, trivial. It would probably take a single engineer a couple of hours, a single pull request, and boom! the compliance gap would be closed.

However, despite our best efforts to communicate context clearly, there were challenges. What we saw was a huge variety of engagement, directly correlating with how much context the repository owner had on the problem.

On one end, our infrastructure engineering teams ran with it immediately, often closing gaps quickly because their context already aligned closely with the problem's criticality.

On the other, some marketing analytics teams needed a truly "white glove" approach, requiring us to walk them through the context step-by-step, patiently explaining the "why" and guiding them through the "how."

This is a context gap.

A context gap is a major risk to program or project momentum. As Technical Program Managers, we are accountable for driving momentum towards outcomes, which means we must be keenly aware of these gaps and how they impact our work.

The Context Gap: It's Not What You Think

The context gap isn't about intelligence or dedication. It's simply a function of different roles and responsibilities.

While you're knee-deep in the problem, your engineering leads might be focused on architectural decisions, your product managers on market fit, and your stakeholders on business outcomes. They have their own critical contexts, which means they won't always have the same granular understanding of the problem domain that you do.

Ignoring this gap leads to problems. So many problems. But it is a good thing you are a skilled Technical Program Manager that can help bridge the context gap!

Bridging the Gap: Your Superpower

This is where context mapping becomes your superpower.

In fact, I believe this is one of the major value propositions of the TPM role! There are not many roles that are juggling so many different contexts and can paint the full picture of the context for everyone to understand.

Context mapping is the conscious effort to understand how much context each of your collaborators has on the problem domain and then adapting your collaboration style accordingly. It's about meeting people where they are, not expecting them to instantly absorb your entire understanding.

Visualizing the Context Gap: Your Concentric Circles

To truly grasp this, think of context as a concentric circle map, with you, the TPM, at the very center. In that innermost circle is your deep, nuanced understanding of the problem domain. You have the context.

Around you are layers of collaborators, each residing in rings with varying degrees of shared context regarding your specific problem:

• Your Core Team (Inner Ring): These are your closest collaborators! Your immediate engineering leads, key architects, or the few individuals that are living and breathing the nuances of a problem like security gaps alongside you. Their context level is high, often mirroring yours.

• Wider Engineering Teams (Mid Ring): This layer includes teams like the infrastructure engineers from our story. They possess a solid technical foundation and may quickly grasp technical requests, but they might not have the same daily immersion in your specific problem's strategic importance or intricate history. They need clear "what" and "why," but less hand-holding.

• Cross-Functional Partners & Broader Stakeholders (Outer Rings): This extends to teams like the marketing analytics group, product managers, legal teams, or executives. Their primary context lies in their own distinct domains, making your problem more tangential to their immediate priorities. They require explicit context-setting, simplified explanations, and a clear articulation of impact, often needing that "white glove" approach.

Your role as a TPM is to appreciate and navigate these concentric circles.

Recognizing where each person or team sits on this map instantly informs how you should communicate, what level of detail to provide, and what expectations you should set. It's about bridging the distances between these circles, rather than assuming everyone lives in your central sphere of understanding.

Context Mapping in Practice

1. Assess the Current Context Level

Before any significant interaction, take a moment to consider:

• Empathize with their domain: Take a moment to truly appreciate the distinct world your collaborators operate in. What are their priorities? What metrics are they accountable for? How do they measure success? Understanding their constant context helps you frame your information in a way that resonates with their immediate concerns and challenges, fostering greater empathy and more productive interactions.

• Evaluate Context Exposure: Have they been involved since day one, or are they just getting looped in? This will change your approach in a pretty drastic way. For many scaled efforts, context is lacking for most of teams initially.

• Consider Their Seniority: Are you communicating with a junior IC engineer? Or the Chief Product Officer? These roles have very different spheres of influence and focus. Understanding this can help you tailor your approach for the best collaboration style.

For example, when discussing a critical technical dependency with an executive, they likely need the "what" and the "why it matters," not necessarily the intricate "how" of the implementation. Conversely, a new engineer on the team will need a much deeper dive into the technical nuances.

2. Tailor Your Communication

Once you've assessed the current context, adjust your communication style:

• Be explicit, not implicit: What's obvious to you may be completely new to someone else. Don't assume shared understanding. Clearly state the problem, the proposed solution, and the impact.

• Vary your level of detail: Provide just enough information to enable understanding and decision-making for that specific audience. For those with less context, start with the high-level overview and gradually add details as needed. For those with more, you can dive straight into the specifics.

• Pre-wire and follow up: For crucial discussions, consider pre-reading materials or quick syncs to bring people up to speed before the main meeting. After a discussion, summarize key decisions and action items, reinforcing the shared understanding.

3. Adjust Your Expectations and Appreciate Their World

This is perhaps the most crucial part of context mapping. When you understand someone's context level, you can set realistic expectations for their contributions and their speed of understanding:

• Anticipate questions: If someone has limited context, they're likely to have more questions. Welcome them as opportunities to clarify and reinforce understanding.

• Don't mistake lack of context for lack of engagement: Just because someone doesn't immediately grasp the nuances doesn't mean they aren't invested. They simply need you to help them build that understanding.

• Tailor the Approach: Finally, determine how high-touch your collaboration needs to be with this team to support them receiving and grasping the full context. Ultimately, you want to empower them to be self-sufficient with all the necessary context but what it means to deliver that looks different based on all the previous steps.

A Word of Caution: Not a One-Time Fix

It's vital to remember that context mapping isn't a "one-and-done" activity. Organizations are dynamic ecosystems. Strategies shift, team structures evolve, and people constantly come and go.

The context you painstakingly build today might be outdated next week. Treat context mapping as an ongoing practice (a regular check-in with your collaborators' understanding) to ensure you maintain momentum and mitigate future context gaps.

The Payoff: Tight Collaboration

You want to keep your program locked in? Always consider the context gaps.

By actively mapping context and adjusting your approach, you'll find that collaboration becomes smoother, decisions are made more efficiently, and your programs move forward with less friction.

It's a fundamental shift in how you lead and interact to become a High Impact Technical Program Manager.

Happy TPM’ing!

Resources

🎧️ The TPM Ridge Podcast

Doron Katz has been leading the charge in creating a top-notch podcast for TPM’s, by TPM’s. Doron, Josh Teter, Michael Götz, and myself are co-hosting to provide a panel-style podcast experience with frequent guests in the industry.

• The latest episode was with David Rifkind to dive into The State of TPMs.

• In June, we had a season launch episode where we shared our path’s to becoming TPM’s and thoughts on AI as TPM’s.

TPM Ridge Podcast: A monthly podcast for Technical Program Managers, hosted by Doron Katz, James Dayhuff, Josh Teter, and Michael Götz.

Covering contemporary topics, sharing their insights on all things TPM. The panel talks about hot topics in our industry, as well as a dive deep into best practices to provide tips and commentary.

open.spotify.com/show/6n4fTGQ9WLK52H9xsU6DFW?si=da9900b5e8e24ee0

Learn

👨‍🏫 The Psychology of a Great TPM: 4 Core Principles

No child grows up dreaming of becoming a Technical Program Manager.

Honestly, it’s a role that doesn’t have a strong magnetic pull against the other mainstream career paths like engineering or product management.

It seems like to me that there are a common set of base beliefs or attributes of most TPM’s. There is still diversity within the groupings of TPM’s, but many of us likely align in very fundamental ways.

I believe there are a set of core first principles when it comes to the Psychology of a Technical Program Manager that are common across most all of us.

It is less of a job description and more of a psychological profile.

So, I ask you, what makes a great Technical Program Manager tick? What behaviors help these TPM’s “win” in the workplace?

Consider these questions when looking

• Are you willing to run towards chaos?

• Are you able to flex and bend in ambiguity?

• Do you find joy in working behind the scenes helping others?

• Do you get a thrill from structuring the unstructured?

Hard skills are learnable by most anyone. But behaviors? Those are hard to learn. Those are the differentiators between the mediocre and the great.

Let’s consider 4 Psychological Principles of great TPM’s that enable them to behave in a way that helps them win.

Psychological Principle 1: Context Craving

Any great technical program manager craves the full context of a project or program. We examine how a project fits in from multiple angles:

• Seeing the through-line of a project as a strategic business driver

• Reading the political shifts around the project

• Understanding the technical systems and components that make it possible

• Diving into the data that support or disprove hypothesis around the business and its operations

We want that bird’s eye view.

Not for the ego-trip of becoming an all-knowing TPM, but because our brains thrive on mental completeness. It’s that same feeling when a puzzle is complete and you can see how all the pieces fit together. It just feels good.

Context is everything to us as TPMs because context brings clarity. Clarity drives outcomes. Outcomes are what make the difference.

To become a great TPM, Crave Context: gather it, build it, spread it.

Psychological Principle 2: Embracing Ambiguity

Technical Program Managers are not intimidated by ambiguity. We embrace it.

Every single project has varying amounts of ambiguity. It is inevitable. We know it isn’t just part of the job, but there’s a part of our brains that light up when we face ambiguity.

It’s like being dropped in the middle of the woods and having to find our way out. There is a sense of adventure, danger, challenge, and survival. Our brains react in a way that allow us to embrace ambiguity with focused energy and optimism.

For some strange reason, we run towards the chaos and ambiguity in search of a thrill to drive clarity and context.

To become a great TPM, Embrace Ambiguity: run towards it, dig into it, enjoy it.

Psychological Principle 3: Emotionally Calibrated

If you’ve made it this far in the article, you may be looking at the first two principles and wondering how to reconcile them.

• On one hand, TPM’s crave context!

• On the other hand, TPM’s embrace ambiguity!

Simultaneously being able to Crave Context and also Embrace Ambiguity is one of our psychological superpowers.

This co-existence of the first two principles leads to the third: emotionally calibrated.

TPMs often absorb emotional friction from and between other functions. It is rarely appreciated how often we “make it work” between teams and organizations that may have far from perfect relationships and interactions.

This means that no matter the highs or the lows of any project, we as TPM’s are that steady anchor. We manage risks, but we also celebrate wins. We don’t just make plans, but we investigate morale across contributors.

This makes TPMs effective stabilizers throughout the lifecycle of any project.

To become a great TPM, be emotionally calibrated: celebrate wins, mourn the losses, but stay as steady as an anchor.

Psychological Principle 4: Systems for the People

We may think and communicate in Gantt charts, but we thrive on human nuance and relationship.

There’s something about people that makes us love the job of being a TPM (and this very same fact is sometimes what makes us hate our job as TPMs!).

But we’re wired to think about people, at scale. TPMs love frameworks, retros, and Jira dashboards…but we love them because they help humans work better together.

We’re system builders and soft skill nerds.

Ultimately, our inner drive is to make progress easier, for all the people, at scale.

To become a great TPM, prioritize people: build relationships, design human-friendly processes, run programs with kindness.

Wrap Up: Why This Matters

The best TPMs aren’t just doing a job. They’re satisfying a deep internal urge to fix, connect, align, and uplift.

They are exemplifying behaviors that help everyone around them win.

These are the psychological patterns that perhaps represent the underlying wiring that gives us our superpowers.

So I ask you again, what makes a great TPM tick?

I believe it is a quiet but unrelenting need to bring order to complexity and momentum to teams.

📧 What makes you tick? Or what other behaviors do you believe make a great TPM? This definitely isn’t the end-all-be-all for high performing behaviors! Feel free to reply to this email directly with your own thoughts!

Note: This post was inspired by the book, The Psychology of Money. This is a book that has always helped me think differently about money: less on the math and more on my behaviors with money.

That pattern of thought got me thinking about the psychological principles and behaviors of a great TPM.

The Psychology of Money

Doing well with money isn't necessarily about what you know. It's about how you behave. And behavior is hard to teach, even to really smart people.

www.goodreads.com/book/show/41881472-the-psychology-of-money

People

🤝 Doron Katz, Host of the TPM Ridge Podcast

Doron is a Staff Technical Program Manager at Walmart. I’ve had the privilege to meet and chat with Doron on a few occasions! He has a passion for the TPM craft and recently has been publishing tons of great content and resources for TPMs!

(Oh and he’s also the host of the TPM Ridge Podcast!)

Definitely connect and/or follow him to expand your network of amazing TPM’s.

Here’s one of his latest articles on Production Readiness.

Production Readiness as a Product: How to Scale Reliability Frameworks Across Teams in Six Steps

I've been focusing in my role at Walmart on Production Readiness over the past few months, which has got me thinking a bit about the seasonality of this process. Historically, teams have employed operational reviews (ORRs) or Production Readiness Reviews as part of a one-time gate, a static checklis

www.linkedin.com/pulse/production-readiness-product-how-scale-reliability-frameworks-katz-srwwc/?trackingId=8TvT%2Fzub%2FY1QMr%2F%2FAp4EHw%3D%3D

Sharing is Caring

🎁 Are you enjoying this newsletter?

Share this free newsletter with anyone you’d like, or simply just post it on LinkedIn if you’ve found value in it.

Learn

👨‍🏫 AI’s Analysis of my Blindspots

Despite years of trying to be a “good” leader, I realized there’s only so much self-reflection I could do inside my own head. So, on a whim, inspired by someone I met on LinkedIn, and maybe a little anxiety I asked my AI assistant to tell me the truth:

What are my biggest leadership blind spots?

The results? A mix of brutal honesty, surprising accuracy, and, thankfully, real actionable steps.

We all have blindspots.

To ignore the potential for blindspots is to immediately limit your growth. Full stop.

We all have blindspot. It’s part of being human.

Our big ol’ brains naturally interpret the world through the lens of our own experiences, no matter how much we try to combat bias or grow our empathy.

This is one of your greatest obstacles to professional growth.

As aspiring technical program managers and leaders, this becomes a real challenge: to reach the next level, we have to grow beyond the habits and paradigms that once served us.

AI Prompt for Blindspot Monitoring

The prompt itself is not complicated. It isn’t fancy. But that’s the point.

I’m sharing this to all of you as a potential direction to explore with AI.

Here’s the prompt:

Now that you know everything I’ve typed, tell me my top 5 blind spots. 

Prerequisites for this prompt

For this to work, the AI needs long(ish)-term context about you.

In my case, I’ve been using ChatGPT almost daily across every corner of my life for months.

I’ve used AI for everything from:

Learning:

• Researching random topics

• Translating talks across languages

• Finding strategies to beat my son’s video games

Life Admin:

• Protesting my property tax assessment (results pending!)

• Running my LLC and side projects

• Creating family dinner recipes

Work Productivity:

• Jira and Google Sheets troubleshooting

• Daily task management (minus any proprietary info)

• Researching domains to ramp up quickly on projects

Needless to say, it has replaced any other search engine that may have been my go-to just a year ago.

My Blindspots, per AI

The feedback felt uncomfortably accurate.

(But again, what should I expect after oversharing my life with AI?)

Before I share the results, a reminder: Growth is not a race.

There will always be people ahead of you and people behind you. This applies to every Technical Program Manager you meet. This is a journey, not a competition.

So with that said, hang with me as I open up with some vulnerability for where I’m at with my growth as a Technical Program Manager

Now, onto what the AI surfaced about my leadership pivot.

As AI performed this analysis, it pointed out the top 5 blindspots that led to the high level summary of being a Hero Operator rather than a Strategic Multiplier.

1. Over-Optimization at the Expense of Delegation (ie, despite having a great solution for something, I can accidentally make myself a bottleneck)

2. Passion-Led Diversification vs. Strategic Focus (lots of ideas, not executing on enough. Mostly related to my LLC.)

3. Excellence Masking Simplicity. (ie, wanting a perfect solution rather than an 80% “good enough” solution).

4. Guarding Energy for Family Might Delay Personal Scaling. (this one hit hard! But it had a good point: I equate growth with more time while ignoring that growth can be experienced with the right growth “levers”)

5. Leading Through Competence vs. Influence (I may lean to hard on my skills rather than organizational influence to rally around an idea and vision)

Fixing my Blindspots, per AI

Thankfully, AI didn’t just stop at critique. It gave me a roadmap to grow past these blindspots.

The first recommendation were a series of mental models to shift:

Moving into a Staff TPM role has already started facilitating these shifts, but making them second nature is still a work in progress.

But there’s still so much growth to take place if I want these mental models to become a habitual way of working rather than feeling like I’m going outside my normal knee-jerk reactions.

After the mental model suggestions, it recommended tactics to begin practicing these shifts:

A note of caution: I do not fully agree with every tactic.

Sometimes in technical program management, you have to roll up your sleeves. Sometimes you are simply the fastest way to unblock progress.

But the real danger is letting that mode of working become your default.

When “just getting it done” becomes a habit, you rob others (and yourself) of bigger growth opportunities.

Blindspot Challenge

Gaining this insight was valuable. No, not because I believe AI is infallible in its advice-giving, but because it forced me to pause and ask:

Is the way I’m working today aligned with the future leader I want to become?

So here’s my challenge to fellow Technical Program Managers:

• Use one AI tool daily across life and work.

• Let it observe your patterns over time.

• Then, when ready, ask it: “What are my blindspots?”

You might be surprised (or even a little humbled) by what you learn. And that’s exactly the point.

Your Thoughts

🤔 Have you used AI for professional growth?

I’m always happy to chat with folks who have found AI useful in professional growth. Feel free to respond to this email directly! Or DM me on LinkedIn.

Learn

👨‍🏫 Change is the only Constant.

You’ve probably heard this phrase before. The original attribution goes to the Greek philosopher Heraclitus, who saw the universe as ever-changing, always in flux.

If we accept this truth, then seeking an unchanging environment is futile.

Yet, so many of us do exactly that! We try to escape the chaos that change brings.

The Wrong and Right Questions

In your career, the question should never be:
"How can I avoid change and find a perfectly stable job?"

Instead, the only question that matters is:
"Since change will always find me, how will I react?"

Lean into Change

Leaning into change is a leadership mindset.

If you’re reading this, chances are you’re a technical program manager, which means you don’t just experience change, you drive it.

And being a leader who can embrace and execute impactful change is one of the most valuable skills you can develop.

Change is where opportunity exists.
Change is where work gets interesting.
Change is where you grow.

I know this might sound cliché. But embracing change isn’t just a mindset: it’s a strategy that has shaped my career. Here’s what I mean.

Let me give you a few examples from my life.

Example 1: Elon Musk takeover of Twitter

I was at Twitter during the Elon Musk acquisition.

No matter your opinion on that event, it was an extreme test of leadership under change (made even more intense by its high public visibility).

I was fascinated by what was unfolding internally. Not because it was easy, but because I had a front-row seat to leadership under pressure.

• I saw how leaders from every function responded to uncertainty.

• I had to keep contributors engaged in a high-stakes data privacy program that needed to continue—no matter what.

• I built new levels of resilience and empathy as we navigated the turmoil together.

Many people chose to leave, and I don’t judge their choices. But I made a calculated decision to stay through the transition. And because of that, I’m convinced that I walked away better than I was before the whole things went down: a better technical program manager, a better professional, and a better human.

Example 2: IBM Acquisition of HashiCorp

For the past year, IBM has been in hot pursuit of acquiring HashiCorp. The deal finally closed a few weeks ago.

Has there been change? Oh, absolutely.

• Major leadership changes have left many wondering about executive sponsorship for critical programs.

• Process overhauls have forced us to rethink how we work.

• Cultural shifts have brought difficult conversations to the surface.

The company I joined two years ago is not the same today. But that’s okay.

Because I’m not just a participant in my career. I’m a curious observer as well. I like to think of myself having a dual role of both actor and spectator of the great play of my life.

I know even more change is coming over the next 18–24 months. And while some of it will be difficult, I also know it will ultimately do more good for me than harm…but only if I embrace it.

Don’t quite because change is hard

If you’re going through a stressful change right now, I get it. It’s tempting to jump ship for something that looks more stable.

But don’t make that decision hastily.

No matter where you go, change will follow you.

Don’t quit just because change is hard.
Don’t quit because you want an easy job. (easy is boring!)

That said, there are valid reasons to leave after major change, such as:

• The change demands too much of you—to the point where it harms your health, family, or personal priorities.

• The change removes your long-term career incentives—meaning the company and your goals are no longer aligned.

• The change alters your market value—and you’re no longer being compensated fairly for your skills.

But do you notice a theme in these? Each of these reasons is about alignment, not avoidance.

Quitting just to escape change? Not worth it.

Recap

If you forget everything else, remember this:

• Change is the only constant.

• True leaders embrace and lead through change.

• Make change work for you.

• Don’t quit just because change is hard.

To all my fellow TPMs out there: lean in. Be the leader through the change. The best opportunities come from the hardest changes.

Learn

👨‍🏫 The Proxy Problem

A high-impact technical program manager delivers outcomes, not programs.

Delivering on outcomes is trickier than it seems, though, because every company can accidentally incentivize their employees to focus on the wrong measures of success.

This is commonly called the proxy problem.

The proxy problem happens when you mistake an intermediate milestone for the actual outcome. It’s easy to do. Trust me, I’ve fallen victim to it several times in an effort to secure a win for my resume. This is especially true in engineering and product teams, where we’re all semi-incentivized to claim wins that look good in a sprint review but don’t translate into real impact.

Proxies aren’t inherently bad.

They help track progress, gauge buy-in, and measure engagement. But they’re a means to an end, not the end itself.

Let’s take a look at 3 examples from various points in my 10 year career as a engineer and program manager.

Proxy Problem 1: The Perfect Plan

I had just polished the perfect implementation plan. Or so I thought.

Every workstream was mapped out. Dependencies were accounted for. Teams knew exactly when and what they needed to deliver. Risks? Documented.

By all accounts, this was a rock-solid plan on paper.

It was early in my role as a technical lead for an API engineering team, and I was confident. Maybe too confident.

Then reality hit.

My manager praised my work. The plan looked airtight. But when it came time to execute, things didn’t unfold as expected.

Despite how well-structured the plan was, it didn’t translate into the outcomes I had envisioned. Everything was supposed to fit together like a 1,000-piece puzzle, and it did! On paper. But in practice? It didn’t matter.

What went wrong?

I suspect the proxy problem had something to do with it.

• Proxy: A well-structured plan can feel like success. But a plan is just a tool. It doesn’t mean execution will go smoothly. As a TPM, I love a good looking plan! It makes me feel warm and fuzzy inside. Being aware of this personal love for plans is something I consistently have to beware of.

• Outcome: The real goal was to reduce the time spent on quarterly planning while boosting engineering velocity. A true measure of success would have been seeing a measurable drop in planning hours and a corresponding increase in delivery speed.

Story 2: The False Comfort of Ticket Closure

Our cross-functional team had closed 75% of the Jira tickets for a project. That’s a solid number! We felt good. We had tangible progress to point to.

But that number didn’t tell the full story.

The remaining 25%? Those were the hardest, most complex parts of the project. The ones that actually determined success. We hadn’t secured a total victory yet and our team habits that helped us reach 75% were insufficient to help us accomplish the final 25%.

The project eventually stalled out and was deprioritized.

As a Technical Program Manager, this was a hard pill to swallow. It definitely brought my ego down to earth and gave me a good reason to reexamine my general approach to the TPM craft.

What happened?

The proxy problem strikes again!

• Proxy: A high percentage of closed tickets feels like progress. But it’s just a number. It doesn’t represent outcomes.

• Outcome: The real goal was achieving a new level of compliance certification. It was a binary result. The only metric that mattered was whether we passed, everything else was noise. But we never got to that point because of deprioritization.

Story 3: The Illusion of a Launched Product

Then there was the time we raced to ship API endpoints that had been deemed urgent by multiple teams.

We snapped to it, built what they asked for, and rolled it out to production. We all felt a rush of pride sending out the launch announcement.

Then…crickets.

But in the weeks that followed, nobody adopted those APIs. The “critical blockers” we had solved? Apparently, they weren’t blockers at all. The teams were just really noisy about the problem but eventually found a local solution.

Eventually, we shut the endpoints down. A complete waste.

Again…what happened?

You know. The proxy problem.

• Proxy: Shipping to production. It felt good. It’s real work, but it doesn’t guarantee adoption. In this case, we were so focused on shipping quickly, that we failed to ensure the features actually solved problems.

• Outcome: Success would have meant solving an actual pain point for internal teams. Adoption, usage, and problem resolution (not just deployment) should have been the true measures. You live and learn. Luckily the cost of this failure was relatively low.

Recap

Each of these scenarios had one thing in common: we weren’t measuring success. We were measuring a proxy for success.

Don’t get me wrong…

• Creating plans is a good thing.

• Tracking progress with tickets is a good thing.

• Shipping to production is a good thing.

But when those good things become the thing, then your focus on outcomes is lost. The proxy problem has struck again.

It’s tempting to celebrate the proxies (plans, ticket closures, deployments) because they’re visible, quantifiable, and easy to track. But real success comes from solving the problem you set out to solve.

So, take time to celebrate those small wins, but don’t declare total victory quite yet. Stay focused on the outcomes.

Before you pat yourself on the back, ask yourself: Am I making progress, or just tracking something that looks like progress?

People

🤝 Aadil Maan, Staff TPM @ Airbnb

I want to take a moment here to give a shout-out to a fellow TPM and writer: Aadil Maan. Aadil has been at the writing game a bit longer than myself. His substack was one of the original inspirations for me to jump into the world of writing on the topic of Technical Program Management.

Keep up the good writing Aadil, you’re crushing it.

Aadil Maan | Substack

I help demystify the role of technical program managers and what it takes to be a great TPM and organizational Leader.

substack.com/@aadilmaan

Resources

📚 The Art of Doing Technical Program Management

Speaking of Aadil…he’s got a substack newsletter dedicated to Technical Program Managers! He’s garnered a whopping 5k subscribers and keeps churning out some high quality content.

I particularly enjoyed one of his latest posts to his subscribers: 30-60-90 For TPMs. Check it out!

The Art of Doing Technical Program Management | Aadil Maan | Substack

Delivering proven real-world strategies, practical advise and tips, and actionable frameworks to help you level up as a Technical Program Manager. Click to read The Art of Doing Technical Program Management, by Aadil Maan, a Substack publication with thousands of subscribers.

artoftpm.substack.com/?utm_source=substack&utm_medium=web&utm_campaign=substack_profile

A word from this week’s sponsor…

There’s a reason 400,000 professionals read this daily.

Join The AI Report, trusted by 400,000+ professionals at Google, Microsoft, and OpenAI. Get daily insights, tools, and strategies to master practical AI skills that drive results.

Sign up now for free and work smarter, not harder.

Learn

👨‍🏫 Stop Using a Hammer for Every Problem

As a technical program manager, you get a lot of problems thrown at you.

I mean…a lot. And the trickiest thing in my experience is that not all problems are created equal.

About 5 years ago I entered the world of woodworking. I built my first (and only) utility stool. I quickly learned that building even a simple stool requires a variety of tools – a saw for cutting, a drill for holes, sandpaper for finishing. You wouldn't use a hammer for every step, right?

The same principle applies to technical program management.

I know I've definitely tried to force a square peg into a round hole before, and it wasn’t pretty. I remember once trying to rollout an Agile adoption to a handful of teams. It was honestly a disaster, but a massively beneficial career experience for me. Agile practices weren’t going to solve their problems. We pivoted quickly to a different approach and had better success.

It made me realize that just like a woodworker wouldn't use a hammer for every task, we shouldn't use the same project management style for every problem.

Enter the Cynefin Framework

That's where the Cynefin Framework comes in.

It's not some fancy academic theory; it's a practical way to categorize problems so you can choose the right approach. Think of it as a map to navigate the different types of challenges we face. Here’s a visual from HBR’s article “A Leader’s Guide To Making Decisions”:

HBR: A Leaders Guide to Making Decisions

You see above that there are five domains that fall somewhere on a spectrum of unordered to ordered.

Let’s start in the middle of the visual above, Disorder.

This is when you're just plain confused!

You don't even know which of the other domains you're in. The first step is to break things down and figure out what kind of problem you're actually dealing with. This is it isn’t immediately apparent which domain is most applicable and your first task is to figure that out.

As you move out of disorder, ambiguity begins to retreat and you start to see the problem(s) for what it is in one of the categories below.

Simple (Sense - Categorize - Respond)

These are your bread-and-butter tasks. The cause and effect are obvious. Think bug fixes, routine deployments, or adding a standard feature. You know what needs to be done, and there's usually a best practice to follow. It's like following a recipe.

The go-to moves are “Sense - Categorize - Respond”. You see the problem, you know the solution, you apply it. Boom, done. Example: A routine software patch deployment. While TPMs often deal with more complex issues, elements of 'Simple' problems are frequently embedded within larger programs and require appropriate handling. 

Applying this to our world as Technical Program Managers across 4 example domains of our job:

• Risk Management: Risks are usually well-known and predictable. Focus on prevention through checklists, standardized procedures, and quality control. Contingency plans should be simple and straightforward. Think "if X happens, do Y."

• Stakeholder Management: Communication should be clear, concise, and focused on progress updates. Regular, brief status reports will suffice. Stakeholders are usually interested in knowing that things are on track and within budget.

• Communication Strategy: Simple, direct communication channels are best. Email, short status meetings, and project management software updates are sufficient.

• Team Structure: Hierarchical, with clear roles and responsibilities.

Complicated (Sense - Analyze - Respond)

These are trickier. There are multiple moving parts, and you need some expertise to figure things out. Like integrating two existing systems or building a new feature with detailed specs. You can figure out the cause and effect, but it takes analysis.

Your actions are to “Sense - Analyze - Respond”. You see the problem, you bring in the experts to analyze it, then you respond with a solution. There might be multiple good solutions, but you can find them with enough analysis. Example: Integrating a new payment gateway into an existing e-commerce platform.

Applying this to our world as Technical Program Managers across 4 example domains of our job:

• Risk Management: Risks are more complex and require analysis. Use techniques like risk assessments, SWOT analysis, and fault tree analysis. Contingency plans should be more detailed and consider multiple potential scenarios.

• Stakeholder Management: Engage stakeholders throughout the process, especially during analysis and design phases. They may have valuable expertise to contribute. Regular meetings and more detailed reports are necessary.

• Communication Strategy: More in-depth communication is required, focusing on explaining technical details and trade-offs. Use presentations, white papers, and technical documentation as needed.

• Team Structure: Cross-functional teams with specialized expertise are crucial.

Complex (Probe - Sense - Respond)

Now we're in the weeds. Cause and effect are only clear after the fact. Think developing a brand-new product with an uncertain market or dealing with major organizational change. You can't plan everything upfront; you have to experiment and see what emerges.

"Probe - Sense - Respond" is key. You try something (probe), you see what happens (sense), then you adjust your approach (respond). It's all about learning and adapting. Example: Developing a new AI-powered recommendation engine with uncertain user adoption.

Applying this to our world as Technical Program Managers across 4 example domains of our job:

• Risk Management: Risks are emergent and difficult to predict. Focus on building resilience and adaptability into the project. Use techniques like scenario planning and simulations. Embrace iterative development and frequent feedback loops to identify and mitigate risks early.

• Stakeholder Management: Keep stakeholders informed of the overall direction and progress, but don't try to over-promise specific outcomes. Manage expectations by emphasizing the experimental nature of the project. Frequent communication and transparency are essential.

• Communication Strategy: Open and frequent communication is paramount. Use collaborative tools, workshops, and regular demos to keep stakeholders engaged and informed. Focus on sharing learnings and adapting the approach based on feedback.

• Team Structure: Self-organizing, cross-functional teams with a high degree of autonomy are ideal.

Chaotic (Act - Sense - Respond) 

This is full-on crisis mode. No cause and effect is apparent, and you need to act fast just to regain control. Think major production outages or unexpected security breaches. The priority is to stabilize the situation first and ask questions later.

"Act - Sense - Respond" is the only way to go. You do something to stop the bleeding, then you assess the situation and figure out your next move. Command-and-control style because the stakes are usually very high. Example: Responding to a major data breach.

Applying this to our world as Technical Program Managers across 4 example domains of our job:

• Risk Management: Risk management is about immediate response and damage control. Focus on stabilizing the situation and preventing further escalation. Post-mortem analysis is critical to learn from the experience and prevent future crises.

• Stakeholder Management: Communicate frequently and transparently, even when information is limited. Focus on reassuring stakeholders that the situation is being handled.

• Communication Strategy: Clear, concise, and immediate communication is crucial. Use all available channels to reach stakeholders quickly.

• Team Structure: A command-and-control structure with clear lines of authority is necessary.

Wrapping it up

It’s not about rigidly applying a template, but rather using the framework as a guide to make informed decisions about how to manage your projects effectively.

By understanding where your program (and sub-projects) falls within the Cynefin Framework, you can tailor your approach to maximize your chances of success.

This will help you avoid a lot of the headaches and frustration we've all experienced when trying to force a one-size-fits-all solution onto a complex problem.

Thanks for reading today, happy TPM-ing!

Resources

📚 Technical Program Managmenet: A Practitioner’s Guide

A couple years ago I launched a course on Educative.io, which is a text-based course platform. I can’t believe it has been that long!

It has a heavy emphasis on program lifecycle, with supplemental content on system design, leadership, and career management. And the great thing is that I can give my readers a special end-of-year discount to the platform. Enjoy!

Learn

👨‍🏫 3 Pillars of Product Operations (and why they matter to TPMs)

Let me start off by stating the obvious: If you’re subscribed to this newsletter, you probably want to become a high-impact Technical Program Manager.

You and I are both on that journey together.

There is plenty of advice out there about how to ramp up your technical versatility by learning System Design and other technical concepts. This is, undoubtedly, a very important part of being a technical program manager.

However, a highly technical TPM won’t get very far if they don’t understand how to “play ball” with product management.

It’s tough, I know. There’s so much to learn. Context switching between the technical details, the program execution, and product strategy can become exhausting.

However, your ability to build a bridge between those contexts is a huge reason why Technical Program Managers like yourself are so highly valued when the job is done right.

In this post, you and I will have a minute to dive into the world of product operations.

Why do Product Operations matter to Technical Program Managers?

Let me start by asking this: Why do we do what we do?

This might sound like an odd question, but it’s an important one!

The reason any software company builds anything is to have an impact. An outcome. To live up to a sense of purpose. In the process of shipping product, we must protect this core value of delivering outcomes at all costs.

As a TPM, you must do all you can to guarantee meaningful outcomes of work.

Sure, system design will help you talk with engineers.

But what about your ability to talk with product managers?

A beautifully designed system is irrelevant if it doesn’t solve the right customer problem. Product Operations ensures teams are building the right things in the right way. And you, the TPM, is critical to that process. You operate within it.

You must understand the world and language of Product Management and Operations.

What’s at risk if you don’t understand Product Operations?

• Weak narratives that don’t build buy-in on important initiatives

• Wasted effort on initiatives that don’t have any business or customer impact

• Failed delivery of outcomes on important initiatives

• Frustrated cross-functional groups miscommunicating important details

Product Operations: a 10,000ft view

Without delaying any further, let’s get into the details of Product Operations.

The framework that I am about to walk through is not my own creation. It is the creation of a much more expert product professional: Melissa Perri. She shares her perpsective in the book Product Operations: how companies build better products at scale. (This is not a sponsored post, it is just a good book).

There are 3 pillars which she details in her book that provide a good framework to understand the world of Product Operations and subsequently, the world in which product managers operate.

1. Business Data and Insights

2. Customer and Market Insights

3. Process and Practices

Let’s dive in.

Pillar 1: Business Data and Insights

This first pillar is like a compass. It is where we can confirm we’re reaching the intended outcomes that we set out to deliver.

• Do we understand what we have already shipped?

• Do we understand customer usage patterns?

• Do we understand the context of this data?

• Is our strategic intent being realized?

• What is the expected ROI of a given initiative?

How can you, as a TPM, integrate your efforts with this pillar?

Think of a time where you’ve too few engineers relative to the aspirations of leadership to ship product. It happens all the time.

You’re experience a priority conflict.

When you program has a conflict where the same engineering capacity is required by multiple initiatives, you role is to stay objective. Instead of getting into a political battle of who-knows-who, go back to the data.

Here are a few questions you can ask from a product perspective to help facilitate a healthy data-driven decision:

• Which initiative will impact the most important business metric?

• Which initiative has the greatest potential ROI?

• Which initiative has the greatest cost of delay?

Prioritization is just one example of how you, as the expert TPM in the room, can partner with product within this first pillar to make data-driven decisions.

Pillar 2: Customer and Market Insights

Anyone else have kids that love the movie Moana? In the story, the main character becomes a Wayfinder. She learns to use the stars to navigate the ocean to get to where she wants to go.

This is different from operational and current-feature data in the first pillar. This data is a first-class citizen in setting strategic intent for the company.

How can you, as a TPM, integrate your efforts with this pillar?

Building buy-in can be really tough on complex, large initiatives. But you know what helps build buy-in really effectively? A story.

Story-telling, ie having a strong narrative, is the secret sauce to any great product manager. You can also build this skill with them, but the role of the product manager is primarily responsible for identifying the data that tells the story.

Whatever you’re working on today, do a little experiment by looking back on the data-driven story telling that is backing your initiative. If this is a weak point, I bet you’re having a hard time getting people to care.

Work with product teams to surface customer pain points from engineering incidents or feature feedback loops, and weave these insights into the broader story of why an initiative matters.

As you build a stronger narrative you’ll see the process of building buy-in become smoother.

Pillar 3: Process and Practices

You are absolutely critical to this pillar, especially for the largest and gnarliest initiatives.

This pillar is the execution and delivery of everything we learn from pillars 1 and 2. Without this pillar, we end up with a company holding onto a bunch of good ideas but no way to move forward with them!

How can you, as a TPM, integrate your efforts with this pillar?

I sincerely hope you get excited about this pillar. This is your chance to enter the scene in a couple different ways:

1. Work in the system: Be a high-impact operator within the defined structure of this pillar.

2. Work on the system: Be a thought-leader in helping craft these cross-functional practices for scaled delivery of highly valuable initiative.

In either scenario, your chance for impact here is massive. You’ve got that program management experience. You’re an expert in cross-functional execution. Lean into that! For example:

• Propose a streamlined method to report on major initiatives

• Build a cross-cutting jira dashboard that gives multi-org visibility

• Establish and facilitate a cadence of planning with product

• Up-level documentation standards for the product process

• Facilitate cross-org initiatives smoothly so product can focus on pillars 1 and 2

Wrap Up

This 3 pillar framework can help you understand the world of product management so that you can be a high-impact partner.

You need to be a strategic partner, not just an execution enabler. That means being a strategic partner not just for engineering but also product.

Just as you design systems for scalability and reliability, you should think about product operations as the system that ensures the right product is being built to begin with. Your ability to understand engineering trade-offs and connect them to customer and business data makes you a key player in aligning all three pillars.

Take a moment today to reflect: Which of these three pillars are you excelling at? Where can you grow?

By leaning into Product Operations, you’ll not only amplify your impact but also unlock better outcomes for your teams and customers.

(📧 I’m interested to hear your thoughts on this post, feel free to respond directly with any thoughts or additions to these concepts!)

People

🤝 Dr Bart Jaworski, Product Manager

I’ll be honest, I don’t know him personally.

But if you like Product Management and a good meme, you’ll enjoy adding Dr Bart Jaworski to your Linkedin Feed! I’ve enjoyed his content over the past couple years as peel back the many layers of Product Management.

Dr Bart Jaworski

I ain't going to sugarcoat it: Being a Product Manager can really drain you. Here are 6 biggest offenders and how to ease their pain: 1) Too many… | 43 comments on LinkedIn

www.linkedin.com/posts/bart-jaworski_productmanagement-productmanager-mentalhealth-activity-7269710333571702784-018c?utm_source=share&utm_medium=member_desktop

Resources

📚 Product Operations Book

In this post, I referenced Melissa Perri’s book. The 3 pillar framework is not mine, it is hers. I just happen to enjoy the paradigm pitched in the book! It probably could’ve been a shorter book, but the principles are pretty solid.

(this is not sponsored)

Product Operations: How successful companies build bett…

Product Operations is the discipline of helping your Pr…

www.goodreads.com/book/show/199467729-product-operations

Learn

👨‍🏫 Problems First, Solutions Second

Problems are more important than solutions. Don’t believe me? Let’s dive in.

• Have you ever seen a program veering off course because the problem wasn’t fully understood from the start? 

• What about when a feature is launched, only to realize it barely resonates with users?

• How about those times when it feels nearly impossible to get traction with an awesome solution because it didn’t have a compelling story behind it?

Misaligned problem statements can cascade into costly missteps, wasted time, and frustrated teams.

As a Technical Program Manager, one of your core roles is to drive clarity and alignment. This all starts with the problem.

Without aligned specificity of the problem to be solved, solution design and execution will likely fail.

A Bloated Problem Lead To Bottlenecks

About a year ago, I was dropped into a struggling program. Lucky me!

The expectation was for me to drive clarity and alignment between engineering and product so that we didn’t miss the customer-committed deadline which was fast approaching.

Technical Program Management Perspective: Lack of Clarity and Alignment

Jumping into the middle of all this, I didn’t initially have the context for both engineering and product. This was a process of discovery to get clarity so we could then drive alignment.

I knew is that we needed to find a way to negotiate either timeline or scope. But I wasn’t sure how to figure this out at first. The more time I spent with each group (both separately and together), the core alignment issue became clear:

The problem had become excessively bloated, leading to requirements also being bloated.

Engineering’s Perspective: Defending Time and Resources

The engineering teams were overloaded with a million other things. Upon hearing the request from product management to enhance the feature set for a portion of our core platform, they immediately became defensive of their time (appropriately so! Any good Engineering Manager defends their team ferociously!).

They could see what was being asked for and immediately knew it would consume more time than they could give.

Yes, it would a good long-term uplift to one of our core systems, but within the communicated timeline? Laughable.

Product’s Perspective: Building Customer Value

The product team saw an opportunity. Through conversations with customers, they realized that there was direct revenue potential if they could deliver an enhanced feature set on this portion of the core platform.

Product set the requirements to truly delight the customer, as any good product management team would do. These definitely qualified as “wow-factor” requirements. Then they began negotiations with engineering.

Bringing All Perspectives Together.

Okay like I said, I was dropped into this middle of all these negotiations. Emotions were high. The meetings were tense. But both groups wanted a solution.

With product management, I began to trace the original problem back to its origin. This “tracing back to the problem” exercise took the form of these questions:

• Why are we doing this?

• What pain point are we solving?

• Who asked for it?

• What does this do for the business?

• What is at risk if we don’t do it?

After diving into this with the product team and doing additional research with them, we discovered 1 very important fact that was lost in the details.

The original request was from 1 customer for a very narrow set of requirements by a very specific date.

This was a game changer.

We compared the list of requirements that product had written with the actual problems the customer wanted solved. Wow. The list of features being requested from engineering shrank quickly.

So what happened?

You may think that product did a terrible job here. Or maybe you think engineering was too inflexible.

The truth is that thinking that was isn’t helpful to anyone.

Here’s what is helpful:

• Product excelled at future-proofing and considering value beyond one customer, though initial alignment with engineering was missing.

• Engineering communicated capacity constraints effectively, preventing overpromising and ensuring realistic timelines once clarity was established

The core issue is that the the problem definition for the first iteration wasn’t clear nor aligned.

As a TPM, I helped the group resolve this. But I had a very useful framework in my back pocket that helped me coach these teams towards a better collaborative model.

The Double Diamond Framework

The Double Diamond framework isn’t just another process model. For me, it was a roadmap to steer these teams toward clear problem definitions and aligned solutions, minimizing wasted efforts and maximizing impact.

Source: Product Board

Let’s be honest, there are a million problems that could be solved.

How did I use this framework in my scenario described above?

I used this framework by bringing us back to the basics of problem discovery and definition.

With Product, we collected all the problems they were hoping to address with their current requirement list (problem divergence in the framework). Then we started to narrow down the list relative to validated customer needs (problem convergence in the framework).

There is no one-size fits all on how to use this framework. After all, this is a product framework. But it serves as an excellent model to facilitate effective collaboration.

Here are 3 ways you and I as TPM’s can use this framework:

• Enhancing Communication in Discover - We can lead early discovery sessions in partnership with Product Management, aligning stakeholders on the core problem through workshops and structured discussions.

• Defining Clear Metrics in Define - We can ensure success metrics mirror the problem’s scope, using dashboards to track progress and keep teams focused.

• Ensure Focused Execution in Develop - We can work across engineering teams to drive clarity of solution design and prevent scope creep, which helps us stay laser focused on the expected outcomes.

• Seamless Handoffs in Deliver - We can coordinate handoff processes with documentation, training, and support, ensuring long-term sustainability post-launch.

By adding this framework to your TPM tool-belt, you become a much stronger leader and collaborator across engineering and product organizations. Large-scale initiatives need quality leadership, and when we as TPM’s leverage the Double Diamond framework, we bring clarity and alignment from the start.

Happy TPM-ing!

A word from this week’s sponsor…

Add file uploads instantly with Pinata’s developer-friendly File API

As a developer, your time is valuable. That’s why Pinata’s File API is built to simplify file management, letting you add uploads and retrieval quickly and effortlessly. Forget the headache of complex setups—our API integrates in minutes, so you can spend more time coding and less time on configurations. With secure, scalable storage and easy-to-use endpoints, Pinata takes the stress out of file handling, giving you a streamlined experience to focus on what really matters: building your app.

Start building!

Events

🎉 TPM Events

Do you want to meet other Technical Program Managers in-person?

Don’t forget about the local chapters called TPM Trails. These are city-specific TPM meet ups! I unfortunately don’t have any near me at this time, but I certainly hope others can take advantage of it.

This page is regularly updated with upcoming events, bookmark it!

TPM Summit and TPM Trails events

events.tpmevents.org/events

Learn

👨‍🏫 Book Review: Technical Program Manager's Handbook

The TPM Handbook (2nd edition), written by Joshua Teter, should be on every TPM’s bookshelf.

It is exactly what it claims to be: A handbook to guide you through all aspects of the TPM role. It certainly is a resource I wish I had when I started my TPM journey, and it is a resource that is still beyond my own capability today to produce.

Joshua is operating at a whole different level as a TPM, as evident by his major contributions to the TPM Craft cutting across the industry.

For those of you who appreciate the structured, pragmatic approach of the PMP world, this book will feel like a perfect fit.

There are many fundamental skills covered in this book that are absolutely necessary to being a high-impact TPM (such as managing the program lifecycle, leadership, system design, etc). All of those are top quality.

But this review will focus on the sections that set this book apart from other TPM books. These sections prove that Joshua has years of experience to grasp the nuances of the role as well as his ability to stay relevant.

Here’s what we’ll look at:

• Emotional Intelligence for Technical Program Managers

• Driving Clarity as a central feature to everything for TPM’s

• Using Generative AI as a Technical Program Manager

Let’s dive in.

Emotional Intelligence for Technical Program Managers

I’m going to start with one of my favorite unique sections in his book: Emotional Intelligence.

Why do I love this section so much? Because Emotional Intelligence is one of the biggest underlying factors that sets up a person to be a high-impact TPM.

Joshua takes it a step further by breaking down EQ into 4 components:

1. Self-awareness

2. Self-regulation

3. Empathy

4. Social Skills

Each one builds on the previous, check it out: Without self-awareness, you cannot self-regulate. Without self-regulation, you cannot appreciate other people’s experiences and adjust accordingly, ie empathy. Without empathy, you cannot navigate social networks effectively to influence without authority.

The longer I’ve been in my career as a TPM, the more I become convinced that TPM’s are not only change agents, but we are leaders through changing environments. We can be the anchors to navigating challenging situations.

And EQ is at the very heart of being able to do that well.

Check out one of Joshua’s latest LinkedIn posts sharing some detail of this section of his book:

Joshua Teter, PMP on LinkedIn: #eq #tpm #ai #technicalprogrammanagement

Emotional Intelligence (#EQ) is the most important skill set for a #TPM.

www.linkedin.com/posts/joshua-teter_eq-tpm-ai-activity-7254506793488273411-s2hc?utm_source=share&utm_medium=member_desktop

Driving Clarity as a central feature to everything for TPM’s

Joshua takes a full chapter to highlight the importance of driving clarity. It is a foundational skill, he says, that doesn’t necessarily apply to a single part of the role of a Technical Program Manager, but rather all throughout it.

As you progress through your TPM career, you’ll experience greater and greater levels of ambiguity. Driving clarity is a skill acting as a consistent thread or theme through each level, but grows in proportion with the ambiguity. (this topic actually relates heavily to one of my formers posts on ambiguity: The 5 Levels of Ambiguity).

What can happen when you don’t drive clarity early enough?

• Scope creep, which happens especially quickly when requirements are not well understood.

• Gold plating, or the continual addition of features or enhancements never asked for.

• Cross-org impacts, or when your project has conflicts with others across the company.

• Sneaky risks, or the lack of risk management early on causes chaos down the road.

Driving Clarity is one of the most foundational skills that a TPM must acquire and apply to all aspects of the job.

This chapter in The TPM Handbook does an excellent job expanding on what that looks like in practice. The fact that there’s a whole section dedicated to it

Using Generative AI as a Technical Program Manager

I imagine the future professional world that my kids will grow up in. Knowing how to effectively use Generative AI will be as common as today’s skills of excel, googling, and using google docs.

Luckily, this 2nd edition of The TPM Handbook has an entire chapter dedicated to the topic. This section on Generative AI for TPM’s is one of the major additions from Joshua that keeps this book on the bleeding edge of our craft.

I personally use Generative AI tooling for generic use cases on a weekly basis, so I was really excited to dive in.

This section goes beyond simple use cases applicable to TPM’s. Joshua reviews the fundamentals of Generative AI and how it relates to machine learning, natural language processing, and deep learning.

Perhaps the most actionable portion of this chapter is focused on Prompt Engineering, which Joshua explains as “learning how to most effectively ask a question for a GenAI system to get the most accurate and detailed answer.

The next sections are focused on key use cases where GenAI can be applied as a TPM:

• Project Planning

• Dependency Mapping

• Risk Management

• Stakeholder Management and Communication

• Bridging Communication Gaps in Software Development

Perhaps most important in this section is the continual reminder that GenAI has fundamentally changed the landscape for software development and any associated roles, like ours.

A word of caution, though.

Most Generative AI tooling assumes you opt-in with data sharing back to the model. This can be dangerous if you begin sharing proprietary company information (such as code, financials, or strategic plans).

If you’re uncertain of how to proceed, do the following:

1. Check if your company has a GenAI Policy. If not, be extra cautious.

2. Always explore ways to turn off data sharing unless you’re using GenAI for personal reasons, which is then up to you on your data sharing preferences.

3. Stay generic in your prompt engineering efforts.

With proper safeguards, you can still take advantage of Generative AI to amplify your impact as a Technical Program Manager. 

Recap

The TPM Handbook (2nd edition) is comprehensive, methodical, and relevant. If you’re aspiring to grow your skills in The TPM Craft, then this book is a must.

It isn’t necessarily a “read it front to back” once you get it, though. I have found a ton of value treating it as a reference book, reviewing various aspects the TPM Craft as necessary.

For that reason, it will always have a spot on my bookshelf as a reliable reference to improve my skills within the TPM Craft.

Check out the link below to get your copy!

A word from this week’s sponsor…

Stay up-to-date with AI

The Rundown is the most trusted AI newsletter in the world, with 1,000,000+ readers and exclusive interviews with AI leaders like Mark Zuckerberg, Demis Hassibis, Mustafa Suleyman, and more.

Their expert research team spends all day learning what’s new in AI and talking with industry experts, then distills the most important developments into one free email every morning.

Plus, complete the quiz after signing up and they’ll recommend the best AI tools, guides, and courses – tailored to your needs.

Sign up to start learning.

Resources

📚 Grab your copy of The Technical Program Manager’s Handbook!

Without further explanation, grab your copy today! This isn’t a sponsored post, so I don’t have any valuable discount to offer. It really is just a valuable resource.

Technical Program Manager's Handbook:

Unlock your TPM potential by leading technical projects successfully and elevating your career path

https://a.co/d/6KUjsG7

Learn

👨‍🏫 TPM Promotions & Manager Partnerships

Do you ever feel like the path to promotion is a constant uphill battle? I know I have.

Over the past few years, I’ve faced some of those struggles, but I’ve found an approach that works. It’s helped me get promoted twice, most recently to Staff Technical Program Manager, and I’m here to share it with you today.

A Failing TPM Career Matrix

A couple of weeks ago, I spoke with a highly competent Senior TPM about her struggles with getting promoted.

She’s delivering on strategic, high-impact initiatives, regularly interfaces with the C-suite, and is one of the most experienced TPMs in her organization. Yet, despite all this, she’s hitting roadblocks in her efforts to move up. The root of the issue?

In our conversation, she shared frustrations about how useless the TPM Career Matrix is to her in being able to advocate for herself.

The company’s TPM Career Matrix is failing its purpose, and it’s making it unnecessarily difficult for her to advance.

• It lacks clear, specific criteria, making it difficult for TPMs to understand what’s required for advancement.

• It isn’t respected by other roles, leading to a lack of credibility and consistency.

• It fails to set a standard for TPM excellence, leaving employees without a clear path to growth.

A well-designed TPM Career Matrix should be a clear, objective roadmap for growth. It guides TPMs in their development, sets the bar for excellence, and earns respect across the organization. When done right, it empowers TPMs to see exactly what it takes to reach the next level and gives them the confidence to get there.

Be Collaborative, Not Critical

At first glance, it might seem like the best approach is for this Senior TPM to point out the issues with the TPM Career Matrix and propose improvements directly to her manager.

But addressing the problem head-on like this isn’t what I would recommend

Doing so might lead to a longer, more difficult path to promotion. No one wants their career growth delayed, especially when navigating conversations about promotions can be high-stakes and delicate.

So, how would I approach this?

Instead of confronting a manager with a list of issues (especially if they helped create or maintain the current matrix), do this: focus on building trust, clarifying the ambiguity around career growth, and positioning yourself as a collaborative partner, not a critic.

Tackling this problem takes a measured sense of empathy, along with a delicate mix of confidence and humility.

In this situation, your manager is your greatest ally. You need their support and advocacy, not just agreement. But securing that support requires more than simply pointing out flaws—it means building a partnership.

This approach (fostering trust, clarifying goals, and partnering with my manager) was exactly how I navigated my path to Staff Technical Program Manager over the past year.

Let’s explore how you can shift the conversation to build alignment and pave the way for your career growth.

Framing The Promotion Conversation

As with any effort you engage in as a Technical Program Manager, one of your first goals is to create clarity from ambiguity.

• Step 1, TPM Career Matrix: Get a copy of your company’s TPM Career Matrix.

• Step 2, History: Write down the programs you’re running and highlight your big wins over the past 12 - 18 months. Start with simple bullet points and then see if you can transform them into compelling narratives.

• Step 3, Future: Write down your targeted goals over the next 6 - 12 months within the scope of the program’s your involved in today.

• Step 4, Cross-Reference: Begin cross-referencing your History and Future with the existing TPM Career Matrix available to you. Highlight areas where you feel there is ambiguity, and also areas where you may be delivering as expected (or above!)

• Step 5, Share Intentions: Your manager can’t help you if you never tell them what you want to achieve. You need to state your intentions, or your why, behind wanting the promotion. Help your manager see your intentions. Your goal should be to make it easy for your manager to become your ally in this journey to promotion.

• Step 6, Get Clear: Once you’ve stated your intentions for the promotion, you can now have a clarity conversation with your manager to validate what it takes to get promoted.

Example Promotion Conversation

Let’s take a look at a way this conversation (steps 5 and 6) may happen.

The outcome of this conversation (or series of conversations) is to have an objectively agreed upon plan with your manager to hold both you and your manager accountable for the end result of a promotion.

(One of the base assumptions in this conversation is that you have at least a somewhat reasonably healthy relationship with your manager. There are obviously some edge cases where managers may be harder to work with.)

Promotion Conversation Principles

The above conversation is merely an example and vignette of how you can frame the promotion conversation. In reality, this isn’t a single conversation. It is a series of conversations with regular check-ins and adjustments over time.

Let me pull out some of the major principles I attempted to communicate in the example above:

• Partnership & Trust. Explicitly call out the hopeful partnership with your manager to build a case for promotion. If you rely on implicit communication for this, the manager may not fully feel the on-going ask to move your career with you.

• Questions. Identify key questions you can ask your manager. You want to go into the conversation with an open mind and ready to see the promotion effort from your manager’s eyes. Make sure you seek to understand the promotion process as well, don’t just assume your manager makes all the calls for this.

• Confidence. Show up with confidence! If you have been performing or over-delivering in various areas, don’t be shy to share that. At the same time, give your manager room to give feedback on their relative amount of alignment with your impact.

• Goals & Business Impact. Your goals provide evidence that you’re ready to be promoted. The more that you’re goals are directly aligned with business impact, the easier it is to justify a promotion. In most mid-to-large tech companies, your manager will have to advocate on your behalf to the organizational leaders. If you put your goals in terms of business impact, you make the advocacy job of your manager way easier.

• Shared Expectations. Remember, this is a major goal of having these conversations. Even if the TPM Career Matrix for your company isn’t ideal, you can craft a shared plan with your manager through conversations like these.

• Not Selfish. It isn’t selfish to strive for a promotion, but it may come off as greedy if you aggressively push for a promotion when you haven’t yet helped your manager build the case for your promotion.

Recap

A broken TPM Career Matrix can make getting promoted challenging, but it doesn’t have to hold you back

You can overcome these challenges by partnering with your manager.

Start by expressing your intentions, setting clear goals, and testing them against the existing framework. Regularly check in on progress to ensure you stay aligned. All of this is to be done within a relationship of trust and collaboration.

In the meantime, continue driving high-impact projects and expanding your skill set. That way, when the right opportunity comes along, you’ll be ready for it.

Don’t Measure Your Life By Promotions

Remember, promotions are not the measure of success for your overall life. They are a single data point to be taken in consideration with a much broader perspective of health, stability, family and friends, hobbies, etc.

YOU ARE MORE THAN YOUR JOB. YOU ARE MORE THAN A PROMOTION.

You are a human being with much more infinite worth. I wanted to close on this note to keep help keep things in perspective.

A word from this week’s sponsor…

Unlock Windsurf Editor, by Codeium.

Introducing the Windsurf Editor, the first agentic IDE. All the features you know and love from Codeium’s extensions plus new capabilities such as Cascade that act as collaborative AI agents, combining the best of copilot and agent systems. This flow state of working with AI creates a step-change in AI capability that results in truly magical moments.

Download It Free Today

Resources

📚 The World’s First Open Source TPM Ladder Guide

If you don’t Straker Carryer in the world of Technical Program Management, you’re missing out.

Straker is a thought-leader TPM currently working at Zillow where he was a key influencer in establishing the TPM practice there. His own blog is filled with awesome posts that go beyond the world of TPM-ing.

Earlier this year he published an open source TPM ladder. This ladder does a really great job setting up an opinionated stance on how to measure critical skills and progress through 5 levels of TPM seniority. Check it out below.

The World’s First Open Source TPM Ladder Guide

After my last two-part series about creating ladder guides, I finally have one for TPM! To my knowledge, this is the first ladder guide for TPMs available for use in an open and free way. Read the post for the links to freely use the ladder guide yourself!

strakercarryer.com/posts/the-worlds-first-open-source-tpm-ladder-guide

Learn

👨‍🏫 Happy Birthday to the TPM Craft Newsletter!

It has officially been ~1 year since I sent out the first post of The TPM Craft Newsletter! Happy birthday to the newsletter!

Gif by theoffice on Giphy

What began as a little experiment has turned out quite nicely! At first, I thought only my dad, mom, and siblings would be interested in reading it. (My wife didn’t subscribe, but I can’t really blame her for that.) 

To my surprise, the TPM community has found value in my musings. At the recent TPM summit, I was thrilled to have so many people come up and share how much they’re enjoying the newsletter.

At the same time, I constantly have a feeling of imposter syndrome. Who am I to write on these topics?

I don’t feel like an expert any more than many of you I’ve met.
I feel like there are others who are much more qualified to write about Technical Program Management.
After sending a post out, I always feel like someone is going to point out a major flaw and that I’ll be discovered as an imposter to the TPM world.

Despite the feeling of imposter syndrome, the show must go on.

To the best of my ability, I’m committed to continue writing and aim to deliver even more value for any current and future reader of the newsletter.

But before we talk about the future, let’s talk about the past 12 months. I’m going to pull back the curtain so you can see the newsletter from the operator’s (me!) perspective.

Why did I start writing?

One of my fundamental beliefs about the TPM role is centered on the skill of writing. I believe the it is a highly underrated skill to becoming a high-impact TPM.

Writing is a First Principle of becoming a high-impact TPM (ie; a skill that is among the most foundational and fundamental).

Writing has the power to persuade, amplify, encourage, and motivate. The better you become at writing, the greater your potential impact at a TPM.

This is a hill I am willing to die on.

This is the backdrop to my decision to invest more time and energy into improving my own writing in a public forum like this newsletter.

But just believing in the power of writing didn’t convince me to start the newsletter. I had very specific objectives in mind for this experiment.

Newsletter Objectives

When I started the newsletter, I had 3 really simple objectives (perhaps more like hypotheses):

1. If I improve my long-form content skills (as opposed to short-form LinkedIn posts), then will that translate to higher writing impact at work?

2. If I write a public newsletter on a regular rhythm, then will the increase of required discipline help accelerate my writing improvement?

3. If I write specifically to the TPM community about the TPM domain, then will they find value in it and be able to improve their own TPM skills?

Two out of three objectives were focused on improving my own writing abilities.

But I wanted to improve my writing in the context of turning it into value for others. By writing publicly, it forced me to focus on value instead of keeping my thoughts to myself.

A good idea trapped in my mind usually ends up dying if I let it just sit there. Writing has been my outlet to give my ideas fertile soil to grow and gather feedback from others.

Key Metrics & Results

But wait. Is the newsletter actually successful?

In the spirit of transparency, let’s take a look at both quantitative and qualitative measures to answer that question.

Quantitative Key Metrics

TLDR: The TPM Community may be small, but wow, is it engaged! Here’s a look at how the numbers stack up after one year. Overall, I believe the quantitive metrics show a reasonable amount of success.

• Unique Posts: 32 (which is about ~2.6 emails per month)

• Subscriber Growth: 0 to 1.3k (that’s an additional ~108 people per month averaged across 12 months.)

• Open Rate: 65.11% (compared to ~30%, which is the general newsletter standard but can vary based on specific industries)

• Click Through Rate: 5.89% (compared to ~3%, which is the general newsletter standard but can vary based on specific industries)

• Unsubscribe Rate: 0.38% (compared to <1% for general newsletter average, so the TPM Craft newsletter appears to be in-line with that.)

• Financials: Loss of $654.53 (The platform I use isn’t free, but I see this as a learning investment. Looking ahead, I’m planning ways to turn this into a win-win for both you and the newsletter.)

Qualitative Key Metrics

TLDR: Positive feedback through great networking opportunities combined with an improved ability to retain career lessons confirms qualitative success.

• Reader Feedback: The general sentiment from readers is positive. This comes in many different forms: DM’s in LinkedIn, direct email responses to the newsletter, in-person feedback at the TPM Summit, etc.

• Retained Lessons: Each post is usually loosely based on a real experience. Career lessons that may have been lost in memory in the past but are now sticking with me longer. Being able to retain these career lessons more effectively is invaluable.

• Networking Opportunities: Writing a public newsletter puts me out there, for better or worse. It has opened up opportunities to meet new people where there may have been more friction had I not been writing regularly.

• On-the-job Feedback: Throughout the past year, there have been a handful of instances at work where my writing quality received really great feedback from stakeholders. Writing this newsletter probably isn’t the sole reason for that feedback, but I definitely it deserves some credit.

Results

Overall, I believe the TPM Craft Newsletter is a success so far!

The quantitative and qualitative measurements of The TPM Craft newsletter indicate that the objectives are being achieved.

It’s not perfect, and there are areas where I want to improve and grow moving forward. But looking back on the past 12 months, I’m happy with the impact of this newsletter on myself and the TPM Community.

What comes next?

There are so many ideas and opportunities that have been rolling into my mind to make the TPM Craft Newsletter even better.

But then, reality comes knocking. Priorities must be set.

My top priority is being the best husband and father I can be (and trust me, the kids aren’t newsletter fans…at least not yet!). With 3 kids and daily demands of being a TPM, time and energy are scarce resources.

All this to say, I find myself being extremely picky about what to do next. I have to ruthlessly prioritize. Here’s are the things at the top of my list of considerations:

• I remain committed to writing free posts regularly (anywhere from 1 - 4 times a month). I do want to refine the content and style a bit more.

• I am exploring the idea of Email-based Courses which is a series of 5 - 7 sequential emails aimed on a specific, relevant TPM topic such as Writing, IC Leadership, Prompt Engineering, and more.

• I want to identify collaboration opportunities with others who have a good pulse on the TPM Craft.

• I want to create downloadable templates and guides to make this newsletter experience even better.

(If you have any amazing ideas of what to do next or just simple feedback on the list above, reply directly to this email! 📧 I’d love to hear from you!)

Wrap Up

I’m excited about what comes next for this newsletter. It is both challenging and fulfilling. I’m grateful for the high level of collaboration across the TPM Community that makes this whole thing possible.

THANK YOU for trusting me with space in your inbox and attention during your busy day.

Until next time, happy TPM-ing!

Testimonial Request

🙏 A Small Favor

I'm eager to show everyone the value of this newsletter.

Instead of me just saying this free newsletter is valuable, your words can make a real difference.

I’d love to hear from you! If this newsletter has been helpful, consider sharing your thoughts in a quick 3-question survey. Your testimonial could inspire future readers and help grow our community

(Psst! These reviews land on the subscribe page of the TPM Craft site where I'm creating a wall of testimonials to help new readers see the value through your eyes. Right now, there are only 3 reviews, but I know many of you have found this newsletter helpful!)

A word from this week’s sponsor…

Daily News for Curious Minds

Be the smartest person in the room by reading 1440! Dive into 1440, where 4 million Americans find their daily, fact-based news fix. We navigate through 100+ sources to deliver a comprehensive roundup from every corner of the internet – politics, global events, business, and culture, all in a quick, 5-minute newsletter. It's completely free and devoid of bias or political influence, ensuring you get the facts straight. Subscribe to 1440 today.

Sign up now!

Resources

📚 3 Popular Posts from the past 12 months

Linked below are a few of my previous articles over the past 12 months that either got high ratings, lots of engagement, or otherwise just got great feedback. If you haven’t read them, enjoy!

Prompt Engineering for TPMs

Why Technical program managers should care about prompt engineering, and 3 use cases where prompt engineering can help you multiply your impact.

the-tpm-craft.beehiiv.com/p/tpm-prompt-engineering

Stop Starting, Start Finishing

Do less, better by managing your WIP

the-tpm-craft.beehiiv.com/p/stop-starting-start-finishing

Building Stronger Partnerships with Engineering Managers

Discover effective strategies for building strong partnerships between TPMs and EMs. Learn advanced collaboration techniques and practical tips to partner well.

the-tpm-craft.beehiiv.com/p/partnering-with-engineering-managers

Learn

👨‍🏫 Understanding the 5 Levels of Ambiguity

Why does it matter?

As you progress in your career, ambiguity becomes less of an obstacle and more of an opportunity.

Mastering ambiguity is essential as you progress in your career. Whether it’s executing a predefined plan or navigating uncharted territory.

The better you get at handling the unknown, the more valuable you become. 

But to thrive, you need to recognize the different levels of ambiguity you’ll face and how they evolve as you progress through your career.

Ambiguity Expands Throughout Your Career

When I got my first “tech job”, I was still a university student.

It was an on-campus job as a manual Quality Assurance Analyst. I received user stories from either the dev team or directly from customers. Our software was a simple people management tool for one of the schools within the University.

Needless to say, the ambiguity was extremely low.

Everything was spelled out for me! Start here, click X, scroll down to Y, enter ABC, record the result. It was tedious work, but provided valuable bug information back to the dev team. (Eventually I automated all this with a UI script runner, but that isn’t the point of this post).

Although it was tedious, it is was an appropriate level of work for me since I brought zero technical skills to the table, but I pitched myself as detail oriented and ambitious to learn software development. The pay matched the level of complexity: low.

Fast forward to my career today and my interaction with ambiguity is far different.

For example, one of my “TPM Wins” in the past 12 months was this: Successfully leading teams to stand up Disaster Recovery capabilities for some of our cloud products.

This was a wildly different experience from my first day as a QA Analyst!

We knew we needed multi-region Disaster Recovery capabilities. But we didn’t know the problems or obstacles to even get there. It was a only a dream.

There wasn’t clarity around how to solve those unknown problems or who should be involved. We knew it would be big as is spanned every team from low-level infrastructure to top-level product teams.

All the details were totally ambiguous.

This got me thinking: As I level up in your career, how does the level of ambiguity shift? How would I describe the evolution of ambiguity?

Breaking down Ambiguity into 5 Levels

As you grow throughout your career, you’ll see a natural evolution around the types and intensity of Ambiguity you’ll face. Starting with level 1 (low ambiguity) and moving to level 5 (high ambiguity).

• Level 1: Execute

• Level 2: Align

• Level 3: Solve

• Level 4: Investigate

• Level 5: Discover

Each one builds on the previous.

Level 1: Execute

At this level, the task is straightforward: the problem is clear, the solution is defined, and the key players are already identified. As a Technical Program Manager, your role here is to drive execution. There’s no need for brainstorming or troubleshooting. You’re essentially handed a playbook, and it’s up to you to make sure the team sticks to it and delivers on time.

Level 2: Align

In this scenario, you know the problem and the solution, but the team isn’t fully in place. As a Technical Program Manager, your focus is on identifying and rallying the right people to ensure alignment. You’ll need to figure out who has the skills, influence, or resources to make the solution happen. Once you’ve assembled the team, it’s about keeping everyone aligned and moving toward the end goal.

Level 3: Solve

Here, the problem is clear, but the solution isn’t. As a Technical Program Manager, you’re expected to take a step back and generate potential solutions. This is where your problem-solving and analytical skills come into play. You’ll work with stakeholders to brainstorm, evaluate options, and create a solid plan. Once the solution is defined, it’s up to you to build the right team and lead the execution.

Level 4: Investigate

At this level, the problem itself is vague, and you’re tasked with getting to the root of it and driving the solution to completion with the right people onboard. As a Technical Program Manager, you need to dig deep—analyze data, interview stakeholders, and collaborate with different teams to uncover what’s really causing the issue. Once you’ve diagnosed the problem, your next job is to propose solutions, form the right team, and ensure everything gets executed effectively.

Level 5: Discover

This is the most ambiguous scenario—you know there’s an opportunity to improve, but the specific problems aren’t even clear yet. As a Technical Program Manager, you’re in exploration mode. You’ll need to discover: assess the landscape, identify the biggest challenges, and figure out where to make the most impact. Once you’ve uncovered the issues, it’s time to devise solutions, build a team, and drive the project to completion.

Clarifying Ambiguity Improves Situational Awareness

This specific post doesn’t intend to tell you exactly how to handle each of these levels of ambiguity.

But the first step in becoming a high impact Technical Program Manager is growing your situational awareness. If you can’t articulate the type or source of ambiguity that associated with each program or project you drive, you may struggle to deliver clarity and make progress.

As you read through the levels above, compare them to your current projects. What level do they fall into? What can that teach you about your highest value contributions to the project?

📧 Perhaps we can dive into these levels in a future email with added depth of “tactics and strategies to handle each level”. Reply directly to this email if you think that would helpful content in the future!

A word from today’s sponsor…

Get software delivered with financial guarantees, focusing on your goals

With ELEKS' product-oriented delivery, we guarantee that your software vision is realised in a superior solution implemented within your timeline or budget constraints. We prioritise your success and focus on maximising your product's business value.

Our team provides industry-leading expertise across your entire SDLC and takes full responsibility for the implementation roadmap, budget, quality metrics, and process setup, ensuring your strategic goals are achieved.

Schedule your consultation

People

🤝 Arpit Shah, TPM @ Google

I’ve been following Arpit for a while now and we’ve interacted via comments on some of his great posts on LinkedIn. He regularly shares fantastic insights of his experience as a TPM, and how to improve your own skills as a TPM.

If you’re looking to increase the amount of TPM content on your LinkedIn feed, Arpit is a great person to follow!

Here’s one of his latest posts on Imposter Syndrome as a TPM:

Arpit Shah on LinkedIn: You are not alone - as a Technical program Manager imposter syndrome is real…

You are not alone - as a Technical program Manager imposter syndrome is real, common & surprisingly easy to manage First of all, it is okay to have imposter syndrom.

www.linkedin.com/posts/shaharp07_you-are-not-alone-as-a-technical-program-activity-7245099572379734017-FI13?utm_source=share&utm_medium=member_desktop

Resources

🎉 TPM Summit, TOMORROW!

Don’t forget — The TPM Summit is TOMORROW!

TPM Summit 2024

Join us for our 2nd Annual Global TPM Summit! Find TPM leaders, networking, exhibitors, food, SWAG, and more at this year's expanded event!

events.tpmevents.org/TPMSummit2024

Hear from incredible speakers from top companies such as:

• Jen Krieger: VP of Engineering Operations @ GitHub

• Lyly Ly: Sr Dir of RnD Operations @ Shopify

• Aman Bawa: Sr. Dir. TPM @ Salesforce

• Jane Chiu: Engineering Chief of Staff @ Coda

You can attend in-person or remotely.

Learn

👨‍🏫 Book Review: Evangelizing the TPM Craft

When I write these newsletter posts, I often imagine writing to my past self 3 or 4 years back in time. I ask:

What advice or guidance would I give to myself as a young-er Technical Program Manager?

Initially, this was because there weren’t that many resources out there about the role of a Technical Program Manager. I wanted to begin building a series of articles to act as a paper trail for anyone else going on a similar TPM journey.

In terms of books, there wasn’t much (if any?).

I had collected a series of Program Management books, Product Management books, and System Design books. This was my informal research approach as I navigated the unknowns of being a TPM. But ultimately, I was left wanting a better form of mentoring and coaching in the form of a dedicated TPM book. It just wasn’t there. And I certainly wasn’t ready to write on myself.

Fast forward to today.

Good news: the situation is not the same!

A Growing Pool of Resources

Across the TPM Community, we’ve got a growing collection of fantastic books to choose from. Here are at least 4 that come to mind:

• Technical Program Manager's Handbook: Unlock your TPM potential by leading technical projects successfully and elevating your career path by Josh Teter (2nd revised edition launching soon!)

• The Art of Strategic Execution: Finding Success in Technical Program Management by Priyanka Shinde

• The Technical Program Manager's Guide: Navigating the Path to Success by Arpit Agrawal

• Evangelizing the TPM Craft: Principles and Practices of Technical Program Management in Silicon Valley by Zhanat Abylkassym

There might even be a few more (none of the links above are sponsored).

A lot could be said about all these books. Most recently, I’ve been reading the last one linked there, Evangelizing the TPM Craft by Zhanat.

He has created such an valuable resource for the TPM Community. My past self would’ve been thrilled to have this level of depth and breadth to guide my efforts and career path as a Technical Program Manager.

I want to share with you what I found so incredibly valuable in his book. Let’s jump in.

Zhanat’s Book is Wildly Comprehensive

Right off the bat, you should know that this book is very comprehensive. Consider these key questions that are answered by various portions of the book:

• How do TPM’s fit into engineering orgs?

• How does the TPM role compare with partner roles like engineering manager, product manager, project manager, and even a non-technical program manager?

• How can a person transition into the TPM role?

• What are the expectations of TPM’s at different levels of seniority?

• How should I effectively structure my TPM resume? and what should I expect in interviews?

• What does it mean to be a technical program manager? (this was one of my favorite parts! Zhanat over-delivers in this section)

• What exactly does it look like to drive a program as a technical program manager?

• What does it mean to manage as a technical program manager?

• How do I intentionally grow as a TPM?

• How do I influence without authority?

• How do I manage conflict?

Wow. Look at those hard hitting questions. And that’s just scratching the surface.

There is absolutely no room in this post to go through each of those sections, so I’d like to share 3 of my favorite highlights.

3 of My Favorite Highlights from Evangelizing The TPM Craft

Highlight #1

When I started my TPM journey, I was under the false pretense that the ideal TPM situation is to walk into a well-structured project to run, I’d run it, and everyone would be happy.

I had many, many wake-up calls before I truly began to see the job of a TPM for what it really is.

As humans, our brains naturally resist ambiguity and chaos. The natural reaction is to be stressed with ambiguity and chaos. Solving for ambiguity and chaos are hard problems.

As a Technical Program Manager, you get thrown into ambiguous and chaotic situations all the time. The fundamental acknowledgement that this is the job helped pivot my paradigm years ago.

While everyone else scrambles, frets, worries, and stresses…the TPM is there to be an anchor, a guide, and navigator to calm waters.

You are there because of the ambiguity and chaos.

In essence, you are this dog:

Giphy

But great TPM’s don’t say “this is fine”.

They say “this isn’t fine! But eventually it will be fine. Here’s our path to exit the building or put out the fire”.

Once you understand and embrace this, you’ll be able to see how to be a great TPM much more clearly.

Highlight #2

In this section, Zhanat over-delivers in shedding light on what it means to be a technical program manager.

Here’s what I mean when I say he over-delivers:

• Zhanat gave example after example of how technical aptitude helped him have incredible impact as a TPM in Amazon, Uber, and Robinhood. These examples are extremely illuminating.

• Zhanat dives into the history and evolution of foundational technologies that have led us to the current state of system design. For example: history of the internet, history of WWW, history of RPC, history of gRPC and microservices. I was especially thrilled about this because I’ve written a similar message about why understanding system design through a historical context is so crucial.

• Zhanat explains the basics of system design, really well. Topics like scaling, availability, load balancing, and more.

Honestly, I’ll be revisiting this section again. Since it is highly technical, I know that another read through will reveal even more useful things I missed the first time.

Highlight #3

Zhanat’s take on “how to influence” is unique and useful. He anchors much of his research of influence on the law of reciprocity and the origins of that practice going all the way back to ancient greek culture.

He takes it a step further with framing reciprocity and influence with tangibly-explained currencies. Here are some of the currencies that act as ways we influence via reciprocity:

• Inspiration-related currencies: motivating goals that provide meaning to work and leads to greater motivation.

• Task-related currencies: enabling a person with the right assets or capabilities to be successful with a given task.

• Position-related currencies: boost a person’s standing within the organization with indirectly better enables them do accomplish their goals.

• And more…

Ultimately, I feel like Zhanat pulled off a super difficult task: he effectively took a very soft-skill and turned it into a very tangible and actionable point of leverage to better influence without authority as a TPM.

Get the book!

Honestly, if you’re a Technical Program Manager then you should have this book on your shelf. It reads like a TPM mentor is speaking directly to you.

Zhanat, you’ve outdone yourself. Great job.

This is not a sponsored review. It’s just a really good book.

A word from today’s sponsor…

Looking for unbiased, fact-based news? Join 1440 today.

Upgrade your news intake with 1440! Dive into a daily newsletter trusted by millions for its comprehensive, 5-minute snapshot of the world's happenings. We navigate through over 100 sources to bring you fact-based news on politics, business, and culture—minus the bias and absolutely free.

Subscribe to 1440 today.

Events

Don’t forget — The TPM Summit is happening in 1 week!

TPM Summit 2024

Join us for our 2nd Annual Global TPM Summit! Find TPM leaders, networking, exhibitors, food, SWAG, and more at this year's expanded event!

events.tpmevents.org/TPMSummit2024

Hear from incredible speakers from top companies such as:

• Jen Krieger: VP of Engineering Operations @ GitHub

• Lyly Ly: Sr Dir of RnD Operations @ Shopify

• Aman Bawa: Sr. Dir. TPM @ Salesforce

• Jane Chiu: Engineering Chief of Staff @ Coda

You can attend in-person or remotely.

Learn

👨‍🏫 Owning Mistakes as Leadership Trait

In my last post, 4 Strategies to Manage WIP, there were some glaring formatting issues that were completely distracting from the core message of the post.

I had a few options for how I could react:

1. Stop Writing The TPM Craft Newsletter. It’s simply, really. Decide I don’t have time to write 100% perfected quality and stop writing the newsletter.

2. Frantically Send More. In order to “cover up” a mistake, I could’ve sent more emails that were formatted correctly in an effort to earn back trust.

3. Own the Mistake, Keep Moving. Keep the steady rhythm of the newsletter and turn it into an opportunity for myself and all of you wonderful readers.

If it isn’t obvious yet, my decision is #3. As a writer, I will own my writing mistakes.

Owning mistakes is a foundational leadership trait. If you are unable to own your mistakes and instead shift to blaming, then you’ll never be the leader you hope to be.

Let’s talk about how and why this works.

(I’ll be referencing a few books in this post, buckle up!)

Owning Mistakes Builds Trust

As a Technical Program or Project Manager, you’re right in the thick of complex initiatives, working with different teams that count on you for clear direction and accountability.

Mistakes are going to happen—that’s just the reality. But how you handle them. That’s what sets you apart as a leader.

Owning up to your mistakes doesn’t make you weak; in fact, it’s one of the strongest moves you can make. When you take responsibility, you build trust, earn credibility, and set the right example for your teams and stakeholders.

If you expect accountability from others, you have to lead by example and exhibit the type of accountability you wish to see.

Extreme Ownership is a favorite leadership book of mine written by former US Navy Seal, Jocko Willink. He teaches: as a leader, you have to own everything in your world. 

For TPMs, that means not just your own actions but your whole program’s performance, even when things go sideways. It’s tempting to deflect blame or protect yourself when mistakes happen, but real leadership is about stepping up, owning the problem, and guiding the team toward a solution.

Owning mistakes is crucial because trust is the foundation of influence.

When team members, stakeholders, and executives see that you’re willing to acknowledge your missteps, they’re more likely to trust that you’re being transparent, realistic, and working in the best interest of the project. Your manager will see that you have self-sufficient skills of reflection and growth.

By owning your mistakes, you increase trust. By increasing trust, you increase your ability to influence without authority.

(I wanted to write more about trust right here, but that wildly increased the length of the post. Check out this book, The Speed of Trust, that inspires a lot of my thinking around the importance of Trust).

In my example of sending a poorly formatted email, the trust of readers was undoubtedly impacted. Luckily the stakes aren’t very high in this situation, but the principle remains the same.

My decision to show up again, own my mistake, and move forward is a reflection of my desire to transparently grow as a leader.

I’m on the same journey as all of you, iteratively improving at our craft of being a TPM.

Owning Mistakes Diffuses Conflict

Now let’s pivot a little bit to talk about how owning mistakes can be a tool for you as a TPM.

Think about the times when you are trying to build buy-in, influence others, get people aligned, drive decisions, etc. All these activities can be described as some flavor of negotiation. You’re constantly negotiating.

As you’re negotiating, mistakes may happen: Some data may have been inaccurate, communications may have slipped, milestones may have been missed.

When mistakes happen, stakeholders, team members, or executives might have negative assumptions or concerns. How can you handle those situations?

In Never Split the Difference, Chris Voss introduces the concept of neutralizing the negative through an accusation audit. This is an awesome tool for TPMs when addressing mistakes, especially in high-stakes environments where tensions may run high.

Voss suggests calling out the potential accusations head-on before others can. This diffuses tension and helps you gain control of the narrative.

For example, if a critical deadline is missed, you could start the conversation by saying:

This approach neutralizes the negative by addressing concerns upfront, signaling transparency, and putting others at ease. It shows that you’re aware of the issue and already taking responsibility for it.

You will want to prepare with some analysis on why the targets were missed, but that can often become a secondary question if you’re able to demonstrate what is actions are being taken to move forward (which may include fixing processes to avoid the same failure in the future).

TLDR

By combining the principles from Extreme Ownership and Never Split the Difference, TPMs can:

• Build trust from stakeholders: When you take full ownership and acknowledge potential concerns through an accusation audit, you manage the narrative and strengthen trust, even in difficult situations.

• Foster a culture of accountability: Owning mistakes encourages your team to follow suit, leading to a healthier, blame-free working environment where continuous improvement is prioritized over fear of failure.

• Build stronger relationships: Taking ownership, while neutralizing the negative emotions that often surround mistakes, helps preserve and even strengthen relationships with cross-functional teams, clients, and executives.

Owning mistakes isn’t just about saying “my bad”—it’s about stepping up, taking charge, and showing true leadership.

As a TPM, you’re the bridge between the technical and strategic sides, and how you handle mistakes can either build trust or damage it. I’ve found success in combining the accountability from Extreme Ownership with the communication strategies from Never Split the Difference.

Resources

📚 Currently Reading

My current reading Zhanat’s latest book, Evangelizing The TPM Craft.

There are fantastic insights in this book addressing just about anything you can think of in the world of being a TPM: Resumes, Interviewing, Role Comparisons, Core Responsibilities, etc.

I’ll definitely be writing up a review once I’m done!

Evangelizing the TPM Craft: Principles and Practices of Technical Program Management in Silicon Valley

Shared via Kindle. Description: Over the past decade, the role of the Technical Program Manager (TPM) has seen a meteoric rise. Once exclusive to tech giants like Amazon, Meta, and Google, it has now become ubiquitous, stretching its influence from Silicon ...

read.amazon.com/kp/embed?asin=B0CKCSKJB8&preview=newtab&linkCode=kpe&ref_=kip_embed_taf_preview_AMQ7P5B4GZS24YCRCFS5

Sharing is Caring

🎉 Enjoying the newsletter?

If you’re finding value in this free newsletter, I invite you to share it! I’ll make it easy for you. Post the following on LinkedIn:

📧  If you don’t want to share on socials, reply directly to this email to let me know what you’re loving about the newsletter so I can continue to make it better!

Learn

👨‍🏫 [Story or Principle]

My last post titled “Stop Starting, Stop Finishing” had an overwhelmingly positive reaction.

At one point in that post I invited readers to reply to me directly if they were interested in diving deeper. I received way more responses than anticipated!

So here we go, a follow up to “Stop Starting, Stop Finishing”.

But wait, are we talking about personal productivity? Or organizational productivity?

In this post, I’ll be focusing on general strategies without specific scope. The application of these strategies to personal scope or an organizational scope look very different. I’ll allow you, the reader, to apply these strategies to your own context.

In most of these sections I will simply tell stories from my past experience.

Let’s dive into some of my favorite strategies to manage WIP.

Overview: A 10,000ft Look

• Visualize Work: Build a source of truth with quantitative transparency for yourself and others so the true magnitude and breadth of work can be appreciated and planned for.

• Define a Clear “Definition of Done”: Understand what it means to be “done”, and in some cases determine what is “enough”.

• Regularly Review WIP and Backlog: Keep priorities fresh and aligned.

• Ruthless Prioritization (and deprioritization): As important as it is to say “yes” to some work, it’s crucial to say “no” to more work.

A Closer Look at the 4 Strategies

Visualize Work

I remember at time at ExxonMobil where our team steadily became overwhelmed.

When we started, the work was manageable in loosely formatted team conversations. But after 1 year, our team was completely under water. None of enjoyed our work any longer.

What happened?

Ultimately, we weren’t aligned on what work was in our backlog.

We were operating an internal web-based platform for text-based competitive intelligence analysis. Our customers were all internal: sales, traders, marketers, etc.

At first, our task was to merely operate the tool and ensure it was available. This gradually transitioned into high-level consultations. Unsurprisingly, this escalated to building customized solutions for various personas.

The problem is that our team wasn’t organized well enough to handle the variety of work that sneakily expanded. And to make matters worse, this work was basically invisible, randomly tracked across each team member.

We accidentally lived the backwards mantra of stop stopping, start starting. Very obviously unsustainable.

(I know! I know! This was bad!)

How did we fix this?

I was the most junior member of the team. Either despite that or in-spite of that, I was eager to solve this problem.

I was convinced that our team needed to operate under the guiding principles of Kanban. More specifically, we needed to visualize our workflows and actual requested work. Without doing that, it would be impossible to manage work.

With encouragement from my manager, I led our global team through a value stream mapping exercise to begin modeling the operations of our team.

With our value stream map visualized, we could more easily classify the types of work coming to our team. This led to us creating a Kanban Backlog with proper classification of work type.

Now pause and look at what we have:

1. We understand our team’s operating model

2. We understand the type of work coming to our team

3. We’re aligned on #1 and #2 with common language

4. We built a visual backlog of work that was understood

Suddenly, we reduced the amount of concurrent work. We could divide and conquer effectively. Customers were happier with better transparency. We were happy to objectively set expectations.

Most importantly, we felt that we were in the driver’s seat again.

All this was made possible because of visualizing work. It was especially powerful because we combined value stream mapping with a meaningful backlog of work.

Define a Clear “Definition of Done”

The worst race is the race with no finish line.

Visualizing work is great. But if that work doesn’t have a finish line, you can never finish it. Your WIP runs the risk of perpetually growing. There will be constant confusion when to move onto the next thing.

The definition of done has some standard rules when it applies to engineering work.

But this principle of defining “done” is applicable to any type of work that needs to be broken down into smaller, manageable chunks.

Defining the definition of “enough”

Sometimes it is useful to define the definition of “enough”.

I’ll give a personal example that is very much not software engineering related.

My grandpa (passed away several years ago) was a master wood worker. He could build anything. Not only that, but he could create beautiful artistic carvings. He had the skills of both form and function nailed down.

I remember working with him in shop as a young boy. I cherish those brief memories.

He inspired me to learn wood working.

The only problem is….time.

I’ve got 3 young kids to be with, a wonderful marriage to nurture, a busy career to grow, and local volunteering to be a part of.

I need to manage my WIP across all these areas of my life. Ambitions don’t quite line up with energy and time.

Now I’ve got some options given those conditions:

1. Give up

2. Delay any effort to learn wood working

3. Define what is “enough” for this season of life

It probably isn’t hard to guess which one I’ve landed on: #3, defining “enough”.

• This is too much: Learn all the wood working possible!

• This is enough: Learn how to whittle small animals and people.

By defining my current definition of “enough” (or a soft measure of “done”), I can manage my life’s WIP while also including this new hobby on a semi-regular basis.

Regularly Review WIP and Backlog

Managing WIP is not a one-and-one job.

Managing WIP is the art building artifacts and designing processes to regularly monitor the pulse of your WIP at regular intervals.

The concept of a sprint and commercial Agile doesn’t always work out well, but the principles behind a scrum sprint. Managing WIP was one of the original ideas behind having sprints for engineering teams in the first place.

Every two weeks check-in on the team WIP and strategic alignment. Reset. Calibrate. Move forward.

You can apply this at a personal level with a weekly check-in for yourself.

This is also commonly applied at an organizational level, with varying levels of success. Although quarterly planning is the common rhythm of a business, I’m actually a growing fan of the 6-week Cycle from Basecamp.

Ruthless Prioritization (and de-prioritization)

When I was at Twitter, I was dedicated to a subsidiary of the company called MoPub.

It was a small organization relative to the number of customers it was serving. The constant challenge with this organization, which consisted of about 7 engineering teams and about 4 product managers, was slow throughput.

It seemed like we could never deliver fast enough.

Of course we could hire more to attempt an increase in shipping speed, but that doesn’t always work and it shouldn’t be the first answer.

My role as a TPM was to partner with the Engineering Director and Product Director to figure out how we can operate better and deliver faster.

After interviewing all the Engineering Managers and Product Managers (and most of the IC Engineers), it became obvious that there was a problem with prioritization and managing WIP.

Strategic Prioritization was a fairly overcomplicated process of scoring multiple ambiguous factors. (The spreadsheet would intimidate even the most senior Product Managers).

The process of prioritization was heavy. By the end of it, the teams didn’t feel any more confident because it was rare that anything was ever strictly moved to the “no” list. Instead, it was just given a lower score.

All the teams felt like they were chasing 20 different priorities at a time, with insufficient time to deliver on any of them.

What did we end up doing to fix this problem?

Product. Their goal: simplify.

The Product organization dove deeper on strategic prioritization methods to give engineering better clarity on our biggest and best opportunities.

We shifted from a heavy, overcomplicated process to a straight forward stack-rank based on cost of delay.

Engineering. Their goal: say no with quantitative data.

The next step was for engineering to pick up this list and run it through a hard capacity check. Across all teams and potential dependent teams, capacity was evaluated for these strategic priorities.

Eventually, engineering produced initiatives that were above-the-line vs below-the-line.

Said another way, a yes-list and a no-list.

The yes-list was always shorter than the no-list. The engineering and product organizations got better at saying no, which is more than half the battle when managing WIP.

If you’re able to ruthlessly prioritize (and deprioritize) in a unified way, that can be an organizational superpower.

TLDR

This follow-up to “Stop Starting, Start Finishing” introduces practical strategies to manage WIP, applicable at both personal and organizational levels.

Key strategies include visualizing work for clarity, defining a clear “definition of done,” regularly reviewing WIP and backlog, and ruthlessly prioritizing (and deprioritizing) tasks.

This post shares personal stories to highlight how these principles have driven productivity improvements in both personal projects and large organizations.

Mastering WIP management is the key to unlocking consistent progress and preventing the chaos of multitasking from derailing success.

A word from our sponsor…

Receive Honest News Today

Join over 4 million Americans who start their day with 1440 – your daily digest for unbiased, fact-centric news. From politics to sports, we cover it all by analyzing over 100 sources. Our concise, 5-minute read lands in your inbox each morning at no cost. Experience news without the noise; let 1440 help you make up your own mind. Sign up now and invite your friends and family to be part of the informed.

Sign up today!

Event

🎉 Speaking at the TPM Summit in October!

Excited to come back to share some thoughts on the intersection of Generative AI Prompting and TPM life! Get your tickets here.

If you’re attending, reply to this email and let me know so we can make sure to meet up! Connecting with people is a major reason why I started this newsletter in the first place.

TPM Events, a nonprofit corporation on LinkedIn: #ai #tpm #ai #tpmsummit

Speaker highlight for James Dayhuff! James is back with us for the 2nd annual TPM Summit to talk to us about Prompt Engineering with #AI!

www.linkedin.com/posts/tpm-events-npc_ai-tpm-ai-activity-7237112196898390016-jlT2?utm_source=share&utm_medium=member_desktop

Learn

👨‍🏫 Stop Starting, Start Finishing

Back in 2016 when I was working at ExxonMobil as an automation engineer, my mind was heavy with all the things I felt that I should be doing.

I was trying to “boil the ocean” (ie; do so many things all at once that I was not making much progress with any of it.)

It wasn’t working.

As a young professional, I was grappling with how to manage my time effectively in this large corporate setting. I couldn’t get a good handle on my work load.

Then, I walked by an open door with a whiteboard inside. It took only a glance to read what was on the board.

“STOP STARTING, START FINISHING.”

Up to this point, I was loosely familiar with Agile principles across both popular flavors: Kanban and Scrum. However, this specific phrase hit home for me.

“Stop starting and start finishing” is all about managing your WIP, or your work-in-progress, a key element of Kanban philosophy.

I still recall stopping at that door-frame and staring at the phrase. It was like someone grabbed a 2×4 board and smacked me in the face. This phrase unlocked the obvious for me: “Ohhhhhhh, I’m trying to do too much all at once and I’m not finishing anything!”

I went back to my desk and started to prioritize “ruthlessly”.

From that point on, this phrase has become somewhat of a motto of mine in how I work.

Manage your WIP

Let’s talk Kanban 101.

Manage your WIP. That’s what productivity is all about.

The moment you begin to take on too many distinctly different activities, your impact and productivity immediately suffer.

If you take on 10 projects, you can only move each of them 1 inch.

Conversely, if you apply that same fixed capacity of time and energy to only 2 projects, the results are wildly different.

Of course, this is an over-generalization. But let’s look at a specific example while I was a TPM at Twitter in 2021.

Cutting down on initiatives @ Twitter

This idea of managing your WIP applies both to your personal time management but also to large organizations.

How many times have you worked in a company where it seems the company leaders has expectations to deliver on at least 100 different initiatives?

While I was working at Twitter (pre-Elon), this was our situation. Everyone was spread too thin.

It became such an issue that the leadership team put together a stack-ranked Jira view of every major initiative going on.

No joke, there were over 200 in that list.

This was an obvious signal that we were attempting to accomplish too much all at once given our capacity constraints.

Ruthless prioritization took place.

There was a shortened list of the top 10 strategic initiatives. These got priority access to engineering, product, and design capacity.

What was my role in all this?

My role was to make sure the business impact of my initiatives was well understood and appreciated.

A couple of my initiatives got deprioritized, except one.

I was driving a data privacy move to help us remediate bad tech debt which was causing chaos and ensuring we were strongly positioned for the future of data privacy. This turned out to be strategic initiative #5 in that list of 10.

This was an immense help to get properly staffed for completion.

(Note: limiting strategic WIP did not result in layoffs in this case, even though it is one conclusion someone could jump to. Rather, teams were reallocated to more important initiatives. ie: fuel was added to existing efforts to increase momentum.)

Do less, better.

So here’s your invitation to improve as a TPM: do less, better.

• Lead your program by managing WIP to ensure progress

• Influence your company strategy with healthy practices of managing WIP

• Work with your manager to make sure your personal workload has a health amount of managed WIP

You want to have greater impact? do less, better.

You want to see more progress? do less, better.

You want to get some breathing room for your own workload? do less, better.

This is not an easy exercise, but it is possible and the benefits are immense.

But how??

For the sake of the length of this post, we’re stopping here for today.

📧 If you’re interested in some strategies around managing your WIP, reply to this email to let me know! I’ve got some personal favorite strategies.

Alternatively, just reply to say hello, I always enjoy hearing from fellow TPMs!

Event

🎉 TPM Summit 2024 (in person and remote!)

I’m excited to be attending the conference again this year, I want to see you there.

This year’s keynote is with Jen Krieger, VP of Engineering Operations at Github. She was on a panel last year and it’ll be amazing to give her more space to speak.

Come join! Either remote or in-person in Mountain View, CA on October 4, 2024.

(note: this is not sponsored, I’m just excited to go!)

Resources

📚 Supercharge your TPM Resume (Aug 27 - Sept 6!)

I’ve worked with and met tons of Technical Program Managers ever since I launched this newsletter nearly a year ago.

A consistent challenge is landing a job, especially among the current job market. I can’t solve all those problems, but I can lend a hand.

For the next two weeks, I’m here to help you supercharge your TPM resume. Applications are open from August 27 to September 6.

TPM Resume Review

Supercharge your TPM Resume with a TPM resume review for TPM’s, by a TPM.

james-dayhuff-s-school.teachable.com/p/tpm-resume-review

What does this look like?

• 📥 Submit. Submit a request on this page to get the ball rolling.

• 👀 Review. I review each the submission to make sure we’re a good fit.

  • (For example, if someone is applying to a TPM Manager role, I don’t have much to offer you!)

• ✅ If we’re aligned, you’ll get an email on next steps to submit your resume.

• 💵 You purchase the TPM Resume Review service for $30 and submit your resume!

  • (Usually these services cost between $100 - $300, but my goal is mostly to cover my costs for this newsletter right now!)

• 📄 I dig into your resume and provide a TPM Craft Resume Scorecard, which will give you laser-targeted improvements to your resume.

  • (I won’t be editing your resume directly nor writing a new one for you)

Reminder: I only have this open until September 6! After that, submissions will be closed! (Why? I’m very intentional about managing balance in my life. A short window like this helps me manage my WIP 😏)

Learn

👨‍🏫 If you struggle to explain your role as a TPM, read this.

Before I became a Technical Program Manager, I was already doing the work of a Technical Program Manager. I didn’t even realize it.

I was working at ExxonMobil in the very clearly defined role (not) of Advanced Systems Analyst II. The longer I was at that company, the more I realized that my strengths didn’t fit neatly into any single defined or respected role at ExxonMobil.

I felt like I had all these great strengths, but couldn’t effectively map them to the career ladder. It felt like the things I was good at didn’t matter.

This was a problem.

It was impossible for me to cast a vision of my career path at the company. This was one of the big reasons I left ExxonMobil.

After a year-long job hunt, I discovered the TPM role and felt like I had struck gold when I was offered a position at Twitter.

I felt seen. I felt understood.

For the first time, I felt like I was in a role that recognized my strengths.

Although Twitter recognized the TPM role, I realized that the role was still not well understood. Role expectations kept shifting person to person.

Also, I couldn’t clearly explain my role as a TPM either.

Why is it so hard to define a TPM??

Explaining what a TPM does is like trying to describe a Rube Goldberg machine to someone who’s never seen one—there’s a lot of moving parts, and the end result is important, but good luck summarizing it in a few words.

(Don’t know what a Rube Goldberg machine is? Enjoy watching this one featured in a music video by OK go, This Too Shall Pass)

The role is a blend of project manager, translator, negotiator, and firefighter, all rolled into one. Some days you even feel like therapist. It’s hard to pin down because you’re doing a bit of everything—keeping projects on track, aligning teams that see the world differently, and solving problems that no one else even sees coming.

In the end, it’s the kind of job where people know you’re essential, even if they’re not entirely sure what you do.

Focus on the outcomes

If you try describe your role as a TPM based on the activities you do, confusion follows. There’s too much variety of activity.

But what if you could explain all of your activities as a TPM by finding a few common threads in all of those activities. Sound promising?

Your role as a TPM is to drive outcomes. Explaining your role is no different. Focus on outcomes.

I’m not talking about outcomes of the program specifically, that’ll change too much.

I’m talking about the outcomes on program execution with you involved.

A framework to explain your role as a TPM: Driving CAPE

As a TPM, you don’t just oversee; you actively propel the project forward by focusing on what truly matters. You drive outcomes.

Much like the chaotic and unpredictable nature of city driving (mainly the other drivers), project execution is a wild landscape with extremely limited predictability.

You’re the driver on that road of project execution.

You drive things so that you can influence the probability of program outcome success.

But what things? You Drive CAPE.

Clarity.

Alignment.

Progress.

Efficiency.

Driving Clarity.

Clarity is where it starts. With no clarity, there is no alignment and no real progress. Think of it like the “top funnel” of successful execution. Some examples:

• Driving clarity around strategic intent. Do we really know why we are doing X or Y?

• Driving clarity on product requirements. Do we really understand the definition of done?

• Driving clarity on measurement. Do we know how to measure success?

• Drive clarity on risk severity. Do we truly understand risk X and Y and what it means for the business or program?

• And so on…

But it can’t stop there. Clarity doesn’t inherently mean everyone has the same level of clarity.

Driving Alignment.

We have clarity. That’s good. But does everyone else have that same level of clarity?

• Drive alignment on the foundational clarity from the top of the funnel. Do we share the vision and what it means to be successful?

• Drive alignment on timing of cross-functional needs. Have we aligned the timing of delivery across all teams?

• Drive alignment on which biggest issues need the most focus. Are we collectively attacking the biggest risks?

• And so on…

But what good is clarity and alignment if we aren’t doing anything about it? Progress is where it begins to count.

Driving Progress.

We have clarity and alignment—great. But are we turning that into action?

• Drive progress with actionable tickets. Does the work have proper, approved owners?

• Drive progress on project health. Are we moving away from an at-risk state and towards an on-track state?

• Drive actual outcomes. Are we launching or landing the features to the right customers at the right time?

• And so on…

Progress may be happening, but how long can we keep operating like this?

Driving Efficiency.

We have clarity. We have alignment. We’re making progress. But are we doing it in a way that is efficient and sustainable? Or are we breaking our backs with a one-time effort that is never possible again?

• Challenge the status quo when friction unnecessarily slows us down. Are we really operating in the best way possible?

• Drive standardization where it makes sense. Can we all dance the same dance to get things done?

• Drive metrics on process effectiveness. How well do we really measure our operations?

• and so on…

Elevator Pitch

In short, ‘Driving CAPE’ is how you frame your role as a TPM. It’s a simple, effective way to explain what you do.

Take your pick of elevator pitch flavors for the next time you need to succinctly explain your role as a TPM (whether you have the title of TPM or not):

So the next time someone asks what you do, remember: you drive CAPE, and that makes all the difference.

A word from today’s Sponsor.

The Daily Newsletter for Intellectually Curious Readers

• We scour 100+ sources daily

• Read by CEOs, scientists, business owners and more

• 3.5 million subscribers

Sign up today!

People

🤝 Priyanka Shinde, up-leveling TPM leaders

I had the privilege to meet Priyanka at the 2023 TPM Summit back stage before we both gave our presentations. She is truly a great person.

In her own words: 𝗜 𝗮𝗺 𝗮𝗻 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝘃𝗲 𝗹𝗲𝗮𝗱𝗲𝗿𝘀𝗵𝗶𝗽 𝗰𝗼𝗮𝗰𝗵 - 𝗜 𝗲𝗻𝗮𝗯𝗹𝗲 𝘁𝗲𝗰𝗵 𝗹𝗲𝗮𝗱𝗲𝗿𝘀 𝗮𝗻𝗱 𝘀𝘁𝗮𝗿𝘁𝘂𝗽 𝗳𝗼𝘂𝗻𝗱𝗲𝗿𝘀 𝗯𝘂𝗶𝗹𝗱 𝘄𝗼𝗿𝗹𝗱-𝗰𝗹𝗮𝘀𝘀 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝘀 & 𝘁𝗲𝗮𝗺𝘀 𝘁𝗵𝗿𝗼𝘂𝗴𝗵 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗰 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝘃𝗲 𝗹𝗲𝗮𝗱𝗲𝗿𝘀𝗵𝗶𝗽 𝗰𝗼𝗮𝗰𝗵𝗶𝗻𝗴.

If you’re looking for a person dedicated to helping TPM’s grow, definitely connect with her.

(in the section below, there is a special offer that will literally save you $1000)

Priyanka Shinde on LinkedIn

I never thought I would walk away from $1M hard cash! 💰 The morning I made that decision... I felt joyful🙂 I felt hopeful🤩 I felt powerful💪 Today, I am…

www.linkedin.com/posts/priyankash_executivecoach-entrepreneur-techjob-activity-7217539453874003968-LVyZ?utm_source=share&utm_medium=member_desktop

Resources

📚 UNLEASH Your Leadership Power

I would like to share an incredible opportunity for Women in Tech Product and Program Management.

The "UNLEASH Your Leadership Power" group coaching and mentorship program designed specifically to help achieve professional and personal growth, and get to the next level of success.

With this one-of-a-kind program you get mentorship, personalized coaching, and a strong community - all in one place!

Enrollment is now open:

• 📆 Program Start Date: August 23, 2024

• ⏳ Duration: 12 weeks

• 🎯 Objective: Elevate your career and turn your ambitious goals into reality

• 💻 Format: 7-Step framework + weekly live group sessions every Wednesday. Each week will have a separate theme.

• 🛠 Materials: Videos, Templates and Assessments

This program is being offered by Priyanka Shinde, a certified executive leadership coach and seasoned Silicon Valley Tech leader with 20+ years of experience across engineering, product, and program management.

Priyanka Shinde is also a published author of the book "The Art of Strategic Execution - Finding Success in Technical Program Management".

BONUS: Get 3-month TPM Academy Membership for FREE when you sign up for the one-time payment option with the above code.

Feel free to email Priyanka [priyanka@thepriyankashinde.com] to learn more about the program.

Learn

👨‍🏫 A Practical Guide to 6 API Patterns

Let’s start with the classic question: How technical does a TPM need to be?

There are many, many ways to answer that question. But regardless of which answer you’re given, understanding APIs is a fundamental slice of system design that establishes your Technical Versatility.

Modern system design without APIs?

Without APIs, system design would be chaotic and inefficient. It would essentially cease to exist!

Each application would need custom code to communicate with every other application. This lack of standardization would lead to a tangled web of integrations, making maintenance and scalability nearly impossible. Can you imagine?? Every single piece of common and popular software we know today wouldn’t exist.

To be honest, it is quite impossible to consider our modern world without APIs.

(Take a moment to say thank you to your APIs today!)

The Top 6 API Patterns

When I first learned about APIs, this was the analogy I was introduced to:

This analogy is fantastic! But, as your understanding of system design progresses, it falls short of capturing the nuances of the many API patterns.

Let’s walk through the patterns from a chronological perspective, starting in the late 90’s.

1998: SOAP (Simple Object Access Protocol)

Rewind to 1998, right before the dot-com bubble. SOAP is one of the oldest and most established API protocols, designed for secure and reliable communication.

• A helpful analogy: Imagine a mail carrier (SOAP) who delivers letters (messages) between houses (applications). The mail carrier has to make sure every letter has a stamp, address, and return address in the correct places, SOAP makes sure that every message follows a strict format. This ensures that the messages are understood correctly by the receiving application.

• When is it used: SOAP remains vital in secure, transaction-heavy environments like online banking and enterprise services.

• Pros: Strong security, standardized format, reliable.

• Cons: Can be complex and slow, uses a lot of bandwidth.

2000: REST (Representational State Transfer)

Now let’s go right to the turn of the century. The year is 2000. The dot-com bubble is upon us! The web is exploding. We need a better way of managing web communications. REST is the most widely used API pattern due to its simplicity and scalability.

• A helpful analogy: When you order pizza online, you don’t need to know how the pizza is made or how it gets to you. You just click buttons to choose what you want. Similarly, with REST, you make requests to a server and get back exactly what you asked for, like a pizza being delivered to your house.

• When is it used: You probably use a REST API every day. Websites, mobile applications such as social media platforms and e-commerce sites all use REST to some extent.

• Pros: Easy to use, lightweight, widely supported

• Cons: Limited to HTTP, stateless nature can be a drawback in some scenarios.

I spent a lot of time with REST APIs when I was an API engineer at ExxonMobil. They were a huge enabler to faster business operations and collaboration across data analyst groups.

2007: Webhooks

As web and mobile apps required real-time communications, Webhooks were introduced. The term was coined in 2007. These are event-driven mechanisms that have helped establish basic things we’re familiar with today, like simple notifications.

• A helpful analogy: An alarm clock goes off at the right time to wake you up without you needing to watch the clock. Similarly, a Webhook sends a notification to your application whenever a specific event happens, so you don’t need to keep checking if the event has occurred.

• When is it used: Webhooks trigger specific actions across different systems: event-driven services like payment processing notifications or continuous integration/continuous deployment (CI/CD) pipelines.

• Pros: Simple, real-time notifications, no need for constant polling.

• Cons: Can be less secure, depends on external services.

2011: Web Socket

WebSockets enable real-time, bi-directional communication between a client and server over a single, long-lived connection. They are fundamental to fast communication across systems.

• A helpful analogy: Imagine two friends on a phone call, where they can talk to each other instantly and continuously without hanging up. They can constantly talk with and respond to one another. WebSocket keeps a constant connection open between two applications so they can send messages back and forth instantly, just like friends chatting on the phone.

• When is it used: Event-driven services like payment processing notifications. Continuous integration/continuous deployment (CI/CD) pipelines.

• Pros: Real-time, bi-directional communication, low latency.

• Cons: Not suitable for all types of applications, complexity in scaling.

February 2015: gRPC

Moving into 2015, modern system design really picks up speed in maturing. The modern, large scale, distributed systems demand something more efficient.

GRPC was developed by Google and released publicly in February 2015. They are designed for high-performance, scalable API communication, particularly useful in microservices architectures. I personally didn’t have much exposure to these until my time at Twitter with the vast distributed, scalable systems we were running there for the social network and the ad-stack.

• A helpful analogy: Imagine gRPC as a dedicated phone line between two offices with operators who speak the same specialized language (Protocol Buffers). This setup allows them to communicate faster and more efficiently than using regular mail (HTTP REST calls), where letters must be written, sent, received, and read, often leading to delays and misunderstandings.

• When is it used: Microservices architectures, real-time communication services, and systems requiring efficient, high-performance data exchange.

• Pros: High performance, supports multiple languages, efficient

• Cons: More complex setup, extra overhead for smaller apps, strict contract

July 2015: GraphQL

Around the same time gRPC was introduced, GraphQL was released and it rapidly gained traction, especially among developers dealing with complex data requirements. It is often considered the 2nd most popular (after REST) API pattern. Companies like Facebook, GitHub, and Airbnb have adopted GraphQL.

• A helpful analogy: Imagine a buffet (GraphQL) where you can pick exactly what you want on your plate instead of ordering a fixed menu. You don’t have to take a full meal; you can just take the foods you like. With GraphQL, instead of getting all the data you might not need, you can request just the specific pieces of data you want, saving time and making things more efficient.

• When is it used: Applications needing specific data from large datasets or real-time applications like social media feeds.

• Pros: Flexible data retrieval, single endpoint, strongly typed schema

• Cons: Security concerns, potential overuse of resources (ie easy to allow excessive queries), steeper learning curve

Recap

Whew. That was a lot.

For me, it’s interesting to look at the chronological development of these patterns rather than a static list of patterns. By looking through the lens of time, you can start to see a shadow of how system design in general has evolved.

Now a quick summary:

• SOAP (Simple Object Access Protocol) - Introduced in 1998, SOAP is one of the oldest and most established API protocols, designed for secure and reliable communication.

• REST (Representational State Transfer) - Developed in 2000, REST has become the most widely used API pattern due to its simplicity and scalability.

• Webhook - The name was officially coined in 2007 but developed in the few years prior, Webhooks enable event-driven automated tiggers happening in real time.

• WebSocket - Introduced in 2011, WebSockets enable real-time, bi-directional communication between a client and server over a single, long-lived connection.

• gRPC (gRPC Remote Procedure Call) - Released in 2015 by Google, gRPC is designed for high-performance, scalable API communication, particularly useful in microservices architectures.

• GraphQL - Introduced by Facebook in 2015, GraphQL is a major API pattern known for its flexibility in querying data.

A note on Technical Versatility…

I’ll be honest, I learned a thing or two preparing this post. For example, I don’t have much experience with Webhooks. But after writing this, I’m better equipped to talk through Webhooks scenarios.

Pro-tip: The most important part of your Technical Versatility is your willingness and eagerness to learn.

A word from today’s Sponsor.

Simple Skincare for Smart Investors

You're already investing your money wisely, so why not invest in yourself too? Tiege Hanley’s Bare Minimum Routine offers an affordable, high-quality solution for men who want to look and feel their best. For only $9, you get a simple, effective skincare system that includes a face wash and an AM moisturizer with SPF to keep your face hydrated and protected all day long.

Do the bare minimum, order your set today.

People

🤝 Naveen Chandrawanshi, Top Programming Voice

I’ll be honest, I don’t know Naveen personally. But his posts are highly visual and anchored on system design. I often enjoy how he visualizes complex topics. Below is one of this posts I found insightful!

Naveen chandrawanshi: Mastering System Design: Your Ultimate Template:

Designing robust, scalable systems is a crucial skill for any software engineer. Here’s a master template to…

www.linkedin.com/feed/update/urn:li:activity:7211702267907850240

Resources

📚 The Pragmatic Engineer

I don’t know if this newsletter even needs an introduction. It has grown so rapidly in popularity in the past few years, it’s hard to believe.

Gergely Orosz is a fantastic writer and has created an incredibly high-value newsletter for anyone in the tech industry. There are some free posts, but most paid posts.

A couple years ago I contributed to one of his articles focused on the role of Technical Program Managers. Check it out!

What TPMs Do and What Software Engineers Can Learn From Them

A deep dive with five Technical Program Managers (TPM) on what the role is, how it evolved, and how engineers and managers can benefit from working with TPMs.

newsletter.pragmaticengineer.com/p/what-tpms-do?utm_source=publication-search

Learn

👨‍🏫 The 5 Levels of Leadership

The time I failed as a TPM leader

Let me tell you about a time I failed to lead. Hang in there with me, this is painful to write!

I had recently left ExxonMobil and joined Twitter. (I don’t know if I could’ve found two companies more polar opposite!)

ExxonMobil leaned heavily into a commercial-grade Agile implementation, fitting our people and organization into strict frameworks. I carried this mindset to Twitter, aiming to drive massive changes.

I did extensive research, created the world’s greatest slide deck, and… it was a complete flop.

What was supposed to be a systemic change in how we operated, turned out to be a puff of unnoticeable smoke.

Why? I failed to lead. I relied too heavily on my title as a TPM, expected people to follow, and worked in a vacuum.

I didn’t quite understand some fundamental truths about leadership and building momentum across stakeholders. Luckily, I learned from this experience and am a better TPM because of it.

Several of these missed fundamental leadership truths are effectively expressed in Maxwell’s leadership framework.

Maxwell’s Framework

John Maxwell is a renowned expert in leadership development. With over 30 million books sold and decades of experience, he has influenced leaders worldwide.

This framework is all about influential leadership.

Rewind to the 1970’s

Initially, in the 1970s, Maxwell branded this as “The 5 Levels of Influence”. Why Influence and not Leadership? Well, management and and leadership were fairly synonymous in the 1970’s.

However, as the terms leadership and management began to find their own nomenclature homes, his framework evolved into “The 5 Levels of Leadership”, based on the principles of influence.

Moving beyond titles

This framework is about moving beyond titles: to build relationships, achieve results, develop others, and ultimately inspire.

There are 5 levels of leadership maturation, according to Maxwell.

1. Level 1, Position: Leadership is associated with a title. People follow you because they have to. This is the weakest type of leadership.

2. Level 2, Permission: Leadership is built on relationships. People follow you because they want to.

3. Level 3, Production: Leadership is demonstrated by results. People follow you because of what you have done for the organization.

4. Level 4, People Development: Leadership is about growing others. People follow you because of what you have done for them personally.

5. Level 5, Pinnacle: Leadership is about respect and admiration. People follow you because of who you are and what you represent.

In my previous story, my mind was stuck at Level 1. I didn’t build the relationships (Level 2) or demonstrate results (Level 3) needed to influence and lead effectively at Twitter. (It is embarrassing to even admit this lack of leadership awareness!)

Source: Vantage Circle

Applying Maxwell’s Framework to TPM’s

Now before we go on, I want to call out the obvious trouble with any leadership “advice”….The trouble with any leadership framework or material is that it quickly becomes too generalized and therefore lacks actionability and applicability.

So to avoid that trouble, let’s see how we can apply these levels of leadership directly to the world of being a TPM!

Level 1: Position

Position-based leadership relies on the rights granted by the title. People follow you because they have to.

At this level, a TPM is new to the role and relies on their title to get things done. People follow their lead because they must, not because they want to.

Example: a TPM is assigned to drive a compliance-related program for broad adoption of a new process, mandated from an executive. Sure, people will follow that TPM lead but most of it is because of their position to drive compliance as a TPM.

At this level, people give you the least amount of effort and input.

Level 2: Permission

Permission-based leadership is about relationships. People follow you because they want to. The leader prioritizes people over process.

Here, you as a TPM begins to build relationships with people on various teams. People follow because they like and trust you. This is achieved through effective communication, showing empathy, and being approachable. By listening to team members and valuing their input, you can create a supportive and collaborative environment.

Example: a TPM may be assigned to drive an initiative, and the TPM begins not by setting milestones of execution but rather by building relationships with the most critical contributors. The TPM understands different peoples views, challenges, hopes, and more. This TPM knows that the quality of the program relies on the quality of relationships.

People begin to give you more earnest and proactive effort.

Pro-tip: When you get a new program set on your plate, one of your priorities should be to shift from Level 1 to Level 2 as quickly as possible.

Level 3: Production

Production-based leadership is about results. People follow you because of what you have done for the organization.

At this stage, you’re recognized for your ability to deliver results. People follow because of what the TPM has accomplished. Your track record of success builds credibility and trust. In short, results establish credibility.

Example: a TPM has had at least one major win within the company. This win is significant in business value and scale. These results associated with an important initiative establish credibility, boosting trust in the TPM.

(This is a beginnings of a high-impact TPM with results to prove it.)

Level 4: People Development

People-development-driven leadership is about leveling up those around you. The tide rises wherever you are. People follow you because of what you have done for them personally.

This level is about developing the skills and capabilities of the team. You invest time in mentoring and coaching, helping team members grow in their roles. You build community. You drive best practices. You stand as an example of what a TPM can deliver. By empowering others, you enhances overall performance and foster a culture of continuous improvement.

Example: an IC TPM might begin to establish an internal TPM community to foster best practices, mentoring, and leveling-up the whole org. The TPM contributes to internal or external TPM best practice documentation. Additionally, but not exclusively, a TPM may move into a TPM management role.

Level 5: Pinnacle

The pinnacle is the highest level of leadership, it is a conglomeration of putting people first, building credibility through results, developing people, and sustaining this over time. People follow you because of who you are and what you represent. These are the all-stars of any craft or profession.

At the pinnacle, a TPM is respected and admired for their leadership. People follow because of who they are and what they represent. The TPM’s influence extends beyond their immediate team, impacting the broader organization and industry. Their leadership legacy is built on integrity, vision, and the ability to inspire others.

Example: a TPM’s opinion is valued at all levels of an organization and company. This TPM has created a lasting, positive legacy of impact on others and anything they are associated with.

So what?

Growing as a leader is foundational in your TPM role.

The greatest leaders lift those around them. Using Maxwell’s framework helps us paint a path to become that type of leader.

The next obvious question is…how do I grow as a leader? How do I move throughout these levels? If you want to hear more on that, reply to this email and let me know! I’m always trying to gauge which content is most helpful.

A word from today’s Sponsor.

Learn how to make AI work for you.

AI breakthroughs happen every day. But where do you learn to actually apply the tech to your work? Join The Rundown — the world’s largest AI newsletter read by over 600,000 early adopters staying ahead of the curve.

1. The Rundown’s expert research team spends all day learning what’s new in AI

2. They send you daily emails on impactful AI tools and how to apply it

3. You learn how to become 2x more productive by leveraging AI

Subscribe with one click.

People

🤝 Simon Sinek, a modern day voice of leadership

Simon Sinek is well-known for many of his books on leadership. Two of my favorites:

• Start with Why

• Leaders Eat Last

In his own words (or the words of his editor?):

Resources

📚 The book, 5 levels of leadership!

Note: there is no sponsorship or anything. It’s just a good book.

The 5 Levels of Leadership: Proven Steps to Maximize Your Leadership

www.goodreads.com/book/show/11225698-the-5-levels-of-leadership?from_search=true&from_srp=true&qid=ZXPYs0lMhq&rank=1