Nine things a (technical) program manager does

TL;DR: Technical Program Managers are responsible for communication, coordination, and facilitation, capturing and tracking the work that needs to be done, identifying, analyzing, and mitigating program risk, reporting up and across, managing relationships, resolving conflict, driving consensus, boundaryless engagement, and doing what needs to be done.

7 minute read

After five-plus years as a Product Manager, I recently became a founding member of GitHub’s Technical Program Management (TPM) organization. Program Management is a new label for me, even if I’m discovering in hindsight that the underlying responsibilities are often long familiar. Not having a formal Program or Project Management background, as I’ve been settling into this new role, I’ve been taking notes and critically thinking about what a (Technical) Program Manger does day-to-day, and how they uniquely bring value to a team and to the organization as a whole. A few months in to this exciting journey of discovery, here’s my list of the nine most important things a program manager can do on any given day:

1. Communication, coordination, and facilitation

Although the role may have some functional overlap with Product Management, while the skill may be a “nice to have” for a product manager, program managers specialize in cross-functional and cross-organizational communication, coordination, and facilitation. As I wrote of product managers a few years back (with slight modification):

Your team should focus on shipping. You should focus on all the meta-work necessary to create the space that allows that to happen. That means memorializing synchronous meetings, shuttling information to other affected teams, and coordinating cross-team efforts (and overcoming any organizational friction that may arise as a result). At GitHub, [we’ve used the term] servant leadership. As a [program] manager, your job is to provide your team with the all political, yak-shaving, and unblocking air cover necessary so that they can focus exclusively on shipping. Make sure other teams know what you’re up to, are able to opt-in to additional context if they’d like, and harmonize any supporting or parallel efforts across the organization. You should be the most organized person on your team, and be able to tell, at any given moment, exactly what needs to be done to get the [deliverable] shipped (and to make sure that is exactly what happens).

2016 Ben packed a lot in there, but there’s three TPM-specific space-creating outcomes that deserve calling out here:

Communicating decisions and other key updates that may affect other teams
Coordinating dependencies and other inter-related efforts across teams
Facilitating your team’s work by ensuring they have the resources they need (unblocking)

2. Capture and track the work that needs to be done

Planning and tracking are a core competency of program (and project) management. What’s the universe of work that needs to get done for the program to be successful? When do we need to do the work by? In what order should we do it? Who’s responsible for each deliverable? Are there any external dependencies? Do we have everything we need? Once you have that work captured, it’s the responsibility of the TPM to track each work stream’s progress, to ensure the real-world work accurately reflects what’s planned and vise versa, and to tack and communicate each deliverable’s status.

3. Identify, analyze, and mitigate program risk

Product and Engineering Managers think in terms of problems and solutions. If there’s one thing that defines the shift from another technology role to Program Management, it’s the shift to thinking in terms of risks and mitigations.

At the end of the day, a program manager is responsible for the program’s successful execution. That means working with functional leads to tease out risks to each work stream’s success (risk identification), defining the problem space to understand the risk’s program impact (risk analysis), and finally identifying and implementing mitigations to minimize the impact of those risks and maximizing the chance of program success (risk mitigation).

4. Reporting up and across

If a TPM has one direct deliverable, it’s to ensure that there are no surprises. That means providing day-to-day and week-to-week, both passive and active situational awareness to leadership and to those directly and indirectly responsible for program deliverables. TPMs should make program execution seem boring, or at the very least predictable.

One unique aspect about being a TPM is that you’re directly responsible for program execution, not outcome. That means that you’re uniquely incentivized to report the no-BS truth on the ground, regardless of how good or bad it might be. Functional leads may shy away from bringing light to a problem area or unmitigated risk for fear of appearances of disappointment, but increasing visibility regardless of status is one of the easiest ways TPMs can bring value to a program.

5. Relationship management

I remember when I was starting my career, I’d see managers setting up “just wanted to say hello”-type meetings with other managers, and I dismissed the behavior as socializing on company time. It turns out that’s exactly what it was, and that’s also exactly the point. It also turns out that humans are complicated social beings. We should always begin from a place of trust with our coworkers and seek to collaborate when appropriate, but the truth of the matter is that programs are more likely to succeed when interactions are relational, not transactional.¹ Don’t be the person your colleague only hears from when you need something.

TPMs form relationships of mutual trust, understanding, and respect with key stakeholders and contributors, making regular deposits to the social capital bank before they need to make a withdrawal, rather than being forced to take on social debt, to stretch the metaphor. Those relationships lay the groundwork for establishing communication patterns and working styles, reduce formality by making it more likely that gaps can be naturally filled in and ambiguity resolved favorably in casual conversation, and generally means you’re working with a fellow human, not a detached avatar, along with the empathy and willing-to-go-out-of-your-way-ness that comes with it (also known as your “sphere of influence” in more-formal terminology). Not to mention, connecting and working with people whom you know and appreciate make the potentially isolating role more fulfilling.

