6 Principles for Building a World Class TPM Team

Given the variability in the Technical Program Manager (TPM) role, it can be hard to know if a new opportunity will grow your career massively or fall short of your expectations. After years of building world-class TPM teams, previously at Uber and now at DoorDash, I’ve developed a few principles for how to build and run a high-functioning and impactful TPM organization. If you are looking for a new TPM opportunity and focused on growth, scope, and impact, you should seek a team that follows these principles.

The mission I set for my TPM team at DoorDash is to drive complex, cross-functional engineering initiatives. Their primary contributions include effective program management, lightweight and appropriate process definition, and ensuring program success metrics are understood and achieved. All of this is driven through the lens of a strong technical perspective, which allows the TPM to contribute directly to the program’s successful definition and execution by uncovering and solving for gaps rather than simply reporting progress given by engineers who are working on the program. A strong TPM will enable proactive and timely strategic decisions, clear alignment across teams and stakeholders, accountability and ownership, and successful execution of the program’s objectives. 

The TPM team has a strong leadership position in engineering

TPM should be a centralized function reporting to the head of engineering. Although TPMs represent a tiny fraction of the engineering team, they support the success of cross-functional engineering programs and deliver the most complex projects.

Impactful TPM teams have a seat at the leadership table, allowing them to give input on how engineering builds for reliability, velocity, and integrity. Their work helps engineering scale effectively and get ahead of the biggest technical and growth challenges, as well as successfully deliver the largest cross-functional initiatives. They also help the engineering team decide when to build more generally, with a goal of centralization and reuse, such as platforms that scale across multiple use cases, or when a specific use case makes the most sense. 

Great TPM teams drive alignment and process improvements that push engineering to operationally up-level over time. Additionally, given how cross-functionally TPMs operate and embed, they are a critical component to a growing engineering team’s culture, diversity and inclusion, and collaborative development.

Of course, there are downsides to a centralized TPM team, particularly in surfacing feedback from engineering and other cross-functional stakeholders about how individual TPMs perform in their roles, which requires TPM managers to regularly check in with these stakeholders. From my experience, however, there is an advantage for the TPM team and the engineering team if those downsides are managed effectively by strong TPM leadership rather than distributing TPMs to work under engineering leaders. 

I believe it is better for the TPM team, the individual TPMs, and the engineering organization if the TPM team is centralized. The advantages of a centralized TPM team include:

• Centralized TPM teams create synergy which leads to best practices, shared learnings, and a rapid way to pinpoint answers to questions around service ownership or organizational expertise. This TPM network is particularly important in the high-growth stages of an engineering organization, where things change rapidly and are documented lightly. TPMs work most effectively amidst a support system to share ideas, learn what worked well for other teams, and combine their collective knowledge across multiple engineering and cross-functional teams.
• A centralized reporting structure preserves the impartiality of the TPM. Although their reporting structure is centralized, the TPMs still embed with the engineering teams they work with on a particular program. This embed model allows them to work closely with engineering and gain trust with the project teams, but it also provides a safe alternative path to raise, brainstorm, and resolve more contentious technical, operational, cultural, or organizational issues.
• Centralized TPM teams have specialized TPM leaders in manager roles who generally have many years of TPM experience themselves. These leaders understand the TPM discipline deeply and can optimally develop and coach TPMs in a way that helps them grow and develop their core competencies and the impact they deliver. Most engineering leaders don’t have this expertise, so a decentralized reporting structure is sub-optimal for TPM growth and effectiveness.
• TPM teams remain lean through a centralized structure. An experienced TPM manager places TPMs on teams where they are needed, rather than a decentralized model where each engineering team has its own TPM. In the latter case, TPMs often end up doing less specialized work, such as sprint/scrum ownership, because the engineering leader mistakenly believes this is the best use of their time, when these tasks generally should be handled by engineering or product managers. Centralized teams of impactful TPMs contribute to an engineering culture of ownership. This model also promotes scope and growth opportunities for TPMs, making it easier to recruit and retain top talent.
• A centralized team provides an organization-wide view, embedding TPMs where they can support a company's top priorities, even when these priorities are shifting rapidly. At times this means moving a TPM from one embedded team’s priorities to another team or program that is a higher impact or bigger risk for the company. The flexibility of a centralized reporting structure encourages these priority discussions and changes as appropriate to accomplish the most critical projects for business and engineering success. 

