Program management 101

What is a program manager? How is it different from a product manager? How about project manager? And what differentiates a “technical” PM from a “non” technical one? These are all questions I get asked often, so I’ll attempt to avoid repeating myself (and clarify my own thinking) by summarizing my thoughts here.

As you read on, please do keep in mind that there is no “one true answer” to this question. Product and program management can vary wildly across industries and even across companies within the same industry. This can lead to quite a bit of confusion!

My thinking is informed by my own experience with program management at both Google and Apple, my experience interviewing hundreds of program managers from other companies as part of my role, and my experience interviewing at other companies which gives some visibility into how those companies operate. That said, my experience is by no means universal and should be taken as one data point.

There are likely to be as many opinions about program management as there are program managers – as a group we tend to like analyzing things, breaking them down, then framing and re-framing them in ways that facilitate understanding and actionability. Doing so is something of an art, and all true artists have their own “style”.

So take all of this with a grain of salt. With that said, I hope that some will find this helpful. It may be useful for someone considering a program management role for the first time, or perhaps a  junior program manager leveling up their skills. Heck, even experienced program managers may find value in looking at things through a different lens. Let’s begin.

Project vs. product vs. program

Out of the three (project, product, program), project management is probably the most universal and accessible idea to most people. In my view, every single person  in the modern workplace  is a project manager, whether consciously or not. A project could be thought of as a set of work consisting of more than one task, completed over a period of time, with a well-defined end state (“definition of done”).

As you can see, most knowledge work falls into this rubric. If you have ever written down a list of tasks you need to do in order to complete something, and then checked them off as they were completed, congratulations! You are a project manager in the most basic sense.

Some companies, but not all, have an explicit “project manager” title and role. The only difference between this person and everyone else is that this person is able to dedicate 100% of their time to project management, while everyone else has to do it alongside their core role. This allows the project manager to take on more projects, larger projects, and longer term projects.

Product management is about discovering and defining what needs to be built, and perhaps more importantly, why. The product manager seeks to understand the user and the market dynamics at play, and translate that into a product vision that enables the company to capture its share of the market opportunity.

Product managers pull from a broad skill set – on any given day, they may be conducting market research, talking to a strategic partner, writing detailed requirements, or establishing success metrics. Product managers are focused on building the best product and user experience possible for a specific product line or area. They are focused on the outside world and how the company can best meet the needs of that outside world.

Program management differs from product management in that the object of focus is internal rather than external. For program managers, the company itself, and the people and processes within it, is the “product” that we are working on. We work to build alignment across teams, establish roadmaps, drive execution, improve communication, anticipate and mitigate risks, and ensure accountability across multiple teams.

A program manager’s scope spans across many products and projects simultaneously. The choice of focus is dictated by the business – and usually will be in support of an overarching strategic area for the company. Program managers tend to own areas of the business that have high urgency, complexity, and/or risk, and their specialized skill set enables them to execute and deliver in these areas to produce business value.

Now that we understand what program management is, let’s dive into details. A program manager has a number of spheres of influence. These can be broken down as:

Objectives

Clear objectives ensure everyone understands the program purpose. This can be achieved with a clear vision, a detailed roadmap, and a way to measure results.

• Vision: What are we doing and why? What is the overall goal or mission of the program? The vision lays out a shared context and purpose for the program. We may be solving an operational, technical, legal, engineering, product, marketing, service, or sales problem. What impact is this problem having? What will this problem look like in the future, with the aid of this program? The vision should answer these questions and inspire the team.
• Roadmap: How will things change over time? What can we expect next quarter or next year? Who is working on what when? Estimate and visualize the work according to work streams. Break down the work into milestones. Identify and resolve dependencies and conflicts.
• Results: How will we measure success? What outcomes do we expect and what is the impact of those outcomes? Use specific and quantifiable metrics to demonstrate business value. Hold retrospectives to jointly review results and suggest improvements.

Stakeholders

Understanding stakeholders and how to manage them is a core function of program management. Stakeholders can be thought of as those who have an interest in the program. The reasons for this interest can vary.

Examples of stakeholders are:

