"Are you able to shed any light on how much software development takes places outside of the US? Or indeed, what happens at which Microsoft sites around the world?

Why would a new grad come to Seattle to work for Microsoft when he can work for Google in Mountain View, New York City or Zurich?"

I would love to talk about our development organization and how it works around the world.  For me working at Microsoft has been incredibly rewarding because of the opportunities I have had to work with developers around the world.  I first worked with Microsoft developers in Japan as we made the Japanese version of C 7.0 and Visual C++/MFC.  Of course not everyone is required to work with folks around the world, but if your job involves that it can be quite rewarding.  If you happen to speak another language, then be sure to mention that since that might offer up additional opportunities (PS: don't exaggerate your language skills or you might find the interview with a native speaker a bit awkward!)

First, as some background the Office product is available in over 40 languages around the world and we sell the product in over 70 different countries (at last count).  We develop Office to be a single, worldwide binary. This means that all the user interface, help, and local features are separate from the core executable.  To switch the user interface language you simply swap out some DLLs using the "Office Language Settings" applet (off the start menu) and bingo! a new language (assuming you have the multi-language pack).  The benefit of a worldwide executable is that patches and bug fixes that touch the core code (i.e. a security issue) can be done with a single patch worldwide.  This is all pretty neat and it actually took us many releases to get this right and we still continue to refine this so that even at the extremes we can separate out functionality like using calendars (lunar, western, etc.) so that we can maintain a worldwide executable.  If you haven't seen your own software running in Hebrew, Chinese, Urdu or another language then you're missing out.  In the first floor of our building in Redmond we have the CDs from a bunch of different languages decorating the hallway and it really shows the breadth of work that everyone does indirectly.

The Office products are developed by a number of sites around the world.  Most of the C++/C# programming is done in Redmond.  This is what you will find with most Microsoft products (with the exception of our Dynamics business software which has most of the development done in Fargo and in Europe).  In addition, Office has a number of substantial development sites (all of which are hiring from college and industry):

  • Mountain View, California – We develop PowerPoint and much of Office's graphics functionality in Mountain View at Microsoft's Silicon Valley Campus.  We've maintained this site for almost 18 years (though it has had several locations in the Valley).  The Silicon Valley Campus has over 1,000 technical people developing a variety of products and services important to Microsoft’s future.
  • Beverly, Mass. – We develop Groove and operate the Groove services infrastructure from here.
  • Dublin, Ireland – Our Dublin location is our globalization hub and from here we localize, test, and release Office in over 30 languages.
  • Tokyo, Japan – In Tokyo we target our development efforts towards specific needs of the Japanese market, since culturally and linguistically customers require Japanese specific features.  We have also learned that many of these needs actually solve problems around the world (like enhanced tables in Word) so this team will routinely ship their work as part of the worldwide product.  We also create the Japanese localization of our product here.  Through an East Asian effort (Japan, China, Taiwan, Korea) we develop the Input Method Editor (IME) which is a linguistic tool that allows the mapping of keystrokes to Japanese, Chinese, Korean characters.  This is some high tech work that has been ongoing for many years and has involved collaboration with linguists and Microsoft Research. 
  • Beijing and Taipei – As with Tokyo, we develop local features for the China market in these two R&D locations.  We also create the localized products here for Simplified Chinese and Traditional Chinese (the two scripts).  As an example of the work done here, we have developed the ability to send SMS messages from Outlook, which is super important for the China market.
  • Seoul, Korea – Similarly, we create the local features for the Korea market and also localize the software into Korean.  In Korea, workflow and Office automation are very important so for example in Office "12" we have done quite a bit of that type of work here in Korea.
  • Global Product Planning – in addition to all this we maintain product planners in several other additional locations in Europe and the Middle East.  They are responsible for the market-based intelligence and working with customers in their native language to better understand their needs and how Office can help.

For most US and Canadian college graduates looking for a technical career the primary locations to consider are Redmond, Mountain View, and Beverly.  This is where you will join the teams that build the worldwide executables.  Working in one of the Asian offices would require language skills (Trust me!  Last year, I spent 3 months living in Beijing and you definitely want to speak Chinese.)

From the earliest days Microsoft has chosen an R&D model that encouraged all developers to work in one central location.  This was not the industry norm as set by IBM where development happened equally all over the world (nor was the fact that most all developers have a private office at Microsoft compared to cubicles).  The reason was that there is a strong belief that to build highly complex systems you need to have very high bandwidth communication.   The core customer benefit that we drive to is to deliver software that works together and software that has a 1+1=3 cumulative effect.  So for example, customers that invest in one technology for working with one product can use that same technology and work with other products.  Now this is very hard to deliver and we continue to have ambitious goals to meet customer needs, but this integration is something that Microsoft does work to deliver uniquely.  Some like to say that this type of development is slower and that it reduces the pace of innovation.  Such statements leave out two important characteristics.  First, the integration of products is itself innovation—having two pieces of software work well together in a unique high bandwidth manner is innovative (before Office, word processors and spreadsheets shared information through file import/export of proprietary formats, not just a clipboard).  Second, I have never met a customer that does not request even more integration than we currently deliver and the flip side is that I have never met a customer that wants to invest in "point solutions" or a series of unrelated products.  But I digress…

So we are focused very much on developing our software from our campus in Redmond.  There are a couple of things to really think about when you consider that some companies will essentially let you work from home (wherever that might be) or will let you work in a satellite office:

  • Critical mass – For any R&D facility you need critical mass to cause the flow of ideas and feedback to really work.  You need to interact with people, to bounce ideas around, and to have other people to help solve problems.  This number is way bigger than you think if you have just experienced college scale projects.  I think the minimum number for this is to have about 50-100 people working on the same set of goals and project.
  • Visibility of your work – Everyone wants to see their work presented and valued by the leaders of the company and your group.  In Office, as we conclude the coding for each project we invite BillG to tour the building and see demos from each team (and during the project we will present to him many times as well).  This can only work because we have most developers in Redmond and Bill is in Redmond. 
  • Management input – Along with visibility of the work, the truth is that for your work to be connected and part of the group's mission it really helps for work to be discussed and talked about at regular intervals.  While electronic communication is obviously easy and available to all of us, I have found that nothing beats face to face meetings.  Often these are informal and happen in hallways and other occasions.  I've heard stories about other companies where to get your work "approved" you need to come in Saturday night for a 5 minute meeting with one of the founders.  While that sounds exciting and cool, if you want big things to come of your work you are going to want more of an opportunity to share your work or make your case.
  • Career opportunity – Everyone wants to gain deeper technical knowledge or broaden their management skills.  To do so is going to require a critical mass of products or people to work with.  Small satellite offices or working from home make this very challenging.  If you work in a satellite office then there is a good chance that moving on to a new project will require you to move to a new location.  Or if you want to move to management you might not have as many opportunities in a satellite office because the number of jobs and the growth of employees is limited.
  • Sales and marketing – Even if you are technical employee, there will come a time when you either need to or want to interact with the sales and marketing folks.  You might want to get their input on features or you might want them to set up some time with customers.  Generally speaking, if you are not in the main part of the company's facilities you are not likely going to be near sales and marketing, as those folks tend to be located pretty close to the executive offices (go figure).

That said, offices that are "remote" can be made to work but it takes an deep commitment from the management team—the people that the most senior members of the team in the remote site report to.  For example, the manager of our team in Mountain View spends 2 days every other week down in Mountain View.  I manage our Groove team and I travel east every 4-6 weeks to spend a full day meeting with the team and meeting 1:1. 

And working remote takes a commitment from the rest of the team to support this type of work.  The members of our teams around the world all travel to Redmond.  The closer teams (Beverly and Mountain View) travel very frequently sometimes as much as every other week.  But it is not enough for them to make it out here.  Because we value the integrated approach to development, the members of the team that work here in Redmond are prepared to work closely with these other team members as if they worked here full time.  We also have members of our team from overseas spending 2 or 3 weeks at our Redmond campus.

We also work very hard to move people between our sites, in keeping with our general guidelines that working through full product cycles is super important.  Also, because we are focused on building out the sites we do choose as extensions to our headquarters R&D and not isolated projects, locations such as SVC are used by all the product lines, which means you have opportunities to move to other projects at the remote facility and still be connected to significant mainstream projects at headquarters.

Also both BillG and SteveB visit our sites outside of Redmond routinely.  For example, SteveB was just at our Dublin facility and BillG just visited our Japan facility where he got a demo of the IME and workflow features mentioned above.

This means we have an incredibly high level of commitment to our remote development sites.  They are critical to our success and very much "first class citizens".  Yet there are challenges in maintaining these sites and it is not as easy at it seems. 

It is easy to be seduced by a company saying that you can tele-commute or work at a small satellite office.  For a short time that might actually work.  In the medium term you have to ask yourself if the tradeoffs are compatible with your own career goals.  And over the long term you have to consider that the opportunities that will be open to you will be a different set than if you were part of the bigger corporate structure.  And ask your potential employer what is the visibility the remote site has to corporate?  Will the manager of the site at corporate be a core R&D person or a "facilities manager"?  Will the CEO/founder visit the site?  Will the manager from the main R&D facility visit? How often?

Another thing to consider is that when you have a core R&D facility and the company works on the breadth of products that Microsoft does there are two advantages.  First, you have access to experts in just about any field—if you are working on SharePoint and want to get the best advice on how to use SQL Server then the team is right there and willing to help.  Or if you are pushing the state of the art in development tools and want to work with leading researchers, Microsoft Research is right there.  And second, you open up a great deal of career flexibility for yourself—you can find new opportunities on new technologies or you can pursue career growth through management, or both.  All of these represent opportunities in the Redmond facility at Microsoft, and when combined with the balanced approach we take with remote development, I think we have a very good set of opportunities.

This topic would not be complete without a few words about "off-shore" development.  This year Microsoft will hire a record number of college graduates (and experienced individuals) to our product groups.  Our demand for talented employees is still greater.  Because of that we will continue to hire record numbers in the US while at the same time continue to grow the facilities we have had overseas.  As you can see, developing software from a single location affords us a chance to do great work for customers and this will continue to be our primary mission and our primary engineering structure.

--Steven