The TPM team is highly leveraged

The best TPM teams are a critical part of tackling the company’s biggest problems. To ensure my teams stay highly leveraged, I’m particularly conscious of how we build the team in its early stages, recruiting a founding dozen or so team members who are top talents in their domains as well as program management experts so we can build around their leadership as they embed in each top-level engineering area. Having senior team members seed the team early on sets it up for future leverage and impact, and lets us add more junior TPMs around them more efficiently as the engineering team grows.  

Although ratios are a terrible measure for a small engineering organization, they become a reasonable way to plan hiring and headcount as engineering becomes a bigger organization. My target ratio of engineer to TPM at scale is approximately 50 to 1. I also ensure that each engineering team they embed with understands the value they bring and gives them an opportunity to be part of strategic as well as tactical execution and planning. 

Ensuring the team is highly leveraged also helps in attracting and retaining senior TPM talent. This high leverage ensures there are growth opportunities for everyone and removes the need to compete with one another for the scope and impact needed for career growth. TPMs should constantly be automating and inventing, implementing light processes for the team, or teaching someone basic program management techniques--looking for how to make themselves unnecessary so they can work on solving the organization’s new challenges. I often tell people, tongue in cheek, that if we meet our goals we will work ourselves out of a job. Of course, in a company experiencing rapid growth, the business and scale issues mean there are always new problems to tackle. But solving problems systemically is a core tenet of high-performing TPM teams.

Being highly leveraged is also an important part of the TPM team’s internal dynamic. A team that sees opportunities for growth will support its other members, share best practices and learnings, coach and mentor more junior team members, and create synergy by working together to solve bigger problems consistently across organizations. They will challenge each other to get better, which makes engineering better. This synergy is the real superpower of a centralized TPM team, and as a leader, the most important way to nurture it is to ensure there is opportunity for this kind of cross pollination. If a program management organization believes in adding a program manager to every two-pizza project team, then its leadership doesn’t follow this leverage principle, which impairs the growth and synergy created by a team that does. 

The TPM team is empowered to fiercely prioritize the work they drive

The work we decline is just as important as the initiatives we take on, and having clear principles for deciding what work will produce impact and is uniquely suited to our strengths as TPMs is an important point of view to cultivate. Much like the scoping decisions we make when building an MVP, engineering time is valuable and must be balanced against the return a feature provides. Similarly, I want to cultivate a team that is looking for the highest value way to spend their time every day to deliver great engineering outcomes. As one of my mentors used to say, “Spend your heartbeats on what you value.” For most TPMs what we value is the impact we have on the engineering team’s success.

As a TPM leader, I do my best to set each TPM up for success in the team they are embedded in. Before embedding someone in a new area, I work with the leadership to rank all their priorities in order to figure out what we should and should not support.  

Additionally, once a TPM has been working with the team and knows them and their tech stack well, they should begin to cultivate their own viewpoint. This will likely mean adding suggestions for what should be on this stack-ranked list, based on gaps they see in such things as how the team plans and delivers work, supports their partner teams, handles inbound requests, manages technical debt, and operates on call. Identifying the right priorities to improve engineering effectiveness is a big part of the value an embedded TPM can provide, over time, as they establish trust with local engineering leadership and can inform and influence how the team allocates its engineering time. 

