Learn

👨‍🏫 Are you falling into the 3 common TPM biases?

You’re in the thick of it. You feel the weight of expectations to drive the large, complex program to success.

Success is the goal. But I’m here with a far more pessimistic story today.

I’m here to tell you why you’ll fail…and what you can do about it.

There are 3 common biases which will be major pitfalls unless you mindfully combat them.

(If you know of other TPM biases that I don’t cover below, feel free to reply to this email and tell me about your experience with TPM biases!)

The Jira Bias

TLDR: You’re more focused on measuring outputs (ie closed epics / tickets) rather than measuring achievement of business outcomes.

Jira, while a powerful tool for tracking project progress, can sometimes lead TPMs to focus excessively on ticking boxes and closing tasks or epics. This "Jira Bias" shifts the emphasis from meaningful business outcomes to merely completing set tasks.

It’s crucial for TPMs to remember that the ultimate goal is not just to move tickets to the "done" column but to ensure that each completed task significantly contributes to the broader business objectives.

Failing to do connect outputs to outcomes almost certainly ensures that the impact of the program will miss the mark.

One of the major initiatives I was driving at HashiCorp fell victim to this. We kicked off the program with Jira representing many reasonable and important outputs.

As time went on, however, it quickly became apparent that the business outcomes weren’t well mapped in Jira. We adjusted by creating key artifacts to represent outcomes rather than outputs and linked everything to the outcome artifacts.

Overcoming Jira Bias

• Set Clear Outcome Goals: Beyond task completion, define what success looks like in terms of business outcomes for each epic or project.

• Represent Outcomes in Jira: Outputs are easily represented in Jira. Make sure outcomes are also represented and linked to the outputs that make this outcomes a reality.

• Regular Outcome Reviews: Schedule periodic reviews to ensure tasks and epics are directly contributing to the desired outcomes.

• Stakeholder Feedback: Involve stakeholders in reviewing progress, focusing on outcome relevance rather than just task completion.

• Balance Metrics: Alongside tracking task completion rates, incorporate metrics that measure the impact on business outcomes.

The Planning Bias

TLDR: You get a false sense of confidence after an initial plan has been made, and fail to adjust as time goes on.

Planning is fundamental in project management, but an over reliance on the initial plan without room for adjustments can be detrimental.

You know the saying by Mike Tyson: “Everyone has a plan until they get punched in the face”. And you know what? Every major project or program gets “punched in the face” at some point. Are you ready to adapt?

To add to that, one of the more respected former US presidents, Dwight D. Eisenhower, once said: “Plans are nothing. Planning is everything.”

If its your first time hearing that quote, it may seem contradictory. But hang in there with me.

The act of planning is immensely powerful. It is the opportunity to pull people together, to hash out details, to ask hard questions, to pressure test scope against timeline and resources through rich dialogue.

The output of that is a plan. But that plan isn’t a living breathing thing able to independently adapt to the real world (maybe AI will get us there some day…).

You need to rely on planning, not the plan.

Adaptive planning, a core principle of business agility, encourages frequent reassessments of plans and goals, ensuring that the project remains aligned with business needs and can respond to unexpected challenges or opportunities.

Overcoming Planning Bias

• Embrace Adaptive Planning: Make regular, scheduled plan reassessments part of your project management process.

• Feedback Loops: Implement short feedback loops with your team and stakeholders to gather insights and adjust plans accordingly.

• Scenario Planning: Prepare for different scenarios by thinking ahead about possible changes and how to adapt to them.

• Celebrate Flexibility: Recognize and reward the ability to adapt and change plans as a strength, not a deviation from the norm.

The Context Bias

TLDR: You assume all program contributors maintain the same level of big picture context as you from day-to-day.

TPMs, deeply entrenched in the details of their programs, often operate with a wealth of context that others may not share. This "Context Bias" can lead to misunderstandings, misaligned expectations, and inefficient communication.

This actually highlights how unique the TPM role is as well. Rarely do any other roles have access to as much context as a TPM does.

Its very, very easy for an engineering team, who is working on 4 competing priorities, to lose context as they continue to drill down into the details of implementation.

This risk? Engineering solution design without proper context can likely result in tech debt or an ineffective solution to be re-worked later.

I ran into this challenge as I watched recurring, large-scale testing struggle to reach the outcomes. As I dug into the root cause with the key engineers, it became apparent that it was a context problem. They didn’t have enough clarity on what they were aiming for.

Sounds so simple that you may wonder how that can even happen. But it happens quicker than you expect.

Overcoming Context Bias

• Simplify Communication: Use clear, jargon-free language tailored to your audience’s level of expertise.

• Consistent Communication: Provide regular, accessible updates that build a shared understanding of the program’s status and direction.

• Facilitate Dialogue: Encourage questions and discussions to ensure all team members and stakeholders feel comfortable sharing their perspectives. Ask the question: who needs more context on the WHY?

• Documentation: Maintain up-to-date documentation that is easily accessible to all team members, serving as a single source of truth.

People

🤝 A voice of Engineering Leadership

I recently discovered Nicola Ballotta in his post evangelizing the high impact of a Technical Program Manager.

He is not a TPM. He is an engineering Director who “gets” the TPM role. Its good to have advocates in our corner! He consistently posts high quality content. Check out his TPM post below: