Life at the Mothership: an introspection

Are you one of those people who hate when people post to their blogs about how it has been so long since they’ve blogged and they apologize for the delay and cite all sorts of excuses?  Yeah, me too ;-)

I’ve been doing a lot of thinking lately about my move to the mothership this past year.  I’ve been journaling things all along the way about my feelings, frustrations, personal tribulations and great experiences I’ve had this past year.  I thought I’d share some of that with you all to provide some behind-the-scenes aspects of how some, not all, teams operate at Microsoft…the good, bad and ugly.  These are pretty random thoughts and in no particular order.  This is a bit of a random stream of thought so feel free to move along.

Background

Although this may sound like I’m writing about my first year at Microsoft, it isn’t.  I’ve actually been with Microsoft for just over 6 years now.  I started very local, becoming the developer evangelist for a geographic region (southwestern US).  In doing that I had so many great opportunities to work on a national level with developers and product teams that I was able to move into a “Community PM” role with a product team, Silverlight.  About 18 months ago I had an opportunity to get closer to the engineering process of shipping software…something I had a strong desire to accomplish.  This resulted in me relocating to Redmond, WA to work directly on the product and own some level of features.  These are my thoughts of being a part of that process and general observations at Microsoft.

Benefits

I would be remiss if I didn’t point out how incredible the concept of being ‘on campus’ feels.  The benefits are great and the way the campus is run is quite amazing.  The company does a good job trying to accommodate employees in all areas.  Having worked with Microsoft in the field I know the benefits in general are awesome, but the aspect of working on the main campus are just even greater for an employee.  You can check out some videos of some of these aspects on Channel 9 series about the campus.  Particularly some of the statistics about the shuttle service (something I use daily) and the dining services are pretty astounding.  I also think it is great that Microsoft pays for public transportation for everyone and I’ve become a regular on the King County Metro bus system…it’s awesome people watching!  Companies vary in benefits to their employees but I do believe that Microsoft offers some world-class benefits to us, and I’m grateful for that (as is my family)!

The Office

I currently work in Building 40, home of CLR, HPC, all things XAML and some other random stuff of people I never talk to.  I pretty much keep to my team on the 4th/6th floors but hear murmuring from other product teams.  You can learn a lot by just walking around!

Prior to moving here I worked from home and/or mobile with customers and community.  To say that I looked forward to office live again would be lying.  It’s an office.  My commute went from going to my basement, to driving (or taking the bus) into work every day.  When “quitting time” was done I couldn’t just walk upstairs anymore and be home to my family…I had to drive.  It is surprising how much impact an hour has on your day really when you haven’t had that time lost in commuting for so long!

Office politics.  Yes, they exists.  It is a big company.  Yes it is annoying.  You learn to navigate what matters and what doesn’t.

Office Hours and the elusive work-life balance

Okay, this one bothers me.  I don’t think of myself as a curmudgeon but I was caught off guard when someone complained that I scheduled a 9am meeting.  Seriously?!  I’ve learned that acceptable work hours around here are truly about 10:30 AM – 7:00 PM.  The busiest part of my day is about 2PM until I leave.  For someone with a family, who has just moved and not have a lot of friends/family nearby, this has been hard to accept.  I’ve been trying my best to manage expectations here.  I’m not always successful…with co-workers or my wife :-).

Work-life balance….I’ve lost it in working on campus.  This is a sad truth that I’m being honest with you here.  It’s been tough to manage a fast-paced environment/product with desires and expectations of family life.  Sometimes it works, most of the time it hasn’t lately.  I’m thankful for a very supportive wife who hasn’t found a good divorce attorney yet ;-).  Seriously though this is something I’m very conscious of daily but not always successful in resolving.

Opportunity

I’ve always scoffed a lot about being ‘on campus’ as a requirement for growth and success in a product.  In fact, I challenged Scott Guthrie many times about why he didn’t invest in product team folks in the field.  Being here on the XAML team, I now realize that, at least for our team, that would be very challenging.  Our team is so agile that decisions and features can change from the beginning to the end of the same day.  Being in the hallways where you can grab your dev lead, argue and decide within the span of a day and in person is really critical.  The value of this is incredible as you could imagine.

Being in-person on a team also provides you personal opportunity.  My office was down the hall from ScottGu.  This gave me ample opportunity to engage with the VP of my division on things we were working on and how we are interacting with other teams.

NOTE: Scott was really awesome to have that close in my opinion.  He would pop in to conference rooms when he saw folks iterating on designs and such and provide his thoughts.  Some like this (I do) and some don’t.  Some think that when a VP says something it must be done.  I’ve found this not to be accurate.  Provide a strong enough position and you can sway any VP…but yes, you should strongly consider their opinion!

I’ve also been afforded opportunities to provide briefings with Soma, BobMu and recently have had bi-weekly meetings with Jason Zander due to my work on XAML tools.  These opportunities certainly wouldn’t have been available being in Arizona.  Being in-person allows an individual to really prove themselves directly and show immediate impact. 

Corp versus Field

