What Makes a Good Technical Program Manager?

In my career coaching, I've often been asked by engineers about making a career move to technical program management (TPM) - my current role at Microsoft. In tech, program management is a role similar to project management but often encompasses more that just managing projects. At Microsoft, it is somewhat of a catch-all for many different types of roles. In my team, Commercial Software Engineering at Microsoft, one of the main focuses for the TPM role is Scrum Product Owner and in that, I've narrowed it down to four skills that need to be developed for success as a TPM: articulating a vision, breaking up a project, defining "done", and storytelling. For a TPM, the understanding of the technology and how to implement complex systems is what makes an engineering background useful and beneficial to the role. Being able to communicate with stakeholders and the engineering team in ways that are appropriate for each becomes a crucial task used throughout the job. I'll go through these skills and show a way for people to try out those skills before they make the role change.

Articulating a Vision

As the TPM is a leader, but not a manager, they need to be able to excite people about joining their project (even if they were assigned to be on it) by articulating a clear vision and purpose. Communicating the WHY for a project is crucial here as that will help align the team's purpose along a common goal. A good TPM understands that different people will join the project for different reasons but that working towards a common shared vision keeps them engaged towards shared success.

Breaking up a Large Project into smaller

Once the team is aboard and the scope of the work has been defined it is important to break up a project into tasks that are appropriate for the team that has been assembled. The TPM needs to consider how to both break up the work into manageable pieces as well as phase the development in order to start delivering value even before development is complete. Knowing the capabilities and strengths of the team members is key to breaking it up in a way that works for the team that you have. You want to enable parallel productivity of the team members, minimizing dependencies during the phases of work.

Defining DONE

It is so important to develop and define a shared, clear understanding of completion among the team before work starts so that everyone sees clearly that the end is visible and attainable. This DONE criteria will likely change during a project - that's fine - as long as the team understands that and can recalibrate their expectations. Often the first definition of DONE for a project is its minimum viable product (MVP). As the TPM started with the vision to align everyone - communicating that clearly what is IN and what is OUT becomes that DONE definition.

Storytelling

Quite often when I start a project, I envision the story that I will tell at the end to explain in human terms what we accomplished or how what we did impacted people's lives. I use this story to articulate my vision in a way that people can empathize with. As a TPM, that story is often a user journey - explaining what challenges they were facing and how the work that we did addresses those challenges. Being able to tell a good story is how you relate to people in an authentic way that they will remember - and be able to retell. That ability to retell gives the story "legs". I tell people that they need to be able to tell a story to their manager that the manager would want to tell to their own manager. If you're interested in learning more about storytelling, watch Karen Eber's talk on storytelling or find a great storytelling class on LinkedIn Learning.

Trying it All Out - with a Hackathon

So an engineer sees these skills and wants to try out being a TMP before they start applying for the role. This is exactly the strategy that Bill Burnett talks about with running experiments in his Designing Your Life TED Talk and book. My recommendation is to join a hackathon. There are hackathons sponsored across the globe to the public, in companies and in educational institutions. Participating in one gives anyone an opportunity to try out a TPM role in a very short time. The Garage, Microsoft's experimental outlet organizes a global hackathon each summer to encourage employees to form teams and hack together on anything they want. Hackathons like the Microsoft Global Hackathon gives employees who want to try being a TPM an opportunity to do so:

1. They comes up with a vision for a project and recruit a team.
2. They break up the project into work appropriate for the team who has volunteered.
3. They define what they will be able to get done to do over three days.
4. They tell the story about the project to the community.

What I love about the TPM role is the creativity needed in all of these skills - it is probably why I love hackathons as well. I've been asked about when is an engineer "ready" to be a TPM. My answer, typically starts with discussing their experience with these core skills and their ability to communicate in ways appropriate for the both business and technical audiences. The TPM is the "bridge" between the business world and the technical world.

What Should I do Now to Prepare?

A reader just asked me what they should do now if they see a TPM role in their future. Here's what I suggests:

• Participate in a hackathon where you could act as the team leader.
• Take a course (online or in-person) on storytelling. Go to a Moth Story Slam to see great storytellers in action and put your name in the hat to tell one.
• Take a certification course relevant to your industry on project management, like Scrum Certified Product owner training.
• Study TPM job postings for what skills employers are looking for.
• Make a version of your resume for a TPM role.

What are other skills that make a great Technical Program Manager?

PS: I just wrote a follow-up article on communication skills for TPMs.

Reach out if you want to chat about your career today at TechCreativeCoaching.com.