BA 29/52: TPM Team Topology - Pt. 1
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?
That is a great question and I think it will need a bit more time and space than a single newsletter. Let’s start with TPM Team Topologies.
In my career, I have encountered the following TPM team org structures:
There is no such thing as a the right team topology but rather these topologies reflect the mindset of the leadership and the place where the engineering organization is from a growth trajectory perspective at any given time.
Some TPM teams may start in one structure and migrate to another in response to the needs of the business and engineering teams. Some may go back and forth between two or more states. What matters is that the topology is being effective for the needs of the engineering organization and business at that moment in time.
Lets dive into it each type.
Overview: Technical Program Management exists as a central office reporting directly to the SVP of Engineering. All TPMs report into the Head of Technical Program Management Office (TPMO) and may have layers of managers of TPMs depending on the org size. Each TPM team or IC in the TPMO supports a particular aspect, team, component within the engineering organization (most common is supporting an any number of engineering teams).
Operational Mandate: These centralized TPMO’s typically own release management, shared org processes and frameworks (think agile project management), and support the execution of the roadmap at a tactical level by the engineering teams, provide insights and lead leadership in roadmap development and strategic planning activities.
Companies Where I Have Seen This: Apple, Google (Android)
Overview: TPMs are hired by and report to the functional Engineering Leaders. There is no centralized TPMO. These IC TPMs can eventually grow entire teams of TPMs under them as the functional engineering area grows both in scope and resources.
Operational Mandate: The TPMs are responsible for supporting the engineering teams they report under. There are no shared org processes and frameworks (think agile project management) as every team can decide their own processes (unless the TPMs self organize into a unofficial pseudo TPMO), and support the execution of the roadmap at a tactical level for the engineering team they support.
Companies Where I Have Seen This: Blackberry (Post QNX Acquisition), Google (various teams).
Overview: Similar in structure to the Centralized model however with the exception that certain functional engineering leaders may decide they wish to have their own TPM teams for more tactical purposes.
Operational Mandate: These hybrid models are quite complicated; where as the centralized TPMO’s may own release management at the org level, maintain shared org processes and frameworks (think agile project management), and support the execution of the roadmap at a tactical level by the engineering teams, the secondary TPM teams could operate on a different tactical level in support of the team they report under. Complexity and contention can arise between the central and distributed TPM orgs especially on processes and decision making. This requires a clear understanding of the boundaries of accountability and ownership between the two teams especially when in what matters to defer to which TPM team. Usually, the central TPMO has more power in some scenarios given their close reporting structure to the SVP of Engineering.
Companies Where I Have Seen This: Apple (Pre-iOS and macOS Engineering unification circa pre-2014).
Overview: A variation of the centralized topology, TPMs are the execution/tactical arm of the Product Organization. The TPMs are hired and report under the Product Management leadership.
Operational Mandate: In this TPMO’s may own release management at the org level, maintain shared org processes and frameworks (think agile project management), and support the execution of the roadmap at a tactical level by the engineering teams.
In another scenario, the TPMs may go from large projects to large projects driving them to execution and may not necessarily be accountable for supporting a particular team as the team TPM. They may work along side product leaders providing support for entire product areas and/or lines.
Companies Where I Have Seen This: Nike; Shopify*
Why should I care about this?
You maybe the first TPM hire a company makes or perhaps you are a Product leader or Engineering leader suddenly looking at hiring your first TPM.
Understanding the various TPM team topologies will better arm you in developing a proper and effective TPM deployment and scaling strategy.
More on engagement and team design later.
Until next time 👋!