Having worked in the field and worked in corporate I feel I’m acutely qualified to comment on this.  Frankly, I don’t think the folks who build the products are given enough recognition.  I’ve been a part of a lot of big evangelism events (which are marketing funded) and I’ve now been involved in a lot of ship parties and/or morale events.  The company could do better showing more appreciation to those who are working tireless hours to get products out the door.

Field interaction could improve as well.  This is team-specific I feel.  Some teams feel free sharing information and others simply feel the field can’t be trusted.  This distrust usually isn’t blind though and a result of some field staff previously not honoring the confidentiality of the product teams’ wishes.  It is unfortunate but in this case one bad apple does indeed ruin it for all.

Cross-team Interaction

As you could imagine, no one team stands alone.  In the XAML team we interact with lots of folks across Visual Studio, CLR, C#, VB, C++, Microsoft Update, Microsoft.com, legal, licensing, internationalization, etc.  It’s amazing what it takes to ship a product here when you are Microsoft.  Most of the time these interactions are great.  However because each team has their own planning, timeframes and goals this isn’t always the case.  In fact colliding shipping schedules causes conflict as well at times.  These are all very difficult things to manage across team boundaries.  My chief complaint in this area is I think these boundaries show in our products and release cycles.  This is unfortunate for you, dear customer, and something I wish we as a company could focus on more.

This collaboration is essential though for success.  Teams (and products) are organized in a way that make this interesting at times.  I’ll give you an example I’m most familiar with.  As a Silverlight developer you likely use Visual Studio to write your application.  There are roughly 9 different teams involved in delivering that core experience…all dependent upon providing a unified product.  And that’s only the product and not the integration with community, content, etc.

Smart People

In this process of working with so many teams you get to work with some of the smartest people around.  You think you know something and how dumb a product feature is?  Yeah right.  You’ll be talked off the ledge pretty quickly about the scenarios you didn’t think of and how they impact the product.  You will be humbled.  I have had the chance to work with a really great set of people in all the engineering teams across the developer division. 

NOTE: Italian developers are awesome to listen to.  Ale is one person I’ve had a chance to work with and aside from learning a lot it is fun to listen to him say See-Sharp-eh. :-)

I’ve recently also been able to exchange thoughts with folks like Anders!  I can proudly say that I helped debug a situation with him…only to have the favor immediately returned when working with some of the async stuff that wasn’t working.  Opportunity + smart people == awesome.

Unfortunately smart people are attractive to other companies (or internal teams) as well.  We’ve lost some good people to other companies.  It is always hard to be happy for someone when you know you really liked working with them and wanted them to stay to make a difference.

Email Volume

Wow.  Email.  Lots of it.  Way too many “+1” wasted bytes in my inbox.  Please stop it.

I’m an information addict though and I subscribe to a TON of distribution lists at Microsoft.  I don’t just listen, I participate.  And sometimes I complain.  There is benefit to knowing the Home Server distribution list when your server crashes…or reaching out to the key tester in Windows who can tell you where your computer crashed based on your dump files.  That is awesome to have that access at your fingertips.

Best email resource?  We have an internal email called “I dunno” that you can send a note to and pretty much get an answer to who owns what product, how you solve some issue, whatever.  I feel like there is some weird robot that knows everything.  There isn’t a question I’ve thrown there that hasn’t been answered in less than an hour.

Internal Tools

Razzle, enlistment, depot, PS, TFS, CinCh, etc.  These are all acronyms or tools that are commonplace at a lot of teams.  All help streamline the internal engineering processes for our teams.  “Razzle” is basically the dev command shell environment (think custom bash).  Each team defines their own but most share common configurations and commands.  Most developers are super efficient at the command-line level to do pretty much anything.  Some other term definitions:

• enlistment – this is basically your source-code subscription.  it’s a process of executing commands to map your local workspace to a source tree and get the razzle tools
• depot – the source control environment.  this is a general term and can refer to TFS or some older systems
• PS/TFS – our work item/bug tracking systems
• CinCh – “checkin checker” – some custom continous integration tools

Probably my favorite dev tool is our code review tool.  It is really amazing.  It came out of a Garage concept (meaning people worked on it in their free time) and written by a team of eager devs (one of which is on my team).  It is an incredible tool that I hope sees integration into our developer tools one day.  Integration into our depots, annotation, and built on WPF :-).

In addition to developer tools there are some great PM tools as well.  Two in particular I like are internal sites that provide a Bing-like search for source code and bugs.  These are both wicked fast and I don’t have to have any tools installed to use them.  I can search all of DevDiv code in real-time and find the one piece of code that needs to change.

Of course there are annoying tools as well.  Our helpdesk site is unusable in my opinion.  It almost always provides me with no help and directs me to a phone number (FYI the phone first advises you to use the site to resolve your issue).

Visual Studio Engineering

