This is my first post (of many?) on the shell revealed blog, and I thought I’d try and offer some insight into what it has been like to be on the Shell Team.  I joined Microsoft and the Shell team September 18^th, so I imagine my perspective is pretty similar to many of our readers, and I hoped to point out some things that stood out to me as I began working with the team.

Let’s start at the beginning—the interview.  At this time last year I was a graduate student pursuing my PhD in Political Science thinking that I was going to change the world.  After a school year of indecision I found myself being flown out to Seattle, interviewing for a new career/life path and scared senseless.  I had done my homework and knew all about the infamous Microsoft interview.

When I got to campus the first person I met on the team was a PM named Ed Averett.  He told me he was going to be my warm up interview, and basically just try to make sure I was good to go for the rest of the day.  After explaining a bit about what the shell is and what the team was responsible for, he started in with a design question:  “Tell me how you would go about designing a cash register system for a coffee shop?”  This seemed easy enough, so we talked about what features it would need, how it would scale, security, etc.  What I realized at the end of the interview was that we had done a little bit more than just come up with features that we thought were good—we matched features to customer needs in their respective demographics.  As we discussed, Starbucks would have different needs than a purely local shop and our product should reflect that.  This seems simple enough, and it is simple when you are designing for three types of customers.  To go a step further, and this is a huge concern when designing something with the scale of windows, we talked about whether or not it was possible to meet all the different types of customers needs in one product.  Thinking about software design in this manner was something that, for me at least, was not stressed in my undergraduate education, but is what software design in the real world is ultimately all about.

My next interview was with Steve Strauch, another PM on the Shell Team.  His big question for me was “How can we make PCs and mobile phones more complementary pieces of hardware?”  We started by talking about how they interact now, and because it was such a broad topic, burrowed further into contact list integration.  While Ed’s interview opened my eyes to the number of customer needs that we are trying to fulfill here at Microsoft, Steve’s spoke to the number of partner, ISVs, HW manufacturers, etc. for whom we need to be designing.  One of the hurdles that we identified when discussing mobile phone and PC interoperability was the sheer number of different formats and protocols that we would have to be able to accommodate because of the diversity of cell phone manufacturers.  Again, designing for the world market is something that I had just never thought about when I was in college and having to think through the problem of making an API (we chose a codec system) that could accommodate as many existing and as of yet unforeseen cell phones complicated everything!  One of the awesome challenges (not that we’re complaining) that I’m realizing the Windows team faces is that Windows is so widely used you don’t have the convenience of designing  to one, two or even a handful of potential customer profiles.  You really need to perform an overall cost benefit analysis of the entire range of possible PC users.  That’s a lot of people J