2
Pillars of a Technical Program Manager
Throughout most of my professional career, I have been a technical program manager (TPM) – or a proxy to it. During this time, I have worked alongside other TPMs on large-scale projects, mentored junior TPMs on their journey, and I have interviewed a large number of TPMs from all corners of the industry. Over the years, I have adopted a considerable perspective on what a TPM is and what makes them successful.
Without getting into complex sentence diagraming, let’s take a look at the job title itself, Technical Program Manager. The title is comprised of two parts, the noun, program manager, and the adjective, technical. From this, it’s easy to see that there are at least two foundational pillars to a TPM. The program management and the technical skills. In my view, program management consists of two separate pillars since program management includes project management. You cannot have the skills to run a program without also having the skills to run a project. However, the reverse is not true – you can certainly have project management skills and not have the skills to run a program. So, that’s our third, and final, foundational pillar.
In this chapter, we’re going to dive a bit deeper into each of these foundational pillars by exploring the following:
- Understanding project management
- Diving into program management
- Exploring the technical toolset
Understanding project management
Before diving into the first pillar, let’s take a quick look at how the pillars support each other, as illustrated in Figure 2.1:
Figure 2.1 – The pillars of a TPM
Program management and project management are directly related to one another and complement each other within every program manager role. The program management phases and tactics build on top of the project management phases and tactics. And since a program involves multiple projects, they often share direct feedback, as risks at the program level can manifest at the project level and vice versa. The technical toolset supports both the program and project management pillars, as it provides the technical acumen to refine and more effectively utilize those skill sets.
To see how the three pillars relate to various managerial roles, we can look at Figure 2.2. The first two pillars are shared with other program and project manager roles. Nonetheless, they are an important part of our foundational skills:
Figure 2.2 – The functional overlap between the role of program managers and TPMs
Though we call ourselves program managers, a lot of what we do day to day, especially earlier on in our careers, is related to project work. So, we’ll start there.
Most of what we do is measured through our ability to deliver results, either directly or indirectly. Did we reach the milestone on time? Did we effectively unblock the low-level design quandary of our developer? Was the stakeholder looped in to help drive a discussion to the right conclusion? These are all different ways that we move a project forward, drive towards clarity, and ultimately deliver our goals.
In the project management life cycle, there are many opportunities to deliver results – not just within the project itself. At every stage, we are tested on our ability to take what is ambiguous, add definition, and refine it. We analyze risks and stop problems before they become problems.
In later chapters, we’ll dive deeper into the major stages of a project to see how a TPM utilizes their technical skills to effectively manage a project. For now, we’ll go through the general steps we take as project managers to successfully deliver our projects.
Exploring the typical project management tactics
We’ll go through a quick overview of the tactics used in a few of the high-impact areas of a project. These are the areas that utilize the TPM’s skills the most. They will be explored throughout the book in various levels of detail and with various perspectives on the tools and work they involve:
- Project planning
- Resource management
- Stakeholder management
- Risk management
- Communication
Let’s take a look at each of these in more detail.
Project planning
Starting with project planning, a project manager takes the given requirements and builds out a breakdown of the work structure and a work list, which then develop into a project timeline with dependencies, durations, and planned estimates. In many project management tools, these are simply a single artifact along with the resultant Gantt chart, though traditionally, this involves many different steps. In this regard, this seems to be a lot of time and effort, but a seasoned and well-prepared practitioner can get through this quickly. The amount of time and effort also varies depending on the size and complexity of the project or program.
During planning as well as throughout the project, we manipulate the project management triangle to get the outcome we need. We often see it depicted as an equilateral triangle (as in, all sides and angles are equal) that represents the trade-offs between the project scope, timelines, and costs – this is done to illustrate that to remain equal, any change to one side of the triangle necessitates a change to one or both of the other sides. For instance, if you lose people, the timelines grow, or the scope has to shrink to make up for the loss. Our day-to-day project negotiations are always tied back to the triangle and the trade-offs required to maintain the quality of the deliverable.
Figure 2.3 illustrates the project management triangle where scope, resources, and time are bound together:
Figure 2.3 – The project management triangle
As you can see, any change to a side length – which represents the number of resources, time, or scope available to the project – will require an adjustment to one or both of the other sides to maintain equal (or balanced) sides. Without this balance, you cannot ensure the quality of the project or program goal. We’ll cover this in more detail in Chapter 5.
The resulting project plan represents the vision of the project and is the basis for all the other stages that we’ll cover. This is the metaphorical blueprint that TPMs follow. The ability to craft and maintain a project plan may not seem super significant, but I am often reminded of the fact that non-project managers have a hard time reading and interpreting a project plan. This is our language. Without a plan, the project is doomed to failure, leading to reactive actions instead of proactive delivery. It can reveal poor planning or estimations, a project trending yellow as time slips, or a risk rising in probability. It is a living document guiding our path and the decisions needed to reach our goals.
Resource management
Resource management also pulls directly from the plan, as it lays out the type of resourcing needed at each phase of the project. Resources can include developers, user experience (UX) designers, software testers, vendors, contractors, and anyone else that is contributing to a task in the project plan. Conversely, this can also include hardware procurement, software installation, or other tangible needs of the project that are not people related.
Although this sounds straightforward, a project can very quickly stall if the right people and assets are not available when needed. How much of a problem this will be for you depends on how your company approaches resourcing and prioritization – it could be a constant struggle or a negligible one.
Stakeholder management
Stakeholder management, though separate from project planning, uses the plan to help inform the frequency and style of communication. In many companies, this style includes written status reports with varying levels of detail depending on the need of the audience, and meetings to convey the current status (which may or may not include a written report of the meeting).
A large number of teams may indicate a need for multiple types of stakeholder engagement – vendors likely require different status mechanisms to convey the needs or desires of the group than internal teams do. Each of these aspects plays into how the stakeholder communication plan comes together. Being consistent and reliable here instills confidence in your executive sponsors and leadership that the project is headed in the right direction.
The frequency can vary based on the number and type of stakeholders as well as the complexity of the project. For instance, a plan with tight timelines, or a lot of dependencies, may warrant a more frequent communication cycle to help ensure the project stays on track by surfacing problems more quickly to the relevant groups.
Risk management
Risk management, or the identification of risks and the strategies that are planned to handle them once realized, is one of the most powerful cycles in managing a project. It touches all other aspects of the project that we’ve talked through because a risk – or opportunity – can occur anywhere! To that end, every management cycle also has risk identification and assessment as well as tracking embedded into the work being done. A good project manager never stops thinking about risks and opportunities. We see risks from a mile away and hone in on them when they become relevant. We don’t let them alter our course, as we have already planned a course correction.
Communication
The key to all of these aspects of project management is communication. Without it, none of these cycles carry weight or value – you share your intended plan with stakeholders, you work with your teams for resourcing, and you discuss and analyze every risk you can think of. This is also true when working with your development team – you listen to them, understand their needs and concerns, and act upon them. In short, communication amplifies cohesion and is a vessel for transparency.
A well-written status report conveys urgency where needed and demands action. It calls attention to problem areas and aligns everyone on the next steps. It lays out all the risks so that when an issue does arise, it isn’t a surprise. It instills confidence in your ability to deliver the project in all the right people.
Now that we’ve discussed project management and the typical tactics that we use while executing the project, we can take what we’ve learned and scale it up to program management.
Diving into program management
As you progress in your career as a TPM, your scope and impact will increase. One way in which your scope will increase is through running programs. Instead of just the day-to-day operation of one project, you will manage or oversee multiple projects with a shared goal.
What is a program?
As discussed in Chapter 1, a program is a combination of multiple projects, often spanning multiple years, that achieves a common goal. Each project may have its own goal, but it will also contribute toward the goal of the program.
Though seemingly straightforward, let’s take a look at it from the perspective of a large, multiple-month project, instead of a program. The first thing you would do is break the project up into smaller deliverables, or milestones. Each of these should deliver a feature or functionality that, when put together with all the other milestones, achieves the goal(s) of the project.
A program is very similar to this concept, but usually on a much larger scale. Instead of a multi-month single project, the end goal may take multiple years. Each of the milestones may be different enough to warrant different personnel or strategies. In that sense, each of these becomes a project in itself (with its own milestones) that spans the program timeline. They all come together to deliver the goal of the program.
To better demonstrate this concept, let’s take a look at a visual representation of a program and the projects that comprise its body of work:
Figure 2.4 – A project versus a program
In Figure 2.4, a program has three planned projects, A, B, and C. All combined, the projects span the life of the program. Each project has its own end goal and its own internal milestones (which are not pictured). Notice that just as with tasks within a single project, not all the projects within a program start at the same time and can vary for the same reasons – whether resource constraints or internal and external dependencies. For this program, there are also program-wide milestones being tracked that align at different stages across the projects – project A’s end goal and the second program milestone are the same. A program-wide milestone can help provide cohesion and context across teams, driving better alignment for the program.
Now that we know what a program is, let’s explore how we use our skills to drive and manage a program through its various phases.
Typical program management tactics
As a program manager, technical or otherwise, the approach toward managing a program is similar. The stages are the same as they are for a project, just on a larger scale, which leads to changes in the skill sets and approaches at each stage.
Project planning goes from determining a single project plan for a single set of requirements to multiple sets of requirements and plans all contributing to the same end goal. The coordination and effort involved at this level increase as the number of projects increases.
Unlike a typical project where the planning stage happens once, the planning stage of a program iterates as projects open and close. Though a singular plan is created in the beginning, multi-year programs will revisit the planning stage often, as projects come into better resolution as they get closer – similar to how planning the estimates for a task in the work breakdown structure is more refined once the breakdown of the task is understood better.
With multiple projects, there are often multiple leaders or drivers, each maintaining their own plan schedule that ties into the program plan schedule. This, again, is similar to a project plan but with a larger scope. A project’s plan is overseen by the TPM with input from the people doing the work (developers, system developers, and so on) as far as estimates for the tasks are concerned. Further up, the program is overseen by a TPM with input from other TPMs, PMs, and SDMs with estimates and timelines for their respective projects.
Stakeholder management is similar to project planning in terms of the increase in scale from project to program level. Where a project may move quickly and warrant a bi-weekly status update, a program may have a status update monthly or quarterly. The goal here is to let stakeholders know that the program is moving in the right direction. This could be that each project is delivering the right thing at the right time, or that a problem exists, and the right measures are being taken to correct it. In this scenario, the high-risk items from each project are showcased in a report, as opposed to listing all the risks when sending a status at the project level.
By now, you can follow the general pattern of project versus program – scope and communication complexities both increase at the program level. The same can be said for risk management as well. A program tracks the risks for each project within its scope as well as the risks present at the program level. These risks follow the same scope pattern; think of inter-project dependencies for a program instead of inter-task dependencies for a project. Depending on the type of organization, funding may be of greater concern within a multi-year program compared to a multi-month project. Projectized organizations, or companies that fund and tie resources specifically to a project, may treat the program as a singularly funded entity for its life span. However, in the tech industry, funding tends to follow a yearly cycle more often. Within a given year, the funds are often fixed to the project, but priorities are re-evaluated yearly, and projects may be re-prioritized or de-funded as other needs arise.
The communication of risks, as alluded to in the stakeholder discussion, will often focus on high-risk items that are a threat to the overall program and leave the project risks to the project level. A good analogy here – and true in general for all aspects of program versus project – is the satellite imagery of a city. From 17 kilometers above the ground, the city shape as a whole is well defined due to the density differences between it and the surrounding area, but spotting the medical district as compared to the core of the city’s downtown is likely hard from this perspective. Zooming in closer to street level (around 4 kilometers), these distinct districts come into focus, yet the city-wide view is now gone. Next, zoom all the way in to the street level and you can discern one office building from the next, and one medical wing from another. Each of these views has its purpose but to see the full city, you have to lose this specific focus on a singular building or district.
Let’s look at a representation of a program-level status update as well as a status update from a project within that program to better understand how they connect:
Figure 2.5 – A program status update
Figure 2.5 shows the type of details the audience of a program status update might want to see at a high level. The concerns are at the program level and only items that impact the program’s critical path, or the sequence of dependent tasks that amounts to the longest time (and represents the minimum time in which a project can finish), are brought to light.
Figure 2.6 – A status update for Project A
Figure 2.6 shows a zoomed-in view of Project A’s status update. This goes deeper into the project to the development tracks, as those have more meaning at this level of granularity. A slip in a story’s delivery can delay the next story from starting, but may not impact the milestone, therefore having an impact at this level more than it would at the program level.
Now that we’ve covered both program and project management and their tactics, which are shared across all program manager roles, let’s discuss how your technical background provides you with the toolset to amplify your existing program and project management skills. This is the key to what sets a TPM apart from a generalized project manager.
Exploring the technical toolset
There’s a reason why the T comes before the PM. The technical nature of the position is what differentiates a TPM from a generalist program manager. The area of focus is so deep within technology teams and technology products that specialized knowledge is needed to properly manage projects and programs. To be clear, not all companies actually use the term TPM and continue to use the generalized PM moniker instead. Make no mistake, though – positions that involve dealing with technical teams definitely require a technical background.
As a TPM, you need to have some foundational knowledge in the technology space. We’ll go over the particulars across the industry throughout Part 3 of this book, but in general, that background should afford you some intermediary knowledge in software or hardware engineering. Although some jobs may cite a specific type of degree (for example, computer science), related degrees and experience suffice in many cases. At the end of the day, if your technical toolset allows you to navigate technical teams, technical requirements, system diagrams, and planning, then you will succeed.
Earlier in this chapter, we went over the general skills and tools that a generalist program manager utilizes. These tools are great to ensure the proper delivery of a program or project across a wide range of disciplines. Now, we’ve learned that a technical background is key to the success of a TPM. Next, we’ll learn why this technical toolset is so effective.
Discovering the effectiveness of your technical toolset
While studying for my Project Management Professional (PMP) exam, the course instructor stated that the skills I would learn would allow me to walk into any job that requires a PM and perform the job. If that were true, why is there a need for a specialized PM in technical situations? Trial and error!
The tech industry hasn’t always had a TPM role – and as stated earlier, not all companies use the term, even today. However, over the last few decades, it’s been shown that a program manager who understands the jargon, complexities, estimations, and designs of the software and hardware world leads to a more productive and successful program manager. The more successful the PM, the more successful the program, and thus, the TPM is brought in!
This doesn’t just apply to the tech industry. You certainly could take your PMP certification and walk onto a construction site management office and apply for a program or project manager position and get the job. You would have the skills, as you would understand the PM lingo and processes. You could effectively handle change management, stakeholders, and multiple dependencies. However, you’d struggle because you don’t understand construction at the level needed to be most effective. You might be able to manage a plan and reason out a good course of action, but it will take you longer to notice risks, mitigate issues, and estimate properly because you don’t have the knowledge and experience for this. Over time, you’d learn patterns and standard behaviors that would accelerate your performance but every nuance within an unknown situation would slow you down.
Experience in the field you are managing is invaluable to your success.
If you have developed software in the past, you will have a good understanding of the software estimates that your developers give you and can challenge the estimates when needed. Your understanding of architectural landscapes and system designs can help you see how multiple projects fit with one another – how one project’s design may cause risk through interference with another, or allow you to realize a positive risk, where two projects in a program share design elements and can thus shave development time off one or both projects.
Here’s a real-world example that might be closer to home for you from my professional software development days, where experience in your field matters. My first job as a developer was at a geochemical laboratory writing software applications to interface gas chromatographs and Total Organic Carbon (TOC) analyzers, among others, into a central lab system for analysis and reporting. My first degree was in geology, and I programmed as a hobby, so it was a natural fit to use my university knowledge to help me in my software development. At the same time, I was fortunate enough to have a desk right on the other side of the lab wall. I could see my applications in action, run tests, and be called upon by lab technicians that had a problem with the patch I had just pushed to their machines.
I had meaningful interactions with the lab technicians and actually understood their problems because I understood their domain: oil. Sure, I had to learn the analysis side and the nuances specific to the tests and situations in the lab, but my foundational knowledge set me up for success in that role. Near-instantaneous feedback imprinted the concept of customer focus into me. It also beat the concept of customer obsession through near-instantaneous feedback into me.
Later in my career, when I switched to a TPM role, I started on a team that specialized in updating services to be compliant with import and export laws. I knew nothing about the compliance domain but spent two years with the team learning the services, as well as the intricacies of import and export legislation worldwide. When I switched companies, I was able to pick up the business domain of my new team – tax law – very quickly due to the legislation knowledge I had built up previously. Just as in the geochemical lab, where I used my geology background to help my application development, the tax and legislation knowledge helped me contribute more quickly and more effectively to the tax projects. Finding gaps in the requirements or requirements that needed clarification was easier, as I understood the context of the requirements to start with – I talked with developers about what changes were needed, and how they would allow them to work faster and with more confidence that they were building the right solution.
All of this is to say that a proper foundational knowledge, or toolset, can accelerate your productivity and general efficiency at your job. Could I have written those applications without a geology degree? Yes. Was I faster, more focused, and able to provide a better customer experience because of my background knowledge? Absolutely.
These tools enhance your existing PM skillset and allow you to apply situationally specific intentions to make all aspects of execution smoother and quicker.
Summary
In this chapter, we learned about the three pillars of a TPM: project management, program management, and a solid technical foundation. We learned about project management as a common ground for all program and project managers and touched on the aspects of project management where the PM adds the most value.
We learned about program management being an expansion of the project management foundation and how the tools and phases involved are the same as at the project level but with a larger scope and more complex communication. We discussed how communication is key to all of these exercises.
Lastly, we talked about what specialization can do and how a specific focus can amplify your existing program management skills to deliver with greater ease and proficiency.
In Chapter 3, we’ll continue to explore program management in more depth. We’ll talk about the specific methodologies that can be used in the various program and project phases. We’ll also look closer at the intersection of project and program management.