Demystifying TPM Responsibilities - Part 2 - Communication
Updated: Feb 6
This post is a continuation of my previous post on Demystifying TPM Responsibilities where I focused on the program management aspects of the role. As I mentioned previously, good program management and planning is required for setting up a solid foundation upon which you can execute. A robust communication strategy is integral to execution strategy.
So let’s dive into communication responsibilities of the TPM role.
Manage communication within the organization and cross functional teams.
The goal of program communication is two-fold - first, to keep the core program team aligned on scope, milestones and timeline and second, to keep leadership (Manager, Director, VP, C-level execs) and stakeholders (other teams, business groups etc) informed of risks and mitigations.
The TPM needs to bubble up the right level of information at the right time to get the most out of your messaging. Besides informing stakeholders, the goal of communication is also to seek help if needed to further execution.
The TPM needs to identify the right communication strategy (cadence, level of details, documentation, reviews etc..) depending on the type of information being communicated and the audience for the same. Here are some key pointers when setting your communication strategy
Format and Medium: Format of the communication relates to information structure. This will be highly dependent on the medium of communication. Email communication will need to be formatted differently than a presentation which will be different than a post/message in a group. Our audience is overloaded with information from every direction, so it is important for us as a TPM to make the communication worth their time. Your communication format should be able to quickly answer your audience’s question “what’s in it for me?”.
Audience: This can be the program core team, stakeholders from outside the organization, external vendors and/or senior leadership/c-level execs. Different people need different information so you will need to adjust all aspects of your message based on the audience.
Level of detail: Think about how much time your audience has to read the information and how much time do you want them to spend. For example, senior leadership is most interested in knowing about key risks, mitigation strategy and they need to help unblock you. On the other hand, a cross-functional team wants to know when dependencies will be resolved for them so they can continue the required work.
Type: The type of communication depends on the phase of the program. During the planning phase, your communication will focus on finalizing requirements or informing everyone about your roadmap, work breakdown structure and timeline. During the execution phase, you may report weekly/biweekly status updates. Communication will also be needed if there are changes in scope or delays in timeline.
Cadence: This usually refers to how often you want to communicate. You can have multiple cadences depending on information type or audience. For example: You may do a weekly update for your core team but a biweekly update to other stakeholders.
Once you have identified a communication strategy, you will need to start formulating the details that you want to get across. A TPM should provide enough context so everyone understands the reason behind the communication. A TPM should never assume that the audience knows what is being referenced. It is also very important for a TPM to provide key insights with every communication. Don’t just share status updates or meeting notes verbatim. Provide a summary followed by more details so you can reach a wider audience.
A TPM is a bridge between the technical and business world and there should be able to effectively communicate technical and business information to non-technical and technical audiences respectively.
I hope the above helps you think about how you can make your communication crisp and insightful. You may need to adapt your communications style to the culture of the team/company so be mindful that what worked in one organization may not do so in another.
Here’s a generic format that I have found helpful. I adjust it based on what I am communicating, but I try to answer these key questions each time.
<short 2-3 line summary/highlight>
<who should read this? This does not need to be part of the communication but helpful to define the audience>
<description of your update/communication/ask>
<context/rationale and importance of the WHAT?
<section to provide dates/timelines on specific activities>
WHERE/HOW as applicable
<long version as needed to provide deep dive for those who want to read more>
Read Part 3