BA 30/52: TPM Team Topology - Pt. 2
Q: How are TPM orgs and teams structured at places like Apple, Google, Nike? How do the TPMs work with engineering teams or on projects?
Last week, I talked about the TPM Org structures that exist within the tech industry.
This week, I am going to focus on how you deploy TPMs at the tactical level.
The two ways any TPM is deployed is either:
Coverage Area: TPM is responsible for covering a large release, org wise cross-functional project with numerous teams or entire product lines.
When to use? When you find that your product or engineering leaders are spending too much time managing tactical aspects of the project work, or when you are trying to introduce a TPM to the organization, this is the ideal way as the TPMs are focused more on advocating the value they bring to big projects versus trying to convince engineers to add a TPM to support them vertically in sprint planning and agile deployment etc.
Coverage Area: TPM is responsible for supporting a specific team, a component of a product or some aspect of any given project.
When to use? When TPMs are accepted as an important aspect of the engineering organization and now your organizational scale is at a point where teams need help organizing, and prioritizing between various projects and product releases as well as being in driving seat of numerous projects, vertically deployed TPMs can add more order to chaos.
⚠️ Word of caution ⚠️
Be careful when mixing Horizontal and Vertical deployment of TPMs. Some anti-patterns I have seen in disastrous mixed deployments:
Who owns the final accountability of the project will get confusing.
An inexperienced TPM will fall into the trap of playing politics when working with cross-functional orgs especially vertical TPMs.
Process alignment becomes chaotic between the org and the individual teams.
Decision making becomes complex as horizontal TPMs may start to exert org structure as a forcing mechanism.
My advise is to never mix the two styles of TPM deployment.
Start with Horizontal TPMs and get the engineering organization used to the value TPMs can bring to the org and projects.
Then, scale the horizontal TPM workforce.
OR transition to a vertical TPM workforce where the engineering team with the most accountability or expertise has their TPM act as horizontal TPM.
Why should I care about?
Goal of TPMs is always about creating order from chaos so the kinetic energy generated by bringing cross-functional teams together can be channeled in a productive and organized manner toward the desired goal.
It is important that you understand how and where you can deploy your first initial TPMs because it’s not just about shipping projects but if deployed incorrectly, engineers will form a stronger resistance to adopting TPMs as part of the normal functioning of an engineering org and only see them as “Date Accountants” or “Agile Bureaucrats”.
Until next time 👋!
How was this week’s newsletter?