Nine things a (technical) program manager does

_posts/2021-03-21-n-things-a-technicalp-program-manager-does.md

@@ -0,0 +1,99 @@
+---
+title: Nine things a (technical) program manager does
+description: The nine most important things a program manager can do on any given day
+---
+
+After five-plus years as a Product Manager, I recently became a founding member of GitHub's newly established Technical Program Management (TPM) organization. Program Management is a new label for me, even if I'm finding that the underlying responsibilities are in hindsight, long familiar. So day-to-day, what does a Program Manager actually do?
+
+### Program manager vs. Product Manager vs. Project Manager
+
+"PM" is an overloaded acronym within the software industry, with the easily confused roles it represents both overlapping and varying drastically from organization to organization. Before we jump into things, here's a brief "PM" disambiguation:
+
+#### Product Manager vs. Program Manager
+
+I've [written before](https://ben.balter.com/2016/06/06/twelve-things-a-product-manager-does/) about what a Product Manager does. In short, a Product Manager is customer focused while a Program Manager is execution focused:
+
+* **Product Managers** - Product Managers are responsible for understanding the needs of customers and distilling those needs into a prioritized list of product requirements. Depending on an organization's size or maturity a Product Manager may take on some program (or project) management responsibilities, but it's generally not their core function.
+* **Program Managers** - Program Managers are specialists of and are responsible for the cross-functional and cross-organizational planning and coordination, risk management, and process tracking that gets the product out the door. Program Managers may inform product decisions, but they do not directly shape products or features.
+
+#### Program Manager vs. Project Manager
+
+In the traditional sense, a program manager is a people manager that manages one or more project managers. More recently, you'll see program managers that manage a collection of inter-connected projects, even if the program managers themselves don't have direct reports. Program management versus project management can often be seen through the lens of strategic versus tactical, but there is no bright line between the two as more senior project managers naturally take on more simultaneous projects or more complex projects which can often be seen as (or become) full-fledged programs.
+
+#### Program Manager vs. Technical Program Manager
+
+In short, Technical Program Managers are technical. They don't write code on a day-to-day basis,[^1] but they are at home rolling up their sleeves and diving deep into technical discussions alongside engineers and other subject-matter experts. A technical degree is not strictly necessary, but TPMs are systems thinkers that have a keen understanding of the product and the platform, and may have previously been an engineer or a product manager for a highly-technical product. Again, like project management, there's no formal distinction here, but suffice to say TPMs generally self-identify as technical (even if, like technical product managers, it's not always reflected in their title).
+
+#### What a technical program manager is not
+
+To be clear, TPMs are not the one *primarily* responsible for a program's success. Depending on your organization, those individuals may be assigned titles like "PRP" (primarily responsible person) or "DRI" (directly responsible individual) and often come from Product Management or Senior Leadership roles. The TPMs work closely with and support those individuals, but play a very distinct role. A program manager is responsible for the program's successful *execution*.[^2] As such, TPMs rarely, if ever, make program decisions, and instead, bring PRPs/DRIs the context they need to make those informed decision themselves.
+
+Namespace conflicts aside, 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, whereas it's 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](https://ben.balter.com/2016/06/06/twelve-things-a-product-manager-does/) 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:
+
+1. **Communicating** decisions and other key updates that may affect other teams
+2. **Coordinating** dependencies and other inter-related efforts across teams
+3. **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
+
+Whereas 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 brining light to a problem area or unmitigated risk for fear of appearances of disappointment, but increasing visibility irregardless 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.[^3] 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. 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, 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. 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.[^4] 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 tradeoff determinations and allocate resources properly.
+
+### 8. Boundryless 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 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. 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
+
+All that said, the TPM role is still in its infancy at GitHub, and I'm confident it will continue to evolve as the organization grows and matures, as there's much, much more ways TPMs bring value to a program and to an organization as a whole.
+
+[^1]: Successful TPMs may find themselves regularly writing non-production "manager code" to automate common administrative tasks and help scale their own efforts.
+
+[^2]: As an example of this distinction, TPMs should ensure that product managers have all that they need to ensure that we're bringing the right product to market, targeting the right customers, and at the right time. If ultimately the product fails to find a product-market fit due to its feature set, its priced too high, or gets the go ahead to launch with a few too many bugs, those decisions are on the program/business owner, not on the TPM.
+
+[^3]: 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.
+
+[^4]: 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.