I am calling this one out specifically because I think it is impressive.  A few years back I heard JasonZ say “we use Visual Studio to build Visual Studio” and I thought it was marketing fodder.  It isn’t.  The VS team has built an amazing environment around enabling DevDiv teams to be successful in building products…including the VS team themselves.  I have never realized the power of MSBuild until working on XAML tools and working in this environment.  Seriously.  I wish there was a deeper behind-the-scenes with the owners of these systems so you can appreciate what happens nightly for DevDiv products.  It’s impressive.  And yes, TFS is used and TeamBuild drives a lot of this.  Dan Moseley is an MSBuild ninja and I’ve learned a lot from him.

Localization

Want to challenge yourself?  Ensure your product is localized, geo-political safe in 42 languages.  I dare you.  This has been an immense learning area for me.  I have seen many people complain about how certain UI looks in certain products.  I’ve now realized that is a very US-centric thought.  When you run some products in Japanese, for example, you’ll realize why things are being accounted for how they are designed.  It isn’t always perfect, but products are build to accommodate all customers, not just US-English!

There are also PMs that serve as our internationalization PMs (IPM).  These folks run products (and usually Windows as well) in what we call PLOC mode, which is pseudo-localized versions.  PLOC is a process for simulating a localized product.  It’s not a real language, but basically takes the resources and turns them into foreign-looking strings.  You have not cried until you run a PLOC version of Windows with Visual Studio and tried to navigate.  These IPMs are ninjas of the keyboard shortcuts.

Specs

Nobody likes doing these.  Some teams are very strict and process heavy.  Some teams’ specs are phone pictures of whiteboard drawings.  When cross-team features happen this can get frustrating.  Managing expectations is key here. 

For the record, I hate doing specs as well.  Necessary evil.

Bugs, triage teams and hard decisions

Bugs are a reality.  There are those that you know about and those that you don’t.  For those that are reported, teams go through a triage process.  This usually involves the PM/dev/test leads of that feature area to look through the bugs, prioritize and decide what gets fixed and what doesn’t.  These are times of hard decisions.  I’ve sat in on man product triage meetings and have seen the agony in how some bugs just can’t get fixed to satisfaction.  I used to complain about lame things in products as well (or things that I thought were lame).  Now I’m on the other side.  I’m the one having to make tough calls about what to fix.  The reality is that time and resources aren’t always on your side.

Customer Interaction

This is an area where all teams at Microsoft can improve.  I think a lot of this stems from people in some engineering teams not having either spent time with real customers or they themselves never have been a customer.  This leads to some jaded opinions at times and uninformed decisions.  Some teams are way better at this than others.  Frankly I think the XAML team does a good job here informing customers, taking feedback in, and working exclusively with some top early-adopters to understand how we can improve products.  I’m a huge believer in openness and transparency.  Unfortunately not all teams share this belief.

The incoming communication channels can use some help.  You can see teams using UserVoice a bit more these days which I think is welcome.  The Connect team (the tool that customers use to log bugs against DevDiv products) is really trying to improve their experience.  I can tell you that they have reached out to community leaders within the company to understand how to streamline some process.

Team Disciplines

The disciplines I refer to here are that of program management, development and test.  These are the 3 traditional roles in engineering teams.  There are smart people in all of these disciplines but unfortunately there are too many instances of lack of respect among them.  I’ve heard one too many “just a PM” comments.  I called out a dev lead in public once about this (probably not the best thing to do but he caught me on a bad day) to chastise him.  I don’t think many people have actually surfaced this concern because he seemed alarmed I thought it was a big deal.

I do think the PM discipline needs to be way more technical across the board.  It surprised me to know that in some teams people who were designing features relied on their dev/test teams solely to verify the features.  To me, that is unacceptable.  I expect my PMs to understand and use the features they are responsible for.  I consider each PM a tester as well for their own area.  I think this is critical to success of the products.  Technical skill varies from PM to PM and form team to team.  Some see this as okay as some teams feel the PM discipline is one of process management only.

Excitement/Passion

At least on my team, I feel there is no shortage of this going around.  When I first moved up here during the summer last year I felt things were a little slow for me.  My manager told me, just wait until we get closer to ship cycles.  He was right.  It is crazy busy around shipping milestones…and the energy is electrifying.

NOTE: We “ship” many times in product teams.  Sometimes they aren’t always public.  Each milestone is considered a shipping version even if no real customer sees it. 

I can attest that this is also a very stressful time.  Peoples’ passion shows during this time when they fight for their bugs/features/whatever.  Sometimes yelling happens.  Get used to it, you aren’t in the library.  In the end the right thing happens most of the time.

Summary

If this feels like a random rant, it is.  It’s been just over a year since I made the move to the deeper engineering process.  I have had a blast learning a lot and am really, really excited to start talking about what my team has been working on since I’ve been here. 

Working for Microsoft is something I truly enjoy.  It is not without issues and a lot of the things I hate are due to ‘big company’ issues that I continually try to change but realize I’m only one of 80K+ employees here.  It is a lot of hard work, a lot of stress and a lot of personal sacrifices that get things done by people here on our teams.  We don’t always get it right, but I’ll tell you that at least I’m fighting for us to try harder to get it right more often!  Apologies for the long rant, but wanted to just share some insider thoughts.