I posted a while back on a job opening for a BCL PM position. We got a lot of great candidates in response to that post, and it was quite exciting to see the range of experience and backgrounds in the people who responded.
Now if you ever show interest in a job at Microsoft, and if you get past the first couple of hurdles, inevitably you'll do a 30 minute informational with a member of the team you're going to be joining. When we had the PM position available, I did a lot of those informationals, and I would always start by describing the position to candidates. I thought I would share my rundown of the position with you for two reasons: a) so you know what a BCL PM does, and b) so you can tell me what sounds cool, and what sounds pretty uncool.
A Base Class Library Program Manager, is fundamentally, a ‘Feature’ PM. That is, their primary role is the ownership of specific features within the BCL. For every feature in the framework, there’s a PM who owns the feature. System.Windows.Form? Someone owns that. System.Web.UI.Page? Someone owns that too. For BCL, the PM ownership of features is broken up amongst 5 people: 3 whom own a small chunk, and two who own a larger chunk (really just coming down to team logistics: the lead for the area believes that it’s goodness for everyone to own some feature area, since it keeps you in touch with the core technology, and the most fundamental PM role).
What features you own is generally a reflection of a couple of things: a) what desire/interest you have in a particular area (the fantasy check), and b) what simply needs to be owned (the reality check). Ownership is normally broken up at the namespace level (although every so often, a singe class or two can be called out, because their ownership can simply be handled separately). For example, I own System (the majority of: base types, Console, Math, Environment, a lot of exceptions, etc., but not things like AppDomain), System.IO (and S.IO.Ports, S.IO.Compression), System.Text.RegularExpressions, System.ServiceProcess, System.Resources, System.Timers (a huge burden), and two classes outside that scope: System.Text.StringBuilder, and System.Diagnostics.Process. Another PM simply owns System.Collections, and another owns System.Threading. This gives you an idea of the difference between a PM focused primarily on feature ownership, vs. owning a smaller amount of features, and doing other stuff too.
Now the inevitable question is: what does ‘ownership’ mean? Well, for each feature, there’s a dev, PM, and test owner. I’ll assert (probably because I’m a PM) that ultimate responsibility for a feature lies with a PM. At the end of the day, the PM for a feature needs to be the Subject Matter Expert for that feature (along with the dev and tester). Responsibilities include:
- The design of the feature (the API set)
- Defining how you’re expected to use the feature
- Triaging what bugs should, and shouldn’t be fixed for the feature
- Scoping, and identifying what work should be done on the feature in VNext
- Writing the specs, and threat models for the feature
- Writing presentations/whitepapers about the feature
- Ensuring the feature is in a shippable state
- Giving presentations about the feature area (or related areas)
- Reviewing documentation for the feature
- Answering customer questions about the feature
Timeline: For someone new to an area, I would expect that learning a feature area would be anything from 3, to 12 months. That is, if you were new to a PM role, then if you were lucky, you could be the expert in 3 months, but depending on the difficulty, it could take a year. For that period, I would expect that 100% of your job is simply coming up to speed on the role. At some point, you’ll find that you’re starting to get the area, and suddenly (ok, it’s because you have people on your *** all the time, asking you to do other things) you’ll notice you have some free time to be doing other stuff.
This is where things can get really fun, since what ‘other stuff’ you do can be largely defined by you. It should be something that at least your manager agrees is beneficial. But once you’ve agreed, you can go for it. Writing whitepapers, giving presentations, driving team wide processes, defining guidelines, creating tools, working with external teams to ensure their needs are met, it’s all good. Visibility is a big thing at Microsoft, so your manager will typically encourage things which get some good visibility. But the other focus here should be ‘pick something you think you’ll enjoy’. Believe me, you’ll be more successful at it if that’s the case.
Lowlights of the job: There’s points in the cycle, where there’s a lot of pressure, and the job can be pretty thankless. Your key job at these points is basically protecting the rest of the team from a lot of the sundry stuff that goes on, and if you do it right and they don’t see that stuff, then of course, they don’t know about it, so they don’t can’t appreciate it. At these points, stress can be high because you’re driving to dates, and you do NOT want to be the sub-team that seems to be lagging behind. At these points, you can often come across like the bad cop: but someone has to ensure you’re keeping on target and while that responsibility is certainly a team thing, at the end of the day, the PM should be the person metering that and making sure it happens.
A lot of the job for a feature PM can also be about triaging bugs and other process oriented stuff. It’s my experience that a LOT of people don’t like that part of the job. The reality is that if someone doesn’t do that, it tends to not happen, and then things can begin to fray, or even fall to bits. It’s an important part of the role, but not the most glamorous.
Highlights of the job: you get to decide (read: be part of the decision for) what happens within a feature area: and this is SO fun. From the decision on what features to do, to how they should be designed. If you like presenting (like I do) then that’s available to you. You get to write code, something which is always neat fun. And I would say above all else, you get to work with awesome people.