My personal experience as a Program Manager and switching back to development

Switching back to the light side of the force: becoming a developer again

I recently transitioned from Program Manager on Microsoft Graph to Software Developer in the Microsoft Graph SDKs team. I’d like to thank my previous team for welcoming me these last 7 months and allowing me to experiment with the role of Program Manager.

I thought I’d share with you some of my experience and learnings as a Program Manager. Before you dive in, keep in mind this is my personal experience, which may differ a lot from team to team, product to product and depend on other circumstances (being remote, cultural, etc…). Do not take this article for a single source of truth, there are other experiences that have been shared out there.

What is a Program Manager anyway?

I’ve been asked this question multiple times, either by friends and family who do not work in technology, or by peers from the community who are evaluating joining Microsoft as a next step in their career. Quite frankly, I don’t think I understood the role very well before starting in this role. I’ll do my best to answer this question with my current understanding. A Program Manager is a mix of the following roles:

• Product Manager from the “silicon valley” traditional sense. Product Managers are dedicated to growing an idea into a full-blown product by designing the best functional solution and user experience. Product Managers focus on understanding the customers’ underserved needs, identifying the opportunities hiding in those needs, prioritizing which opportunities to pursue, coming up with the requirements, experimenting with markets/users, and adjusting the strategy until success is met (however they defined success).
• Project Manager who focuses on planning, finding resources, and reporting status of a given project.
• Scrum Master who focuses on getting the team organized, removing any blockers, grooming the backlog, and achieving the most efficiency at delivering.
• Software Architect who’s responsibilities lie between understanding complex problems in order to come up with elegant solutions and between making sure the technical direction to solving these types of problems is well understood by the development team. (this one may only apply if the “product” you’re working on is technical, like an API or developer tools)
• People Manager who’s responsibility is to motivate troops, cascade down strategic decisions and aggregate signals in order to report up. Without direct authority, only influence, targets of your influence often have dozens of other people trying to influence them to do other things.

Ultimately, a program manager is responsible for pointing in which direction, at what pace, and in what conditions the broader team should go. PM’s make sure all the different teams understand why it is important to go in a specific direction, and that every actor is coordinated with the group.

What does a Program Manager do?

PM’s mostly attend meetings and send emails (sometimes simultaneously). Putting together presentations and specifications is also a big part of the role.

Jokes aside, I’ll describe the typical lifecycle of a feature, but keep in mind a PM has multiple “programs” (features) going on at any given time, all of which at different stages.

1. PMs begin by exploring a product space and try to understand whether this space presents underserved need.
2. PMs try to confirm that “intuition” by talking with existing customers.
3. PMs try to confirm that “intuition” by exploring data/telemetry. (if available)
4. PMs design a solution, at a functional level. (go back to step #2 until the solution seems to serve that need on paper)
5. PMs try to understand and convince others of why it’s important to prioritize that feature over so many other features.
6. PMs communicate to the engineering team what needs to be built, they’ll come back with the how (technical designs) and when (estimates).
7. PMs run pilots with a select panel of customers to try out the MVP (Minimum Viable Product). (go back to step #4 until the feature is mature enough for a public preview)
8. PMs make sure the feature is properly documented.
9. PMs make sure the feature can be supported by support teams. (at this point you should be ready to run a public preview)
10. PMs advocate for the feature publicly. (blog posts, conferences…)
11. Congratulations! The feature should be Generally Available. Repeat.

It is worth noting that a lot of the strategic planning and team coordination follows the Objective Key-result methodology. If you’re interested in the role, getting familiar with this methodology will help you ramp-up.

Most of those steps involve meeting with people, a lot of emails/instant messaging, writing documents, grooming backlogs and more. If for some reason a peer team cannot help (understaffed, not geared for this problem space, other urgent priorities, etc…), it is likely that work will fall back on the PM.

Who do Program Managers work with?

This includes but not limited to:

• Engineering teams: they build the service and keep it alive.
• Marketing teams: they organize events, publish blog posts, and make sure people outside of the company know about the product/feature.
• Support teams: should customers experience issues with the features, they are the first line of defense.
• Documentation teams: they make sure that whatever solution the team came up with is properly documented in a way that’s easy to understand by anyone. They also make sure that whatever cryptic language Vincent writes in turns into intelligible English. (apologies to you my dear readers)
• Customer Experience teams (CXP/CPX): because a PM does not have time to talk to all customers, they are in continuous conversations with select customers to understand what’s missing/blocking adoption and aggregate that information for the PM.
• Legal Teams: they make sure that solutions being built are ethical and respect the law.
• Security Teams: they make sure that solutions are designed so customers and their data stay safe.
• Other PMs: because any feature must integrate with other features/relies on lower-level features, the people in charge of coordination need to coordinate among themselves.
• Management: report progress, plan the upcoming quarters etc…

My personal experience

Besides the more generic learnings I have outlined above, I’d like to share a few other details from my personal experience.

I started as a Program Manager back in January 2020. My immediate team of Program Managers was fairly new¹ but it was paired with engineering teams who have been working on Microsoft Graph for a long time, some of the engineers since the beginning.

Office Culture

After two weeks on site I went back home and started working remotely. One of the first differences I noticed was the strong in-person office culture. People were used to going to in-person meetings, popping at each-others desks or simply chat in the corridor for a lot of conversations. This was especially surprising to me for two reasons:

1. I had worked for the past 3 years at a company which didn’t have any office, and I was naively expecting that a remote and asynchronous way of working had become the global standard.
2. We have multiple team members in Nairobi, Kenya and the company is globally distributed. How can an in-person culture work at all in that context?

The in-person way of working came to a sudden change when the pandemic started in mid-February². I could see my colleagues struggling to adapt to working from home while rebuilding a family routine at the same time. Even though this leveled the playing field and changed the culture for the better in my opinion, it has been a rough way to transition for most team members.

Responsibilities and achievements

Approximately at the same time, my team was starting to organize areas of responsibilities and I inherited change notifications, change tracking, and throttling.

During my time as a Program Manager, I’ve helped the team deprecate TLS1.0 and 1.1 for change notifications, deliver support for change notifications and change tracking for new entities, twice, move change notifications with resource data to general availability, bring Azure Event Hub delivery mode to public preview, publish more detailed throttling information, and co-presented a session at build.

Retrospective

A positive aspect of the Program Manager role is the bigger impact: as you spend time coordinating people instead of doing the work yourself, you achieve much more as a team than you would ever by yourself. This aspect comes with two major trade-offs:

• As you’re further away from production, it becomes much harder to feel like you’ve accomplished something.
• The constant communications leaves little time to focus on something.

I really enjoy writing code because as I do that, I get to be “in the zone” solving problems. At the end of the day I also get “concrete” results and a feeling of accomplishment.

Drinking from the firehose

As a program manager I received about 60 000 emails and sent about 2 500 emails in 7 months. My trick was to move any email that didn’t need my attention (and which really shouldn’t have been sent to me at the first place) in a temporary folder. Every Friday I’d spend whatever time it’d take to setup automatic rules ranging from “move it to this folder, keep it unread” to “delete it and mark it as read” saving me from reading more than 90% of emails over time.

Some insights from MyAnalytics:

To be clear: I’m not casting any judgment on those activities, spending less time on communications and more time focusing better fits my personality.

Conclusion

That is the conclusion I’d like to finish with: before taking a new role, make sure its core aspects fit your personality. Learning new skills is easier and faster than changing who you are at your core.

I hope this article answers some questions from those of you who have been curious about the role. I’m thankful that Microsoft has given me not only the opportunity to explore the program manager role but also allowed me to transition back to development.

Footnotes