• An executive or set of executives who sponsor (pay for!) the program
• Cross-functional teams whose work is impacted by the program
• Individual contributors on the various project and product teams
• Horizontal functions like finance, legal, privacy, security, etc
• Partners, vendors, or key customers

Each of these stakeholders comes to the program with a unique set of expectations and degree of interest. It is the job of the program manager to elicit and understand these factors in order to tailor the program to meet the needs of a diverse set of stakeholders.

The program manager accomplishes this by doing things like:

• Establishing and growing relationships directly with a tailored group of key executives
• Providing vision, leadership, and mentorship to individual contributors
• Identifying and managing vendors, suppliers, or strategic partners
• Communicating status broadly and consistently

Ideally, in order for a program to operate credibly, it should have a formal charter that is approved (ratified) by a core group of stakeholders. The charter lays out details of the program and covers much of the information discussed in this article.

Constraints

• Scope: What will and will not be included in the program?  Be explicit about what is within scope (for example, engineering and product development) and what is out of scope (for example, operations) for a program. A program should be tailored to achieve a specific strategic goal. Most projects do not need a program manager. Be judicious and thoughtful in how to apply program coverage.
• Priority: What order do things need to be done? How quickly do things need to be done? Identify the critical path and any dependencies to resolve. Some tasks can be done in parallel and others must be done in sequence. Map out teams and work streams over time to visualize what will be done first, second, third, etc. Establish shared definitions of P0, P1, and P2 priority.
• Resources: What people, tools, and assets are available? Ensure adequate coverage across needed skill sets. Estimate resource needs by individual, team project, and product line. Include testing and operations costs. Do not pad resource requests or request buffer resources, instead ensure scope and priority match resource realities.

Teams

Program managers must keep hybrid teams accountable for delivering on their commitments. One of the ways they do this is by establishing roles and responsibilities, and recognizing good work.

• Roles: Ensure roles are clearly defined. What level of commitment is necessary over what period of time? What is expected in terms of deliverables? Ensure responsibilities are understood and agreed to. List the role in the program charter with the person's name and have them sign off on it.
• Recognition: A program manager should reward good performance by praising team members who are delivering value. Highlight the achievements for their managers, directors, VPs, and cross functional stakeholders. When someone is performing well and is critical to the success of your program, make it known.

Status

• Summary: Use simple color schemes to visualize status (red-yellow-green). Keep a list of open issues that require a decision or executive attention. Report top-line metrics for each line of business.
• Risks: Identify potential risks in the areas of engineering, product, operations, and legal. Identify a comprehensive set of mitigations to identified risks. Use a probability vs. impact matrix to quantify and order risks.
• Escalations: Call out decisions that need to be made, especially when executive attention is required or the decision is blocking something from happening. Call out ad-hoc resource requests with justification.

Skills

A good program manager will have a blend of interpersonal skills and domain-specific or technical knowledge.

• Interpersonal: Communication is central to everything a program manager does. Relationships ensure your message is trusted and understood in context. A program manager acts as a neutral third party. As such, adopt a diplomatic presence. Consciously use body language and tone to convey an additional layer to your communication.
• Technical: To be considered 'technical' a program manager should have an equivalent level of technical knowledge as a practicing engineer in the field. Technical program managers are commonly seen in the fields of software (web, mobile), cloud (platform, infrastructure), and hardware (compute, memory, storage, networking, devices) .
• Domain-specific: Some program managers specialize in security, privacy,  risk, legal, marketing, UX, or other specific domains. Each of these domains has its own specialized terminology, and plays a different role in the business. Domain-specific program managers become experts in their field over time.

Culture

• Respect: Fostering a culture of mutual respect across the organization is a critical function of the program manager. They do this by approaching conflict with a neutral perspective, increasing connection across teams, being open to feedback, adapting, and assuming good intent when mistakes occur.
• Transparency: Executives do not like surprises. Give them previews and rehearsals of important communications, decisions, or meetings. Prepare them with background material, summarized context, and 1-1 discussion prior to engaging in critical meetings. Adopt a postmortem culture that does not assign blame.
• Leadership: A culture of leadership is fostered first through demonstration. Every program manager is an example for everyone they encounter in the organization. The program manager should exhibit the same qualities that they hope to inspire in others. Find opportunities to mentor other program managers directly. Find opportunities to learn from your own mentors.