Scaling engineering is one of the core competencies of a strong TPM organization. Often the initiatives we don’t take on are an opportunity to up-level our engineering teams by guiding them and developing their ability to own initiatives themselves, rather than project managing everything for them. Instead of taking on project management, for instance, we might help teams establish better milestones to reduce a project’s risk or suggest a tool to help track project dependencies more effectively. Teaching project management techniques and tools to our engineering managers and technical leads who own delivery of more contained projects helps us scale and up-level the engineering organization. When a team can project manage its own contained projects, we maximize the TPM team’s leverage, saving them for bigger projects that involve many engineering teams and really need a project management expert for success, rather than smaller ones that only cross one or two teams. We are also simultaneously contributing to a high-performance engineering culture with a strong ownership mentality.

TPMs should be able to focus on making the biggest contribution with their limited time. TPMs are not just part of one team, they are part of two teams--the engineering team they embed with and the centralized TPM team. Everyone on a team should be willing to do whatever it takes to move the team forward, including mundane work. TPMs are not above certain work. Even as a director I have personally ordered dinner each night for a team I had holed up in a war room to solve a huge time-bound system scaling issue, because at that moment it was the most important way I could contribute. The ability to choose your focus based on what will have the most impact is something you earn with what you deliver, the value you add, the partnership you provide, and the trust you build.

The TPM team consistently drives technical clarity 

As TPMs, we embed in engineering and grow deep domain knowledge from the engineering organization we work with. We develop expertise on our tech stack, partnering closely with the tech leads and engineering managers to come up with the short-term deliverables and shape the long-term strategy and technical direction. TPMs should be able to bridge the business needs with the technical challenges to help engineering balance time-to-market with reliability and scalability. Additionally, TPMs use their deep technical knowledge to help drive technical decisions, mitigate technical risks, and propose alternatives. 

Our partnership with engineering is founded on our ability to add solution value, not just track deliverables. TPMs operate cross-functionally, driving programs that include many teams and integration points, and this breadth and scale typically increases as the TPM gains experience and seniority. In a strong engineering team like DoorDash’s, I’m not as worried about how each individual piece is designed and built because I trust our engineers and tech leads to drive towards the correct technical solution for their piece of the problem. 

A great TPM ensures this technical solution is built within the context of the bigger picture, however, ensuring the business, technical, security, and compliance needs of the overall solution are well understood by teams. By holding this broad picture, TPMs can actively ensure that all the pieces of the puzzle actually build a holistic solution once they come together, and there are no gaps or overlaps between teams and parts of the solution. This is where TPMs really shine and where their technical skills are tested. They should be looking for these gaps or overlaps and actively solving for them in the project, as well as aligning the milestones, deliverables, and dependencies of the project so that issues are found early and solved, reducing risk to delivery dates. Technical depth also allows a TPM to ask the right questions around scale, growth, and success metrics for the solution so that we invest in an implementation that will serve our customers appropriately, particularly in a hyper-growth environment.

Technical as well as business acumen allow us to drive the appropriate trade-off discussions and ensure the big picture is kept in mind while solving the immediate problem. Having technical depth allows us to drive accountability by being part of the process end-to-end, not just tracking its progress in a spreadsheet and asking engineers for estimates and project updates. That’s when a TPM team really sizzles, bringing value to engineering by making complex problems consumable, leading to simple and effective solutions.

The TPM team tackles difficult problems in a blameless culture

TPM teams walk the nuanced tightropes of ownership and accountability. As TPMs, we drive programs that span many teams, and none of the people involved in doing the real work report to us. Much of what we do involves leading delivery of something cross-cutting and complex through influence, alignment, and providing accountability against the project plan and end goals. Leading with influence is a core competency for an effective TPM, and we should strive to create clarity and alignment by constructing a narrative for why the program matters and gaining commitment based on the strength of that narrative relative to other business or technical priorities.

At DoorDash we believe in a culture of ownership and use a DRI (directly responsible individual) model to drive that ownership with clarity. Every major initiative at DoorDash has a DRI, and sometimes, but not always, that is a TPM. 

