Exploring what makes a TPM thrive

This topic comes up in every interview I’ve conducted for the TPM position. I’ve put some thought into everything that a TPM does. The points that I’m going to discuss are not qualities specific to a company, team, or variation on the TPM role, but they are transferable from one position to the next.

Keeping forward momentum

For a TPM to thrive, their focus needs to be on moving the project forward and unblocking their team to get things done. This may sound like a cliché, as though you are reading it from a job description, but it is resoundingly true. Our innate drive to solve roadblocks, build a plan, mitigate risk, and drive toward deadlines are key to a project’s success. It is important to keep momentum on a project because, without it, we risk losing progress and need to start over. Context switching is often to blame here because, during the time a project is blocked, the individuals working on it may move on to other priorities or lose context in the downtime. This necessitates more time to ramp back up once a project is ready to move forward. It is in our best interests to resolve issues quickly in order to keep engagement, focus, and motivation.

This driving motivation is a trait that isn’t always present in roles that are adjacent to the TPM, such as the development manager and the product manager. This is because the primary function of those roles is not focused on project or program delivery like the TPM role is. A development manager’s main focus is their people and their service or area of ownership, and a product manager’s focus is their product. For the TPM, the focus is the project or program, which is where their drive and perspective are also focused. A blocker in a project blocks our main purpose, so it is extremely important to be aware of. This same blocker may be overshadowed by a performance review cycle for the development manager or by the product needs of the product manager.

Driving toward clarity

One of the most effective ways to keep forward momentum is to always drive toward clarity. The drive to clarify can come at any stage of a project or program. It’s very common to see this during the requirements analysis and planning phases, as clarification is a key outcome of analysis and is needed to ensure a complete plan. We are always driving towards clarity through clarifying requirements, clarifying scope, clarifying the communication strategies and important stakeholders, and even unblocking development work.

Every roadblock we encounter requires us to drive toward clarity. We ask about the problem, the people or systems involved, any proposed solutions, and paths to escalation. Then, we take all of this data and define the problem to ensure that our solution is fixing the right thing. This then allows us to work toward the right solution. Think of it as asserting your acceptance criteria for a development task to ensure that it has the right outcome.

One way in which we drive toward clarity utilizes the last critical trait to make a TPM thrive—the communication bridge. We’ll talk a lot about communication throughout this book, but this is a special form of communication that takes our technical background into account.

Communication bridges

Since we have a technical background, not only can we talk with our technical teams but also understand them! This is critical for our ability to understand the tasks it will take to complete a project and to push back on unrealistic estimates or provide feedback. This skill also allows us to explain the work that our developers are doing for other stakeholders. We can take highly technical information and transform it into language that a VP of marketing will easily understand.

This ability to translate from technical to non-technical works in reverse as well. In fact, we rely heavily on this early on in a project during requirement analysis. We take business requirements and translate them into functional specifications for our technical team.

We understand the business and their needs, and if required, we understand their knowledge domain. Knowing the domain isn’t always required to land a job, but the ability to learn the domain on the job is key to being a successful TPM.

For many years, I’ve worked with the tax teams at Amazon. Our business partners are highly knowledgeable in worldwide tax laws and the implications of those laws, and they speak in a tax-skewed legalese that can be very daunting to someone outside of the tax domain. When I joined this team, I had heard terms like situs and jurisdiction, but I didn’t know what they truly meant, or how important they were. Requirements documents were full of tax jargon, and every requirement was framed in the context of a tax-related concept. This made understanding what needed to happen very difficult, and to make matters worse, the people in the development team weren’t trained tax experts either (nor should they have been). But this meant that it was my job to understand these requirements in a way that could be explained to the development team.

Not all communication bridging has to be in the moment, and this wasn’t the case for that either. Instead, the team focused on creating courses to explain the tax domain for our developers – at least enough to understand the major concepts involved. We did the same for our business team to help them understand the data flow and major components of the software stack.

This allowed for easier communication between the technical and business teams, using a common understanding and lexicon. Any requirements that came up could more easily be talked through with a common understanding. By understanding our business and its needs, as well as our development team’s needs, we can effectively bridge the communication gap between business and technology. From a career growth perspective, this soft skill is by far the most important skill to perfect. Due to this, it is also the skill that shows up most in the growth category for career progression. To improve this skill, ensure that you practice active listening by staying engaged with the speaker (put your phone away and stop checking email). Affirm your understanding through body language such as nodding — but don’t interrupt. When they are finished, paraphrase what you heard and follow up with questions. This takes patience to do right, and that can be hard when you are trying to connect with someone quickly. I grew up in an environment where it was common to interrupt or talk over others during particularly engaging conversations. Although this can be fine among friends when talking about trivial matters, this is very disruptive in a work environment — especially given that, at work, we are often trying to solve a problem. When you interrupt, you aren’t taking in what the other person is saying because you are looking for a space in the conversation to insert your own thoughts, instead of taking in what the other person is saying. Active listening will ensure that you truly understand the point of view of the other person. Often, this information can build on your understanding of their problem.

Follow-up questions can fill in the gaps in your understanding to paint a more complete picture of a situation. Over time, you’ll understand your business teams and their domains, which will help you become a more effective communicator. The better you understand the pains of your business team, the better you can relay that to your development team in your functional specifications and conversations about scope. The more your development teams understand, the better the outcome of the software, and the more successful a project will be.

We now understand what makes a TPM thrive at their job, as well as the fundamentals to accomplish it. Next, let’s compare the roles and responsibilities of a TPM to other roles that are often found adjacent to it.