6. Resolve conflict

Conflict avoidance is a natural outgrowth of relationship-driven organizational culture. When you work with someone on a regular basis or depend on them for the success of your own deliverables, it’s understandable not to want to wade directly into a potentially volatile subject, real or perceived. But teams do have divergent (and often conflicting) priorities. Individuals do make mistakes and communicate imperfectly. Ambiguity does often arise where responsibilities overlap and teams interface with one another. Sometimes people just plain don’t like each other.

As a TPM, your role is to force those tough conversations, to bring things out into the open, and problems into the light. TPMs can play the role of the trusted third-party that can facilitate a productive and solution-oriented conversation on neutral ground where all parties feel heard and their interests represented. This takes groundwork ahead of time to build the trust and relationships and a level head in the moment to keep conversations focused on the program’s success.

7. Drive consensus

As a product manager, I regularly used terms like “alignment” and “clarity” to describe communicating and socializing a product vision. The goal was that everyone from leadership to individual engineers implementing a feature understood the bigger picture and the overarching problems the product was intended to solve for customers. As a TPM, I’ve built on that vocabulary, using the imperfect term “squishiness” to describe the exact opposite: program ambiguity.

It’s the TPMs responsibility to reduce program (and work stream and deliverable) ambiguity. That means ensuring everything (and I do mean everything) is documented, discoverable, and socialized.² When you spend every day in a space, it’s easy to reduce things to shorthand or hold quick huddles in Slack, but when programs span multiple functions, enumerating plans in explicit long form can go a long way to tease out interdependencies, yet-to-be-made decisions, and overall, create a greater sense of cross-team coordination (“unknown to some” ambiguity). Often times that comes in the form of going two or three levels deeper than a functional lead might first present a plan or like.³ The other form that comes in is in surfacing decisions which need to be made, and ensuring decision makers have the information they need to make trade-off determinations and allocate resources properly (“known unknown” ambiguity, often captured in a risk register).

8. Boundaryless engagement

One of the most defining aspects of a TPM’s role is that the TPM’s scope is organization-wide and boundaryless. What I mean by that is that TPMs are empowered to, and should feel comfortable going to where the program’s work is, regardless of organizational lines or corporate hierarchy. In a given day you might interact with senior leadership and individual contributors (SVPs to junior engineers) across multiple functions (Sales, Legal, Finance, Support, Marketing, etc.), and that’s what makes the role so uniquely effective.

This ability to move freely throughout the organization allows TPMs to bring value by surfacing and resolving cross-functional program dependencies (“connecting the dots”) and to catch issues without clear ownership, especially where organizational lines intersect.

9. Doing what needs to be done

Ultimately, it’s the TPMs responsibility to do whatever needs to be done to ensure the program’s successful execution. That might mean spending more time than you’d like copying-and-pasting from one spreadsheet to another on a given day, preparing nearly-identical updates in different formats for different audiences each week, or “brute-forcing” a one-off problem through more clicks than you can count. For better or worse (I think better), the TPM is the “catch all” for any problem, task, or deliverable that doesn’t have another logical owner (often because it spans or sits on functional lines). It’s not always glorious or fun, but it’s an integral part of the TPM role, and it’s another way TPMs uniquely bring value to a program and ensure its successful execution.

Conclusion

Over the past few months I’ve greatly enjoyed the opportunity to grow and learn from my peers, many of whom bring years of experience and formal training to the new-to-me role. As I first began settling in, I struggle to get a sense of what a program manager’s typical day looked like or what skills I should be focusing on day-to-day to bring value to my team. Here’s the list I wish I had as I was first stepping into the role, and I hope it helps others to do the same.

As much as I might like them to be, human-to-human requests, are unlike server-to-server requests. A properly authenticated request from a never-before-seen client is less likely to be fulfilled, or fulfilled in a timely manner even if its facially valid. ↩
If you liked it, you should have put a URL on it. ↩
I resist the urge to compare TPMs to dentists, due to often negative perception associated with “going to the dentist”, but “reducing squishiness” is not unlike a dentist poking around in your mouth to find the soft spots in your teeth. Nobody likes having cavities, but brief discomfort and early mitigation is much preferable to the alternative. ↩

Originally published March 26, 2021 | View revision history

If you enjoyed this post, you might also enjoy:

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit