Hey 👋 this is Luca! Welcome to a ✨ free monthly edition ✨ of Refactoring.

Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.

Here are the latest articles you may have missed:

• LinearB — The Quest for Engineering Productivity

• New Tools and Techniques for 2023

• How to Delegate Effectively

To receive all the full articles and support Refactoring, consider subscribing:

Become a better tech leader today ✨

You can also learn more about the benefits of a paid plan.

A few weeks ago I had a good chat with a friend of mine, who has a technical leadership role at a mid-size company (~50 engineers).

He told me they finally managed to create cross-functional teams that are fairly independent, and that he is happy with how fast they are able to ship new things. However, he also told me he is struggling with a couple of projects that — necessarily — span the work of many of such teams.

Coordination is tricky and so is resource allocation, because ownership is somewhat distributed and each problem goes back and forth like a hot potato.

I asked him if they ever thought of introducing Technical Program Managers to run such projects. He answered that he wasn’t sure, because he wasn’t familiar with the role and how it would fit the organization.

This was an honest confession, and it struck a chord with me. The TPM role is often misunderstood, I believe for two main reasons:

• ⏱️ Timing — as with many roles that aren’t useful until your team reaches a certain size, it is tricky to figure out when it is the right time to add one.

• 🔬 Scope — TPMs sit in your product / engineering org while having no direct authority or ownership of engineering or product teams or components. Many people are baffled at this.

So how does Technical Program Management work? To shed light onto this crucial role, I asked for help from my friend Aadil Maan, who graciously co-authored this piece.

Aadil has a tremendous experience having led programs at companies like Humane, Apple, Nike, and Google. He is also a fantastic writer — he is the author of the Building Romes newsletter, where every week he explains and demystifies specific aspects of the TPM role. You should check it out!

So, this article wants to be a primer on Technical Program Management where we cover the why, the what, and the how.

Today we will talk about:

• 📖 What is a TPM — and how they differ from other managers.

• 🤹‍♀️ Skills of a good TPM — let’s talk project management, tech knowledge, and communication.

• 🔍 Signs you may need a TPM — to figure out when it is the right time to add one.

• 💼 How to break into a TPM role — career advice for people interested in the role.

Let’s dive in! ​

📖 What is a TPM

A typical Product team may consist of a Product Manager, Engineering Lead, Design Lead, and some engineers.

Often times that is enough, but for complex projects where you have multiple teams working together, a Technical Program Manager may step in to orchestrate the collaboration across the various domains.

To put it in another way:

• Product Managers focus on the what and why.

• TPMs help Engineering Leads with the how and when.

A TPM is the nervous system ensuring product and engineering continues to stay aligned on the what, why, how and when.

At large companies, where it becomes necessary for Product Managers to focus on the strategic aspect of their role, a TPM is brought in like a tactician to help execute on the grand strategy. So, the TPM enters the stage to develop an end-to-end execution plan on how to ship a solution to a technical problem.

Such problems are of varying complexity, usually ambiguous in definition, and need to be delivered in collaboration with engineering, product, design, and marketing within a certain time & budget.

But how do TPMs do that? 👇

🤹 Skills of a good TPM

A Technical Program Manager needs three core competencies:

1. Project management

2. Technical knowledge

3. Soft skills

Let’s see all three:

1) Project Management

Knowing how to take complex requirements and develop an achievable project plan within the constraints is the bread and butter of every TPM.

Here are the key Project Management skills every TPM needs:

🗺️ Project plans

You don’t have to have a GANTT chart to have a project plan.

A TPM needs to know when something as simple as a spreadsheet will be more effective, or when a PERT chart is needed versus GANTT chart.

Remember — at the end of the day, project plans are a series of cascading gates (milestones) with set exit criteria (work to be done, acceptance criteria) that must be reached by a certain schedule.

🔪 Breaking down work

Requirements must be translated into actual work to be done by all members of the cross-functional team. This can be as simple as translating requirements or user stories into epics or how to break down epics into their child tasks.

🏰 Information Architecture

Complex projects have a large number of moving pieces.

It is imperative that information is flowing, referenceable, and available at all times to stakeholders. TPMs often design wikis, living documents, PRDs, archives for meeting minutes, and more, for effective collaboration. TPMs must know how to assess, group, and design artifacts to be stored.

🪫 Risk Management

TPMs excel at risk management.

