The Cambridge English Dictionary defines “handbook” as:

a book that contains instructions or advice about how to do something or the most important and useful information about a subject

Let’s revisit this at the end and see if this book holds true to that definition.

What’s it about?

The general idea behind the book is that it covers a broad range of topics related to a Technical program Manager (TPM). The book has 3 main parts:

What is a Technical Program Manager?

It covers a bit of history of the role as well as what the expectations of the role are now — the focus being FAANG. It also talks about the difference compared to other job roles, such as an Engineering Manager.

Fundamentals of Program Management

This is the meat of the book and the closest part to a “handbook”. It describes the key areas of focus for a TPM when running a program. The main topics covered are:

• Finding Clarity (especially at the start)
• Planning
• Risks
• Stakeholders
• Program management

There’s a sample program (” Mercury Program”) that connects each of these topics. You can read these on their own with having read the other parts.

Technial Toolset

This part covers the “T” in TPM. At a high level, it covers things you would expect a software engineer to know and understand.

It includes things like

• Understanding the types of programming languages, data structures and algorithms
• Systems Design and Architecture (Service Oriented, Event-Driven, Domain Driven Design, etc)

I must emphasise that these are introductions to these topics. If you want to understand these in deep detail, you would need to read other literature. Joshua (the author) says that this part is brief because he assumes the reader has a technical background.

Why did I read it?

As someone who has worked in technical delivery for many years now, I read this book for two main reasons:

• To understand what the latest expectations are of the TPM role in Tech
• To understand the gaps in my knowledge or experience to drive where I can improve

I’ve never been an engineer — sure, in roles next to engineers, I’ve done lots of SQL, shell scripting, peered at Java/Kotlin to understand a technical point, deployed containers to production, designed systems and so on.

But, as time progresses, I find myself doing this less and less and, talking to others doing this more and more. Is this normal in the TPM role?

What do I think of it?

First off, let me say, writing a handbook is an ambitious task. Unlike a student or machine handbook, a lot of what a TPM does is context based — what are the practices in the company, how do to the teams work, what is the culture of the organisation…?

For each section, I’m using a star ⭐ (for things I liked) and a wish 🙏 (well, for things I wished were included)

What is a Technical Program Manager

⭐ This is my favourite part of the book. I like the look into the history and the comparison across companies and job roles.

Fundamental of Program Management

⭐ I would say this covers all areas of Program Management (the “PM” part) that at TPM needs to do and think about, along with some good advice and tools to use. If you followed this part, you would ensure you were covering all the key elements of a well-run program.

🙏 The reality of programs is that they are a messy melting pot of people, processes, external pressures, market conditions, etc. This means that often things don’t pan out exactly how you plan them at the start. I’d probably cover more on “when things don’t go to plan”.

🙏 I also wish there was more about estimation. It’s briefly covered, but in technical programs, estimation is often a controversial topic. At a minimum, exploring and discussing things like the “cone of uncertainty” or talking about the impact of technical tradeoffs when working towards a fixed time.

Technical Toolset

⭐ Software — its engineering, architecture and delivery is a huge topic. Whilst the focus was on code development, system design and architecture, I wish the author had added in other things to explore. One way to do this might have been to follow a piece of code through to writing to production (so you can touch topics such as code integration, compilation, observability, deployment architectures, release strategies, etc.)

Would I recommend this book?

I would recommend this book to the following people:

• Tech folk interested in moving into a TPM role
• Grads entering a tech consultancy. Even if not working day to day in program management, there are elements you end up either being exposed to or supporting leaders with.

I’d not recommend this to more experienced delivery managers or TPMs — for those folk, I’d say “Think about an area that you would like to improve on and delve into detail on that topic”

And to conclude… does this hold true to the handbook definition?

Yes, it does — although perhaps it’s better classed as “Program Management for Technical People” — or maybe that’s just me being a pedant.