This is a very big question and as I am writing this, I am not sure if I can answer it in just one post. As I’m looking at the question on my screen, there are two things that I immediately think about.
- I remember all the times I asked this question – because I wasn’t sure myself
- I am resisting the urge – typical of a program manager – to shorten (or “synthesize” *ugh*) the sentence to ‘Why Program Management?’
Now while I’m doing my best to ignore point number 2, let me expand on point number 1. I will then follow this up with a more structured posts to actually explore the actions of a program manager that make all the difference to their team. Together this should hopefully do the topic justice… 😛
The first time in my career when I asked myself about the value of program management was when I was interning as a software engineer. Based on my very limited understanding of the discipline, program managers were the people asking me to update a bunch of systems after doing my technical work. They were also the people who ‘protected’ me from having to do too much e-mail and a bunch of meetings, allowing me to focus on typing away in Visual Studio. This is no doubt a very simplistic way of putting it, but it describes at least one aspect of the role.
A good program manager will protect their engineering teams from randomization by taking informed decisions about how to prioritize the team’s work. They will give the work context and understand the purpose of the work.
For that to be possible it’s important that program managers are deeply technical. Later in my career – when I started interviewing for program management roles – I once got told that ‘you can be a program manager for literally anything. It’s just leadership, management, organization, and communication.’ I fundamentally disagreed.
Yes all of these things are important, but they only become relevant in the right technical and customer context. If you do not understand what your team is working on, it’ll be incredibly difficult for you to prioritize the work, or to represent it externally. As a result you will randomize your team and fail at one of your fundamentals: to enable your team to do their best work at all times.
This is still only part of the story though. Yes the ‘protective umbrella’ and ‘informed prioritization’ are both important aspects but there are also other – more active – aspects of the role.
As much as it is about protecting your immediate team’s workload, it is about elevating good work, and encouraging people to ask the right questions, to make them go beyond what everyone around them thinks they are capable of. To do that you must define a vision and make people believe in it.
This helps them evaluate their work against that vision. Broadly this is often described as ‘leadership’ or ‘creating clarity’, but there are a bunch of specific actions associated with this. This is – however – something best covered in a separate article. So – now that I’ve got my personal context out of the way – let me follow this one up with a set of more structured articles exploring the Why’s and the How’s of Program Management. 🙂