The DRI is responsible for ensuring that the program is completed successfully. This means ensuring it has the resources needed, that issues are resolved quickly, that risks are managed effectively, and that key decisions are made in a timely manner, allowing the program to move forward. If the TPM is the DRI on the program, their role is clear--ensuring it is successfully delivered. But even if someone else is the DRI, the TPM will be a key partner in the DRI’s, and program’s, success, because the key skills of organization, definition, alignment, identifying and mitigating risks, unblocking and resolving issues, and tracking progress against project goals are all key responsibilities of the TPM. A strong TPM is not going to let a program fail because of unresolved issues, lack of alignment, or lack of resources. These are the problems we fight to solve so a program can be delivered successfully.

One of the most important things a centralized TPM team provides is neutrality. Even though the TPM may be embedded with a particular engineering team or area, the separate reporting structure means that the TPM remains a neutral party. This is again a power to be wielded with care and earned with stakeholder respect and trust, but I want my team to feel able to highlight and engage with the team and leadership to resolve weaknesses, whether technical, organizational, or cultural, which impede a program’s success. 

The team should be incentivized to operate with openness and honesty and to create clarity. They need to work with engineering to set aggressive goals and milestones, without padding, and report accurately on where the program is against those goals, particularly if there are key work streams that are yellow or red against plans. We can’t fix issues we don’t acknowledge, and neutrality ensures that there is some air cover to ask tough questions and shine a light on problems, with the end goal of working with the teams to get to a solution and successfully deliver the program together. Often, problems are exposed at the borders between engineering teams, where a cross-functional project is suffering because there is no alignment between teams on goals, responsibilities, or timelines. TPMs need to bridge these gaps between teams, and neutrality paves the path for that to happen in a blameless way.

The TPM team is recognized and valued by the organization for its ability to bring order to chaos

At DoorDash, each of the TPMs build recognition and the team’s reputation incrementally, day-by-day, with what we deliver: managing projects over the finish line, ensuring each planning cycle is a little smoother than the last, running effective postmortems to avoid future outages, and driving monthly operational reviews that gradually tighten up engineering execution. 

When I joined DoorDash to lead the TPM organization, I knew we had crossed the tipping point the first time a leader outside engineering asked me for a TPM to drive a critical company objective. People ask for us when something is big, complex, broad, and difficult. I might not always say yes, adhering to the principle of fierce prioritization, but I’m happy when someone sees a problem and thinks of us first. That’s when I really know we’ve made it, at least for today. We have to get up and do it all over again tomorrow, with the next hard problem. But that’s the fun of this job, if one is lucky enough to get to do it at a rapidly growing company, solving interesting problems at scale with a group of really amazing and committed engineers. I love building that TPM team and delivering that impact, together with engineering.

Final thoughts

Your role on a team and at a company is contextual, because we operate day-to-day in a specific environment, not a vacuum, and are impacted dramatically by the characteristics of that environment. The qualities of the work we do and the time we spend working are heavily impacted by the culture as well as the leadership of the company we join. As leaders, therefore, we are responsible not only for the teams we build and develop, but also for our thoughtful and intentional impact on providing an optimal environment for that team to thrive and do their best work in service to the company. 

I chose to come to DoorDash for many reasons, and one of them was certainly the culture I saw here and how that culture was developed and nurtured by its leadership team. I didn’t have to change anything culturally to be successful or to develop and build a world-class TPM team within DoorDash Engineering, and the growth and scale trajectory provided by the business creates the opportunities for scope and impact that compel great TPMs. 

In other words, the scaffolding was already in place for the team I wanted to build and be part of. This team is one where TPMs are not only valued for their basic program management skills but also for their strategic thinking, technical contributions, problem solving, positive cultural impact, and operational talents. As I continue building our TPM team at DoorDash, I strive to also build the best environment and culture for that team to be a valued partner in engineering’s success. I am incredibly fortunate to have the opportunity to build a world-class TPM team at this amazing company.

The DoorDash TPM team is growing. Check out these opportunities if you are interested in joining us!