Introducing the team

Thanks for the comments and the flood of email we received (and to the number of folks now following us on Twitter, too). It is definitely humbling to see all the enthusiasm and interest. There are clearly already few important threads in the initial comments, some of which are based on the previews of the Windows 8 user experience. We’re definitely gearing up to discuss these issues, the design, and tradeoffs. Windows 8 has new features across the full breadth of the product. It takes quite a team to build Windows 8, and so I thought it would be a good idea to talk about the team structure—sometimes the “how” can help folks to understand the “what” and the “why.”  This will give you an outline of the places we added features to Windows 8.  It will also serve as a bit of a guide as we talk about the product.

It is tempting for some to think of Windows as one entity or group, or for some to think of Windows as just a set of specific people. Sometimes someone speaks at a conference or has a blog, and that comes to represent the product for you. In reality, Windows is always a product of the whole team and much of Microsoft.  Nearly every development group contributes to building Windows 8 in some form or another.  And Windows contributes efforts to most other groups as well.

Windows is a fairly broad project made up of a set of coordinated smaller projects. When we started building Windows 8 we had a clear sense of the direction we were heading and so we built a team structure to support that direction.  Many of the teams work together while at the same time we try to break the work down into fairly independent groups—obviously as a customer you want things to work together, but as an engineer, you also want to be able to work independently. That’s a fine balance we work to maintain.

A lot goes into building a team structure to get all the work of Windows done. The most important first step is deciding “what” we plan to get done, so that we can make sure we have the best teams in place and the best structure to do that work. At the same time we have to make sure all the engineering processes—like daily builds, integration, quality, security, and all the fundamentals—are integral from the start (lots to talk about on these topics!).

We have several engineering roles, or disciplines, that make up our team. The implementation work on Windows happens when developers write code. This code implements features that come from specifications written by program management along with interaction designs from our product designers.  Testers are responsible for making sure the spec is complete and the code does what the spec says it should do. This is a simplified view of the relationship between roles, since we routinely walk a bit in each other’s shoes. There are several other equally important roles on the team, but we tend to think of our engineering effort as development, test, and program management working together in lockstep throughout the entire release—each role has an equal voice in the outcome and choices we make.

We organize the work of Windows into “feature teams,” groups of developers who own a combination of architectural elements and scenarios across Windows.  We have about 35 feature teams in the Windows 8 organization.  Each feature team has anywhere from 25-40 developers, plus test and program management, all working together. Our teams are all focused on building a global product, and so some of our teams are located outside the US and are also delivering globally.

In general a feature team owns and builds what that most folks would identify as an area or component of Windows. “Feature” is always a tricky word—some folks think a feature is a broad architectural component like the "user interface” or networking, and other folks might think a feature is something more specific, like the “start menu” or IPv6.  So the term is a bit overloaded. When we set up different feature teams, we pair the architecture (code, subsystems, components) with the scenarios (user experience) in which users will encounter it, while also working to make sure we keep teams small and manageable.  We long ago stopped trying to count new features because of the difficulty in defining a feature.  We do count work items, which do map to the work and specs that we build (but that is a pretty long list).

When folks do the math and come up with the number of developers on the team, we usually hear one of two reactions: “wow, that is a lot, and there is no way that can work,” or “wow, you build a product for a billion people with a pretty small number folks.” It is to our benefit to have the smallest number of people on the team possible, but it is to your benefit to have the largest number of people adding all the things that folks might want. So, we find a place in the middle. We want the team to be manageable and able to produce high quality, full-featured code.

I mentioned earlier that Windows contributes code to lots of other products and vice versa, so when you look at this list, keep in mind there are features from other groups (for example, our browser language runtime comes from the development tools group) and some of the work here goes into other products, too.  For example, all of our kernel, networking, storage, virtualization, and other fundamental OS work is also part of Windows Server—that’s right, one team delivers the full Windows Client OS and much of the foundation for the Windows Server OS. And some features are built in the core OS but are ultimately only part of the Server product.

Many of the teams listed below describe features or areas that you are familiar with or that you can probably figure out based on the name.  As we post more, team members will identify themselves as part of these teams.  We also have organized these teams in seven larger groups that pull related teams together—fundamentals, devices and networking, core OS, developer experience, user experience, web services, and our engineering system. The Windows Live group (Hotmail, Messenger, Skydrive,  Photos, LiveID, and more) also has a similar structure. Internet Explorer group is also a couple of teams on its own, but obviously contributes across Windows 8.

  • App Compatibility and Device Compatibility
  • App Store
  • Applications and Media Experience
  • App Experience
  • Core Experience Evolved
  • Device Connectivity
  • Devices & Networking Experience
  • Ecosystem Fundamentals
  • Engineer Desktop
  • Engineering System
  • Enterprise Networking
  • Global Experience
  • Graphics Platform
  • Hardware Developer Experience
  • Human Interaction Platform
  • Hyper-V
  • In Control of Your PC
  • Kernel Platform
  • Licensing and Deployment
  • Media Platform
  • Networking Core
  • Performance
  • Presentation and Composition
  • Reliability, Security, and Privacy
  • Runtime Experience
  • Search, View, and Command
  • Security & Identity
  • Storage & Files Systems
  • Sustained Engineering
  • Telemetry
  • User-Centered Experience
  • Windows Online
  • Windows Update
  • Wireless and Networking services
  • XAML

In addition to these teams made up of development, test, and program management, there are many others that are part of the product development team. Our content development team writes and edits our online assistance, website, deployment documents, and SDKs, to name a few things. Product planning leads customer and market research and also pays very close attention to feedback and telemetry around the pre-release software. Product design develops the overall interaction model, graphical language, and design language for Windows 8. Our research and usability team creates field and lab studies that show how existing products and proposed features perform with all types of customers. Localization brings Windows to over 100 languages (and localizes this blog).  Our operations team runs services that are used by hundreds of millions of people and almost a billion PCs.  Just to name a few..

When we started Windows 7 some people told us that the Windows team was too big and had reached a size that caused more engineering problems than it solved. At the same time, you can look at all the comments and see the incredible demand for new features across a very wide range of scenarios.

Folks want new things, and changes to existing things; they want features to be available globally, to be accessible, and to be super high quality; they want things to work on existing hardware, and to take advantage of the latest new hardware. Our job is to get as much done in as short a time as possible, at a very significant scale. That's all a pretty significant engineering effort.

For folks who are counting my words, I am still under 1,500 words, so I think I will call this an introduction to the team. Keep the comments coming, as they are helping us get ideas for posts and shape the dialog. I hope this post helps to develop some shared context in terms of talking about Windows 8.

--Steven