Many programs and products fail primarily from not managing risk properly. Keeping track of risk and developing the right response at the right time can make the difference between a slight delay to completely missing the deadline by quarters.

🧘 Agile methods

You don’t have to be a Scrum expert, or religiously adhere to program increment planning or Kanban boards.

What is important is that you are aware of the core components of the various agile practices, then help your teams pick and choose the right pieces from them and develop a bespoke methodology that fits the culture and personalities of your team.

🤹‍♂️ Stakeholder Management

You will work with varying degrees of personalities so it is important for you to know how to deal with and manage everyone's needs and wants.

Proactive stakeholder management is key to making sure that your team can focus on building the product instead of constantly answering inconsequential and annoying questions.

2) Technical Knowledge

No one expects Technical Program Managers to know how to code.

However, to be successful members of the Product team, TPMs must have a systems-level understanding of how the various components come together to develop complex products.

Here are the key technical skills every TPM should possess:

📐 Systems Design

TPMs drive large projects that span across multiple engineering teams.

Thus it is important that a TPM understands how backend and frontend systems work together, what APIs are, how modern app dev happens, and what role cloud plays in the workflow.

🎨 Design Thinking

If you are responsible for driving UI based products, it is important to understand how design teams think, work, and deliver UX/UI.

This understanding will help you create a better plan, design collaboration between engineering and design, and communicate to leadership why it takes so long to deliver “a simple button” :)

🚀 Performance and Quality

In order to ship high-quality, performant products, a TPM must be the voice of quality.

You should understand how the various types of tests (e.g. unit, integration, E2E) come together with logging and monitoring to catch quality issues before they become news articles. In addition, when developing project plans, a smart TPM will bake in time for fixing performance issues, quality bugs, and will find time to deal with tech debt.

3) Soft Skills

Technical Program Managers rarely if ever have any direct decision-making authority yet are accountable for the success of a program.

They are often known as Leaders Without Authority. Therefore, they must rely on their soft skills to be able to Lead With Influence.

What does it take to lead with influence?

❤️ Trust building

Trust is the primary currency that a TPM uses to push programs towards success.

A TPM needs to be trusted by engineers to help them resolve road blocks, to keep communication lines open, to manage risk, and to be an advocate for the product team.

On the other side, leaders place their trust in TPMs to deliver programs on time and schedule, to make them aware of pending risks, and ensure information flows to all parts of the company for better collaboration.

Trust is earned through experience, by showing up for the product teams ready and willing to help.

⚔️ Negotiation

TPMs don’t just ask for dates.

They understand that everyone is under pressure to deliver on their roadmaps and commitments. They leverage empathy to help teams figure out what positions need to be changed to get their program across the finish line.

🤝 Diplomacy

This is perhaps the biggest soft skill a TPM brings to the product team.

Engineers, Designers, Product Managers, Marketers — everyone is wicked smart at what they do. It is natural for conflict to arise when collaborating on complex projects.

The TPM is the one person in the room who takes no sides but focuses on the good of the program and its stakeholders. They help bridge the divides and defuse the tension in the room.

🧐 Inquisitiveness

All plans are as great as their weakest link: that single missing detail, or that lack of understanding.

TPMs are great at asking questions to dig deep into the details, to ensure that nothing is left to chance, that everything that can be understood is understood, and to prepare for the unknowns that the product team is not aware of.

🔍 Signs you may need a TPM

Based on the skills and responsibilities above, it is obvious you don’t need a TPM from day one. This is a role that pays off once your org has grown beyond a certain size and complexity.

But what is this size, exactly?

Giving hard rules is tricky, because things pretty much depend on the skills of people on your team, the type of projects you work on, how much cross-team coordination is needed, and more.

So, instead of rules, you can watch out for signs that you may need a TPM. Here are some:

1. Bad collaboration — Have you noticed a lack of cross-team collaboration on programs? Do you feel information flows effectively between the teams?

2. Missing tasks — Are you getting constantly surprised by a missing task or work stream or dependency on complex programs?

3. Swamped PMs — Have you noticed your Product Managers are spending way too much time focusing on tactical execution rather than strategic action?

4. Undecisiveness — Have you noticed a lack of follow through on decisions, action items, or communication?

5. Shallow planning — Have you noticed that planning feels haphazard nowadays?