Meetings

A special note on meetings.

Everyone loves to hate meetings. The truth is, unless there is a structure or purpose, meetings quickly descend into a big waste of time. On the other hand, meetings can be useful and productive when certain rules are followed.

In general, meetings are not a good medium for status updates or for one-way broadcasting of information. Using meetings as a primary mechanism to disseminate information is an anti-pattern and should be avoided.

Meetings are good for three things: 1) making personal connections, 2) identifying actions that need to be taken, and 3) making decisions. If none of these things happen, a meeting is generally a waste of time.

Consider the following regarding meetings:

• Accessibility: Don't be impossible to reach, but don't make yourself too accessible. Find the right balance based on your objectives. Set a high bar and only meet when it is truly needed.
• Agenda: A meeting must have an agenda, full stop. No agenda, no meeting. You should never run a meeting yourself without an agenda. When you run a meeting, the agenda should be sent out ahead of time, ideally the night before. If there are background materials to review, these should be sent ahead of time (day before or earlier) as well. If you arrive at someone else's meeting and find it is without an agenda, you should create an agenda as the first order of business, or disband and offer to meet again when there is a clear agenda.
• Attendees: Nobody should be coming to a meeting as an observer, everyone should be participating and contributing to the meeting. Take into account whether a particular attendee is necessary or not before adding them to the meeting. Don't ask potential attendees if they want to attend, because people will naturally feel obligated to say yes, even if it would not be that useful for them. Instead, identify a minimum quorum and make attendance mandatory.
• Timing: In general, you should meet sooner rather than later, and for the least amount of time necessary to move the program forward. Meetings tend to fill up the time allocated to them. When you have a very clear agenda and everyone reviews background material (on their own schedule) ahead of time, meetings should not take a lot of time. I schedule many 15-minute and 30-minute meetings. I rarely schedule a 60-minute meeting unless strictly necessary, and I always end meetings early when possible.
• Decisions: Decisions should be recorded, and sent out to the group in writing after the meeting. If anyone disputes a decision, they can take it up at that time. Maintain a ledger of decisions that have been made and need to be made. Do not allow indecision to derail a meeting. Either a decision can be made at the meeting, or not. If not, move on to the next agenda item.
• Actions: Action items should be identified and recorded during the course of the meeting. Maintain a ledger of action items, their assignee, and their status (open / closed). Follow up on open action items at subsequent meetings. Action items should be clear and specific. The owner of the action item should acknowledge their ownership of it and commit to taking the action.
• Notes: Notes should be taken during most meetings. The level of detail needed in the notes will vary based on the size, complexity, and importance of a meeting. Notes should capture important and relevant information discussed or discovered at a meeting. The importance and relevance of information is dictated by its ability to influence a decision or identify a course of action. Notes should contain information about the attendees, agenda, relevant discussion, decisions made, and actions identified at a meeting. Non-attendees should be able to read the notes and understand what was discussed and decided. Notes should be distributed widely to relevant teams and stakeholders to facilitate shared understanding and promote accountability.

Finally, if you need to run political or controversial meetings with many high level stakeholders, consider reviewing Robert's Rules of Order, the classic work on parliamentary procedure, for some wild ideas. ("Permission to speak, madam chair?" Imagine!)

PMO

• Charters: Once the program is defined, develop a charter and have program sponsors ratify it. Charter should include information about objectives, stakeholders, constraints, and teams. This document is like the birth certificate of the program that team members can refer to.
• Portfolio management: In a large organization, many programs, projects, and products are developed simultaneously and it is difficult to manage scope and resource assignment across all programs. Unify reporting across programs to summarize at a portfolio level. Adopt a process for assigning engineering and product resources to programs.

In conclusion

As you practice and develop your craft as a program manager, you will begin to form your own structure and framework for how you think about things. The above is my own, incomplete and imperfect as it is likely to be.

It is my hope that by sharing my thinking and structure with you, you might use it as a spring board, and a tool to help your own even greater understanding.

If you are a new or aspiring program manager, please do not hesitate to subscribe for more, and connect with me on Twitter or LinkedIn. I have helped a number of software engineers and others make the jump into program management.