A Day in the Life
Posted by Tyler | Filed under Work
Frankly, I would have answered them long before now if I knew. In fact, even now, I really don’t fully understand the full scope of my position yet. I’ve been here nearly two months, and everyday I figure out something about my job that I didn’t know. I am still adjusting, not only to the job, but to life in the Puget Sound area and to the fact that I don’t really know anyone out here. Anyway, I could go on and on about that… This is supposed to be about the job itself…
Note: The thoughts I have here are my own perceptions of the Program Manager position at Microsoft, and are not, nor should they be considered, the Gospel truth about the PM position or working at Microsoft in general. This is what I have seen of how things work within my particular team. Things vary greatly even between different teams within Microsoft. On top of all of this, I have only been working at Microsoft for about two months. I know very little of what I’m talking about, and am by no means an expert, but lots of people have been bugging me for information, so I’m writing down my thoughts. The perceptions and opinions stated here are subject to change. :-)
Since this post is quite long (it took me over two weeks to type it up… I need to start brushing up the old typing skills if I’m planning on participating in NaNoWriMo again this year!), I am putting some handy links here, sort of like a table of contents. Some of this stuff is pretty dry, but I always try to be thorough, so skip through the boring stuff if you want. Just because I wrote it doesn’t mean you have to read it. :-)
As a PM, I own features. A feature is a specific functional piece of a product. For example, the spell-checker in Word is a feature. When it was designed, some PM wrote up a Spec that outlined the functionality, all the UI associated with it (the red squiggly line for example) – including screenshot mock-ups – and the scenarios in which it would be used. The spec also outlined how the feature was supposed to work. The developers worked off of that spec to implement the feature, and the testers worked off of the spec to test it. Basically, the PM is responsible for designing a feature and driving it to completion. This doesn’t mean we get whips that we can use on the developers and testers – they don’t work for us. We’re a team, each member with different responsibilities. The PM is the principal customer advocate. That means I have to think like a customer. Would the customer be confused here? Would they make a mistake because this is misleading?
As you can see, it’s also important that a PM be aware of what is going on in other areas of the product. For example, my feature may be similar to another feature that another PM is working on, with similar UI or something, and if I live in a cave and am totally oblivious to the state of other features and the product as a whole, then what I end up producing could… well… suck. :-) This, of course, means that PMs have lots of meetings.
Most days I have a meeting or two, or three, or… For the most part meetings are informal, and usually they’re pretty enjoyable. There’s a lot of different types of them too. For example, every week we have a Program Manager meeting, which is all the CMS PMs and Gerhard, our Group Program Manager (GPM). Sometimes we do status checks within the team and sometimes we have guest presenters from other teams. These presenters are usually people that are working on features similar or directly related to something we as a CMS team are working on. Sometimes they’re people from another product team (say, Frontpage, or Word) and sometimes they’re from completely different divisions of Microsoft. For example, my first PM meeting we had Ward Cunningham come speak to us about Wiki’s. Awesome!
Since I am working on features with developers and testers, we have meetings to touch base with each other and see where we are. In Microsoft-speak, the team implementing a feature is called a Feature Crew. A crew typically consists of a PM, a tester or two, and as many developers as are working on the feature. We have a weekly meeting called a Feature Crew Sync-up where we all get together and give status updates. There is also a larger logical grouping of feature crews that are working on features that target the same type of customer. For example, the features I am working on will be used by an IT Professional at a large organization, so my FC and another FC that’s working on a related feature make up the ITPro team. These groupings help keep things organized and eliminate some overlap in development, since you’re working closely with people whose features are similar in scope to your own.
Finally, there are a couple of other types of meetings that warrant their own sections.
During the development phase, when features are actually being designed and implemented by feature crews, Feature Crew Councils are held to get feedback from managers. For example, at an FCC I was involved in, both Gerhard and Nathan, the development lead, were present. We walked them through the feature, including a demo that was running the actual code and UI. Then they ask us questions and give us useful feedback. For example, they might be confused by a piece of the UI. That doesn’t necessarily mean that UI must change, but it does mean it’s worth taking a second look at the design and making sure there’s not a way to make it clearer to the user. Often the meeting attendees will have suggestions as well – it’s not like they say, "This sucks. Fix it." They say things like, "I don’t think the difference between the source section and the destination section is made clear. When I look at this page, I’m a little confused about what data is where on the page. You might try reorganizing it to make it clearer." These suggestions and feedback are very important as a supplement to usability testing and customer feedback.
Spec writing is an iterative process, filled with drafts, reviews, and critiques. The basic idea is that no one PM can make all the right design decisions or see things from every angle. In order to get the best spec and make sure that features are well-designed, a spec goes through a review process. The review process consists of many different steps, but basically a review and a critique are similar in their goals; they just happen at different chronological points. Usually a review happens earlier when there are a lot of unresolved issues or unclear sections in the spec. A critique happens after the PM and tester feel that the spec is complete and has all of its active issues (sections in the spec that require investigating, then get resolved as the PM finds out the answers) resolved. There may be more than one review and critique, depending on the feedback received and any issues that get uncovered as part of the critique.
Since I started at Microsoft, I have learned more about software bugs than I really wanted to. :-) I’ve learned about things like regression bugs, the so-called "bug tail," etc. Needless to say, bugs are a normal part of software development. No matter how perfect or talented your developers are, they’re going to make mistakes and introduce bugs in their code; but it doesn’t stop there. Sometimes features aren’t speced very well, and devs make judgment calls or assumptions when they’re coding. These assumptions might be incorrect, and the feature ends up not working in the way that the PM intended. This is essentially a spec bug – something that was either omitted or unclear in the spec which creates confusion further along in the process.
As a PM, it’s my responsibility to make it as clear as possible how each and every piece of my feature should behave. This is important not only to the developer, who’s actually writing the code, but also to the tester, who has to compare the code to the spec and make sure the code is working the way the spec says. Spec bugs are filed against PMs in the same way code bugs are filed against devs and test case bugs are filed against testers. Everything is centralized in a big bug tracking database, and we access that DB using an internal tool called Product Studio. Product Studio is a very powerful and simple to use tool that is specially tailored for bug/issue tracking. It’s extensible enough that many teams use it in many different ways. I really wish we had it back when I worked tech support at IIT, because it’s easy to find things and set up complex searches (and save those searches!). I monitor bugs just like I check my email, and try to resolve them as fast as I can, taking their relative priority into account.
A bug’s priority is determined by the triage process. When a bug is opened, it initially has no priority. At some point (usually soon after it is opened), it is triaged by the appropriate parties and assigned an appropriate priority. Depending on the type of bug and where in the development process we are, the person or persons responsible for triage may change. Later in the process, a larger triage team may be used to discuss and determine relative priorities of all the bugs.
Contrary to what you might believe about Microsoft, software security is incredibly important here, and something we take very seriously. One key piece (though not the only piece) of security analysis that we use is a Threat Model (they’re talked about in-depth in Writing Secure Code, chapter 2). Every feature must have threat model analysis done on it. As a PM, I am responsible for managing the model, which includes generating a Data Flow Diagram (DFD) of the feature to use in modeling the threats to the system. Generating the DFD can be tough, since it requires a lot of in-depth info about the nuts and bolts of the underlying code, so meeting with the devs to get that information is crucial. After you have the DFD, the entire teams looks at the system and figure out where an attacker could try to breach it. You categorize the threats and establish a baseline threat value, which is a numeric average of various categories. Anyway, the book does a much better job of explaining the threat modeling process, so if you’re really interested, take a look at it. Every threat has a bug entered to track it and ensure that the threat is properly mitigated.
Right now, I am managing three very different things. One is a feature that we’ve already finished coding (for the most part); the other two are sort of "fell through the cracks" issues – things that either we didn’t have the manpower or time earlier in the development process to get to, and so I’m taking care of them. The most difficult thing about my responsibilities is the huge need for multitasking. I’m only doing three major tasks – some PM’s are managing many more. Thankfully, I am figuring out ways to make my life easier as I go along. A major piece of staying on task is my whiteboard. Every office at Microsoft seems to have at least one, and sometimes many more, whiteboards (something I alluded to in my interview breakdown). Not only is the whiteboard useful for jotting down notes or drawing diagrams during informal meetings in your office, but it’s also a great task manager. I know, I know, I could use Outlook and OneNote and the lot (which I actually do), but there’s sometimes no substitute to a big white board filled with things you need to get done. It’s a constant reminder of how far behind in my duties I am, and it feels oh-so-good when I can finally erase a task from the board.
I do use Outlook a lot, though, because Microsoft is extremely email-centric. Plus, it handles all my meetings and scheduling so I don’t go crazy trying to remember things. OneNote is also great, since I have a Tablet PC. I don’t use it as much as some people, but it is kind of nice to have one central place where I can store my notes from every meeting I go to. There are problems with it though, mostly because I tend to write at an angle and that throws the handwriting recognition off a lot.
Another thing that helps me stay on task is my weekly one-on-one (1:1) with Jim, my manager. It’s a status update, and he clues me into some bigger-picture timeline stuff, so it helps me prioritize the things I’m working on to be sure I do the most important stuff first. Staying on task is something that is pretty tough. I’ve been told it gets easier with time, and I believe it, because I’m already more effective in one day that I was my entire first month, I think. At the same time, though, I am not sure I’ll ever be able juggle things as well as some of the other people on my team. Time will tell, I suppose. :-)
Anyone who’s worked at Microsoft (especially interns) will tell you that it’s baptism by fire. From day three, I was being looked to to make major design decisions, and frankly, I don’t think I was ready. On top of that, Jim left for a week’s vacation about a month into my tenure, so I really had to figure things out while he was gone. It was a good experience, definitely, but I made a lot of mistakes and I really feel like an idiot a lot of the time because not only do I have to live with the consequences of a bad decision, but the other people on my team do too. I especially feel bad when a flawed design has to be recoded just because I didn’t take the extra four hours or so to really think through the original design. I do not relish the look on a dev’s face when he finds out he has to ditch all his previous work and start over. It’s good motivation to do it right the first time, I guess, and I take some comfort in the fact that in the end things will be better for the customer, so making the design change, while difficult, is definitely the right decision.
One of the biggest adjustments for me since moving here has been the differences in designing software aimed at the enterprise customer. I come from a very "individual user" background, and making enterprise-grade software is a different experience in many ways. Don’t get me wrong – ultimately we try to make software that the end-user, which is always a person, will succeed with. But there’s a big difference between my mother as a computer user and Peter, a computer user at Initech (catch the reference? :-). Much of Microsoft’s software is aimed squarely at the business market, and since I have never been in the business users’ shoes, it’s often really tough for me to "put on the user’s hat," as they often say around here.
The atmosphere at Microsoft is… well… hard to describe. It’s relaxed and frenetic at the same time, if you can imagine that. The people I work with are always busy, and yet the office somehow maintains a coolness about it. Dress code is very casual. I wear jeans and a T-shirt most days, and sometimes I feel overdressed even in that. :-) For my first month, I woke up around 8am and tried to get in by around 9:15 or so, but lately I have been trying to make it in earlier, around 8am. I just hate staying at the office so late, so if I start a little earlier, I leave a little earlier. Not that anyone’s watching, of course. I could show up at 11am and leave at 1pm if I really wanted or needed to. I’m sort of free to do as I please, but there are expectations in terms of productivity, so it makes sense for me to be in the office long enough to get my work done and not go crazy. Also, with as many meetings as I have, I usually need to be in the office during the majority of the day anyway. I have found that self-motivation is very important at Microsoft, and though I thought I had a decent amount of it, I am finding that I might not have enough. See Staying on Task. :-)
Oh, and contrary to what you may have heard, iPods are welcome. :-) That said, there is certainly an enthusiasm for Microsoft products, and mostly it’s well founded. There are some cool Microsoft applications and products. (I hear Magneto [aka Windows Mobile 5] is most excellent, but I haven’t had a chance to check it out yet. The new version of Office is swooby though, that I can vouch for :-). There’s enthusiasm around any cool technology, whether it comes from within or from our competitors (Automator is something that was brought up recently), and I think that’s to be expected. We’re a bunch of technology geeks, and whether we’re building it or someone else is, if it’s cool, we’re going to crow about it. :-) I have run into people who are hell-bent against anything non-Microsoft, especially OpenOffice and Linux, but they’re few in number. That’s a good thing, too, because I really don’t much care for zealots, no matter what side of the software fence they’re on.
Well… I could really go on and on, but as I said at the beginning, I have been writing this off and on for over two weeks, so I figure I might as well just go ahead and post it. Maybe I’ll post Part II in the next few weeks. We’re transitioning to a very different stage of the development process, so I’m going to be learning a lot of new stuff, and my responsibilities are going to change over the next few weeks. Anyway, hopefully this will appease the inquiring minds of my friends and family for a day or so. :-)
This is the online journal of