6. Little ownership — Do you feel like no one has the full 10,000ft view of what’s happening on a critical program?

7. Unmanaged risks — Do complex projects continuously suffer from completely predictable and otherwise manageable risks?

8. Bad alignment — Is leadership unsure that engineering teams are spending time on the right things?

If you answered yes to half or more of the items above, well, congratulations — you may need a TPM! 🎉

Conversely, here are also some wrong reasons to hire a TPM, that you often hear nonetheless:

• I want someone to write our Jira tickets.

• I need someone to write meeting minutes.

• I don’t want to have to deal with building GANTT charts.

• We need someone to off load sprint ceremonies so engineers can write code.

• We need someone to come implement Scrum for us.

• We need someone to help us be agile.

• I don’t want to write or roll up status to leadership, let’s hire a TPM.

• We need someone to clean up and keep grooming our backlog. 

• I need someone to help me manage the meetings on my calendar.

These are all tactical issues that, yes, may legitimately drive people mad, but are not conclusive of the TPM opportunity per se.

Adding a TPM is a strategic choice, that is grounded in how you want work to happen across teams and projects. Yes, down the line this may help with many of the issues above, but only if their root cause lies in the collaboration and project management work that is TPM’s bread and butter.

💼 How to break into TPM

Being a hybrid and often misunderstood role, many people wonder what kind of track record you need to break into TPM.

A major factor is whether or not you come from a technical background. In fact, I have seen people having successful TPM careers in both scenarios, but what you need to exhibit in interviews / your resume is probably different:

Coming from a technical background

Going back to the three main skills we covered above, if you come from a technical position, you must prove that you have the right project management and soft skills to excel in the role.

To do so, both in your resume and interview, you should focus on projects where you played a direct role in things like:

• Putting together an execution plan.

• Developing processes and frameworks to improve engineering velocity and efficiency.

• Managing communication with stakeholders.

• Resolving roadblocks and ensuring all the action items were followed through on.

If you lack ‌such skills or a solid track record, there are two main ways to develop them:

1. Work — Take a more active role at your current company to lead projects in some capacity. For this, you can most often take some initiative even without a formal role.

2. Study — look into project management classes, executive education programs, and certifications, like those offered by the Project Management Institute. Even Google Grow offers certificates in agile project management which will give you some good foundations.

Coming from a non-technical background

If you come from a non-technical background, you must prove that you can hold your own when collaborating with engineering and be more than just the “can you give me date for that task?” guy.

You can be the voice of the technical teams with leadership, translating technical knowledge into business impact.

To exhibit this, as part of your interview prep, think of a large project you drove that was successful, and also one that was not successful, or had issues. Think of the role you played in both, especially driving technical issues, road blocks, and requirements. Think of your lessons learned.

If you lack the technical skills we covered earlier in the post, the best way to catch up is to start reading. Even one hour of study per week, but done consistently every single week, can go a long way.

Staying in the newsletter domain, here are some of the best ones (other than Refactoring!) you can check out for systems level education:

1. Technically — especially targeted to non-technical folks aiming to get a better understanding of basic tech concepts. Very well written.

2. ByteByteGo — hands-down the best newsletter out there about system design. It includes plenty of case studies / exercises you can use to improve your chops.

3. The Pragmatic Engineer — a unique blend of engineering advice and news about what’s happening in the tech space. Particularly suited for folks working in big tech.

Consider also pairing with technical leaders on your team, and asking them to give you an overview of how the system works. Knowing well the ins and outs of your actual systems can often compensate for the lack of more generic tech chops.

Finally, always remember that you don’t have to be an engineer to be a TPM — you rather have to be a quick learner and student. The best TPM I know — my mentor — has an MA in English.

So, tech skills can always be learned, but make sure you are exposed to projects where you play an impactful role. Every successful or not successful project you lead will make you better.

🏛️ Learn more on the Library

That’s it for today! You will also find this and the attached resources under the Technical Program Management topic in the Refactoring Library.

Go to the Refactoring Library 🏛️

Check out this video to see how the Library works.

💬 Join the Community

This article couldn’t be possible without the great conversations that happen in the community. I love sharing the upcoming articles in advance and bouncing ideas off with 400+ tech leaders!

It is the best part of Refactoring — you should join it if you haven’t already.

Join the Community 💬

Check out the welcome video to learn more.

See you next week 👋

Sincerely,
Luca