While at Stanford this week I was asked by a number of PM (program manager) candidates to talk about the PM role at Microsoft.  The PM role is unique to Microsoft and was actually created in response to developing software that is more usable and at the same time pushes the state of the art of technology.  So when we talk about PM at Microsoft, we're talking from a perspective of creating and evolving the role over the lifetime of the PC industry.

I have been both a PM and an SDE (software design engineer) during my career at Microsoft.  When I was recruited I started off as an SDE candidate and then I learned about PM during the course of my interviews and I thought "COOL!" that has to be a job for me--after all it sure sounds like an incredibly cool role, since it has the title "manager" in it and if you read/hear the description it sure sounds like you're running the show. The job title "program manager" is a bit of a misnomer, since program managers do not program nor do they manage--go figure.  I went with SDE because I wanted to write code in my job.  After being an SDE for 4 years I moved to program management.  I think that was a good move for me because while I like to think I was competent at development, I was probably never going to hit it out of the park with my ability to write code, but I think what I wasn’t able to do in writing code I made up for with the skills required of a program manager :-)

What follows is a description of program management from a PM perspective -- that means through the lens of a PM.  It is also an analytical description based on my experience.  I'm not trying to hype the job or make it seem too over the top.  In fact, I've recently talked with an number of candidates who have been told of PM roles at other companies and my feeling is that they are not being told the whole story.  So with my blog I try to be a bit more complete and not "sell".  This might make it seem like there's no room for change or to impact the definition of the role, but that is not the case.  What I'm describing is in constant evolution and it is the members of the team that are constantly evolving the role.  PM is a role that has a lot of responsibility but you also define it--working in partnership with expert designers, clever developers, super smart testers, etc. you all work together to define the product AND the responsibilities each of you have.  PM is one equal part of a whole system. 

Program managers got started at Microsoft while developing Excel for the Macintosh.  The challenge the company saw was that we were stretched thin trying to push the state of the art in technology (in this case develop for a brand new OS using brand new Graphical User Interface concepts) and so the developers were very busy just trying to make things like printing, display, graphics, etc. work as well as trying to develop new algorithms for spreadsheets and modeling.  That meant that the place where we were not focusing enough attention was on the usability or the scenarios for how people would use the software.  In a very classic sense the high order bit of our development was the code--this is pretty classic in most organizations today where you really only see development and test (sometimes called QA) and to the degree that there is input from users/customers this is usually done by the demand generation or marketing team (called product managers in Silicon Valley).  So at Microsoft a new role was created in Program Management with the explicit goal of partnering with development and working through the entire product cycle as the advocate for end-users and customers. 

The challenge of trying to write code using the latest technologies and bringing ever more complex scenarios to end-users in a simple way continues today as we build web sites (OfficeOnline), server products like SharePoint, and entirely new products like OneNote, as well as build whole new user experiences to replace the aging menus/toolbar paradigm.

Up front I would say that the PM role at Microsoft is both unique and one that has unlimited potential -- it is PMs that can bring together a team and rally them around a new idea and bring it to market (like OneNote, InfoPath).  It is PMs that can tackle a business problem and work with marketing and sales to really solve a big customer issue with unique and innovative software (like SharePoint Portal Server).  It is PMs that can take a technology like XML or graphics and turn it into an end-user feature benefitting 400 million people (Office Open XML format or the new graphics functionality in Office12).  I could go on and paint a very emotional picture, but let's spend some time digging into the more analytical aspects of the job.

Where developers were focused on code, architecture, performance, and engineering, the PM would focus on the big picture of "what are we trying to do" and on the details of the user experience, the feature set, the way the product will get used.  In fact the job has matured significantly and it is almost impossible to document a complete list of the responsibilities of program management.  One way to do that is to list the sections of a specification for features in Office that a PM would complete before the code gets written which includes nailing the scenario you are solving for, the worldwide implications (will your work make sense to customers in China, India, Estonia), how will developer customers extend the product (object models, programmability), is the product secure and is privacy maintained, what are the other features your work interacts with, will the feature be responsive and performant, and more.  These are critical parts of the design of any product, and when you will have 400 million potential customers thinking these through before you start the work is critical.

As an aside a lot has been said lately about "agile development".  A key benefit of program management is that we are far more agile because we have program management.  That can be counter-intuitive (even for many developers at Microsoft who might be waiting for their PM to iron out the spec).  But the idea that you can just start writing code without having a clear view of the details and specification is a recipe for a poorly architected features.  A great PM knows when the details are thought through enough to begin and a great developer knows when they can start coding even without the details for sure.  But like building a house--you don't start without the plans.  While software is "soft" the cost of remodeling or rebuilding is no different than if you decide the walls are in the wrong place or you forgot to leave room for the HVAC system--sometimes because we don't have material costs in software we think that "rewriting" is perfectly ok.  That generally works super well in two cases.  First, if the program is small then of course you can rewrite it.  In the commercial software world most software projects are not the work of one or two people--in fact one way to think of it is that if a project is only the work of one or two people (or is only a 100KLOC) then the economic value (and thus the impact) of that product is probably pretty finite (at the very least a competitor is likely to catch up very quickly).  And second, rewriting works well when you are looking backwards and re-doing what has been done (like cloning an existing product, implementing something for the n-th time).  When you're doing innovative work, the time spent on design and analysis pays off handsomely in the ability to develop a complete program and to have something of lasting economic value.  AND when you have a process that embraces design and up front thinking you also find your development much more agile because when you do get the code in the hands of customers--after 2 months or 2 years--there is time to respond and react with changes because you are not overwhelmed with the basics.

The last point is worth re-emphasizing.  There's a school of thought that just getting your software out in beta and then "reacting" to the feedback is the best way to get the product done.  Again, this tends to work for products that already have a definition you are chasing of if you're interested in incremental feedback.  So if you're building an email experience and release it in beta, your customers/users can help you to prioritize which features in the universe of email to add next assuming you did not have all of them up front.  But if you're doing something new and innovative or more importantly if you want more than incremental feedback then you need to have much more sophisticated mechanisms than just beta feedback from power users.  Most importantly, the role of PM is to represent all customers, not just the ones who do beta tests or the ones who take the time to send in feedback or use early products.  A key skill of program management is to have empathy with a broad range of customers.  Often when you are just getting started you will see how easy it is to over-emphasize early power user feedback or anecdotes over broad based feedback.  Don't get me wrong, power users are great but they are just one type of user.  A great advocate for the "little guy" is Walt Mossberg and he really does point out when you're missing the mark on a product and too focused on "techies" as he calls them.  The bottom line is that most people are not techies, but most beta customers and most early adopters are so you as a PM have to do the leg work to validate your work with a broader audience. 

Before talking about what PM does specifically it is important to look at PM in the context of the relationships with the others that contribute to building products.  A PM serves as the coordinating point where all the disciplines come together--this is why you can think of the PM as being the hub.  What is critical about the Microsoft PM role is that all the different people serve as a "virtual team" building the product--the PM does not have to go pull them together but rather has to help get everyone aligned.  The resources for a project are dedicated to the project--these resources include development, test, product planning, usability, and product design.  Each role brings a unique perspective a unique set of skills to the product development process.  While you can often be someone who has an affinity for another discipline, rarely can any one person bring all of these skills and experiences.  And I can promise that any project of significance really needs the specialized skills to do a world class job and build a sustainable and uniquely innovative product.  I should probably write a blog like this on each role--maybe after the holidays!

• Development -- developers write the code.  They are in charge of the code's architecture, the performance, the reliability, the security, and getting the functionality into the product. Of course development is at the core of what we do as a software company, but it cannot stand on its own.
• Test -- software design engineers in test insure the quality of the product but more importantly that the product ultimately meets the needs of the customer we set out to meet.  SDETs will review all specifications as first class members of the team and use their perspective and experience in working with PM and SDEs to insure that the product is not going to be fragile and that it will be possible to insure a successful implementation.
• Usability -- usability engineers validate the designs of our software and incorporate the statistical understanding of customers into the process. Microsoft was an early pioneer in integrating usability in the product development process (though some might say how in the world we released the Hot Dog Stand theme if we had usability).  Many usability team members have PhDs in HCI or related research areas such as anthropology, and many are undergraduates with a HCI or psychology background.  These team members design mechanisms to test and validate designs and design assumptions.
• Product Design -- Design work in partnership with PM to develop the interaction model for our products and also own the overall product look and feel.  While many companies use design for "graphical design" (which we do) our designers are expert in computer interaction--many have studied at programs like Delft's or CMU.  When you look at the new user interface in Office12 what you see is a strong collaboration between the PM experts and the Design and Usability experts.
• Product Planning -- our planners are experts in understanding the market place and understanding what our customers need from software.  Planners own research and communicating that research to the product team PMs and to the executives deciding the overall goals of a release.  Planners are assigned to broad technology and business areas (collaboration, business intelligence) where they become expert in all the products and solutions on the market and how Microsoft can offer customers improvements over what is in the market.  Many planners have business background and have worked in marketing before.

Many companies will "sell" you on being able to do many of these different things from one job.  This is just not a reality that exists and I always feel a bit bad for folks who believe this.  There are two times I hear this a bunch.  First is at startups you hear "come join us from college and you can own all of this".  Of course at a startup the real experience is that you are the college hire, which means you will do the grunt work while the founders and the venture people do all the strategic work--so you might find yourself setting up the build machines rather than interacting with customers.  Second, I hear this a lot when companies are selling against Microsoft and point out that "at our company we do not specialize and everyone does everything".  This is another "well in reality..." situation, since of course even when I have seen companies that claim to do the specifications or customer research and up front planning they do that work from Product Management, and those people are just as specialized, they just report to the marketing team.  And we know what that means, which is when push comes to shove the marketing team will need to use every hand to get out there and generate the business and sell--so even if there is a single group that does the work, those roles are specialized, and rarely dedicated specifically to the role.  These are my experiences and of course your specific situation might be different.  I've just seen these patterns repeat themselves over many years of hiring students and having them come back to Microsoft after a short experience with something like that.

It is worth talking about the size of the PM team for a bit.  In Office our PM teams are small (our dev teams are usually about 20-30 developers as talked about previously).  The entire user interface for Office12 was developed by a team of about 12 program managers--imagine that 12 program managers did all the work to totally define the new interaction model for 400M customers of Office.  But along with the fact that the team is small is the fact that a team like this is also one where even the newest members of the team receive significant mentorship and training from a very senior member of Microsoft (you can watch this video to meet the head of the user interface PM team).  So you have the biggest impact you could have in designing software while receiving a very high level of management attention.  And then of course each PM has developers they are responsible to equip with features and specs -- the whole user interface development team was less than 30 people (so about 2 devs for each PM).  A critical part about PM (also one that is unique for Microsoft) is that as a PM you have dedicated developers for your feature area--your job is to get the most out of those developers in terms of bang for the buck by having great feature ideas and great specs to get them done. 

So what does a program manager do?  Well there are three phases to program management: learn, convince, spec, refine.  These roughly mirror the product development timeline written about previously.  Do keep in mind that the timeline is not fixed--rather the phases of the timeline are.  So if we're doing a 12 month project then the time is divided accordingly, same as if the project is 24 or 30 months.

Learn --> Output of learning is a prototype

During the learn phase, program managers spend their time learning about customer problems and learning about the products and technologies out there that are relevant to these problems.  There is a lot of work with planning to understand competitive products or new products in the marketplace.  As you can imagine, customers have huge challenges in getting their computing systems to do what they need.  So often we will spend days at a customer's place of business learning from them and watching them trying to get their work done.  A great example of this is the work we did to understand how customers manage documents in an organization.  It is easy to see that organizations like law firms or pharmaceuticals are heavily dependent on the flow of documents in an organization (contracts, drug approval and research) and so the systems are both mission critical and elaborate.  Companies really want to automate more and to make things more usable and reliable.  The work of program management was to deeply understand how to model the flow of documents in an organization--spending time at big drug companies, small startups, big law firms, local law firms, Public Relations agencies that produce press releases, or government offices that produce legislation to name a few.  Out of this work PM and Planning developed a conceptual model called the "document lifecycle" (DLC).  This helped us to frame the way that customers would like features to work.  So for this work the PM needs to be really good at working directly with customers, learning from them, listening, being open minded to different ways of working, etc.  When you're hired from college you will participate in this work for your area.

At the same time there are deep technical problems to solve.  We need to solve the control and access to information (drug test results and contracts need a high degree of security, yet they need to be collaboratively authored).  PMs spent a lot of time working with the Windows platform team who develop platform technologies like our Rights Management Server or the Windows Workflow Foundation (WinWF).  These technologies are critical to enabling a robust and extensible implementation of the DLC. So in this phase of learning, the PM has to become well-versed in new platform technologies or in how to apply existing technologies.  Often this is where some people say "it would be easier to roll our own" -- which of course in the immediate term it is (just build your own linked list and event source/sink) but what you miss out on is the expertise and leverage that comes from a deep platform technology.  For example, by learning the WinWF and being an ISV of that technology we can take advantage of advances in workflow, integration with Visual Studio, and a very robust and scalable server without us doing any work--just like when developers reuse the process model of Windows, or the client side drawing code of GDI.

With this information at hand the role of the PM is to synthesize this learning into a series of prototypes.  These prototypes are of varying fidelity.  This is where the analogy to architecture holds--sometimes you do a drawing, sometimes you do a high fidelity diagram, and sometimes you build a model.  In software we sometimes build static screen shots, we sometimes prototype in tools like VB.NET, sometimes we prototype in a series of static bitmaps that illustrate a scenario.  For our new user experience in Office12 we went through a series of high fidelity prototypes development first in PowerPoint (you'd be amazed at the depth of interaction you can do) and then in more high-end design oriented tools.  By the time we were ready to exit the learning phase, we had a full mockup of the user interface (which I have shown at my campus tech talks this year).

The output of this phase is a prototype upon which we will author specifications.

Convince --> Output of convince phase is a plan and goals

Once you've learned a lot you have to go out and convince your peers, your manager, and the dev team that your ideas are worth pursuing.  This is where being a solid communicator and someone who is able to bring together customer needs, technologies, and scenarios really comes together. 

As an aside, a lot of companies will tell you that you can come and pursue your ideas.  That is probably not a good plan -- that is a recipe for chaos.  But more importantly, if you can do whatever you want there is a good chance someone else in the company has the right to come in and tell you to change.  If there is this level of empowerment it means the management team is empowered as well :-)  The ability to just start at a company and pursue your own agenda is much more of a lore than any reality--all companies have a strategy and a business framework that the work needs to fit within.  At the very least, eventually shareholders will want a return on your R&D investment.

So at Microsoft the convince phase is really where your entrepreneurial skills come to play.  While you will always have work to do, during this phase you are working to expand your vision and get as many lined up behind your area as you can handle.  Your ability to convince people of your ideas is a lot like trying to get funding from venture capital folks.  That is why if you have a great conviction of your ideas and a lot of energy you probably have the makings of a great PM.

The best part about this is that the teams you work with are all working in unison on the vision and everyone is on board trying to make sure the ideas come together super well.  In particular your mentor is there to work with you.  But ultimately, the ideas will succeed based on your own initiative and ability to convince the team of the chances for success and the high priority nature of the work. 

The output of this phase is the set of objectives for the project area.  What follows is developing things at the next level of detail.

Spec --> Output of spec phase are a series of written specifications

The first thing people always think of is "specs are for bureaucrats".  That drives me a bit crazy.  I know as Americans we have a tendency to use new products without reading the instructions, but it is lunacy to develop a new product without first writing down the goals.  The mere process of writing is thinking, and the thinking will always push you to uncover more issues sooner before it is way too expensive to change things.  For all the talk about agile development, few ever talk about specifications as being the most important step in agility.  It is way easier to change a bitmap or do some editing of English in Word than it is to move around and rearchitect code. 

Yet at the same time we do not sell our specifications, we only sell our code.  So while we work to be very hardcore about having up front planning we do not develop our specifications to the point that they are the full documentation of the product.  It is too much work and not enough of a pay off.  So if you make a late breaking design change we might document the change in the change log but we don't go back and redo all the words in the spec.  Another fun one for reading specs from a long time ago is that the actual feature name used in the product is never what we named it during development--the Office Assistant was famously named TFC during development.  The "C" stood for clown.  I will let your active imagination figure out what the TF stood for.

So in writing a specification, the PM that worked on the learn phase now has to turn that learning into an experience that customers will have.  This is where the entire series of features, user interactions, boundary conditions, localization, ISV opportunity, and all the details are filled in.  A specification is how a developer will estimate the amount of time it will take to write the code.  So if your spec omits a lot of details and developers need to guess, then there is a good chance you will end up not being able to realize all of your dreams because too many things needed to get filled in a the last minute, plus your developers will not be very happy working with you.  So doing a good job on the spec is important. 

A great program manager will take their whole feature area and divide it up into specifications that match the developers or break the feature up into workable "chunks".  On average a PM writes about 8-10 specs for their area, and each one can be 30-50 pages depending on how visual (how many pictures).  Some specs are significantly longer and some PMs choose to write a larger number of smaller specs. 

Specs are not just for developers.  But the usability, product designers, and testers are all contributors to and refiners of the specifications.  In fact while the output of the Spec phase is the document, the final output is an "inspected specification".  If you've ever gone through a code review with a professor or mentor (as an intern) a spec inspection is like a code review.  During this time testers might push on you about boundary conditions or compatibility with existing products.  Product designers might work with you to improve the way the spec describes the overall interaction.  Usability might research the instrumentation from in-market products and use that to refine the priorities for the feature.  In fact the role of data is critical to Office PMs--if you run a web site you have click streams and logs, and Office through the Office Customer Experience Program has exactly the same--usage information for millions of volunteers (anonymous and private of course) and that educates us immensely on how to design features (Jensen's blog describes this as well).  So the spec, while owned by PM, is a work product of many contributors.

It is worth noting that many times along with a spec is a more detailed prototype.  This is particularly true for heavily interactive features.  In this case product design and PM work together to develop detailed prototypes of the work (often these will be tested in the labs with customers as well).

When the spec is complete the core part of development begins.  PM then transitions to refining the product.

Refine --> Output is the product

During the development of the product, PMs are constantly refining the details, working with development and test to determine what needs more clarity and what is working better than expected (that can happen) and what is going less well (that happens more).  PMs are on call to answer questions and "unblock" development.

More importantly as the real code becomes available, PM is anxious to try it out and make sure it is meeting their own design expectations.  Once the real code creeps along we will bring that into our usability labs to further understand how the product works.  A famous story of this phase of developing the PM role was that the first PMs were trying to improve a feature under development and ran some usability tests.  The feature bombed.  The PMs tried to explain this to the developers, but the developers insisted that the PM just picked "dumb users" because the feature was great.  So after a few rounds of this the PM dragged the Dev to the tests to watch 10 out of 10 users fail to use the feature.  The developer finally relented and the feature was fixed.  Today, developers can watch tests via streams or go downstairs to our usability labs and watch the tests in person.  Almost all developers I know are keenly interested in how their features are doing (and how the PMs are doing designing those features!) 

Another aspect of refinement is working with customers who use the early code.  While it is cool to throw a product out to beta and get some instrumentation and maybe get some qualitative input via mail, the only true way to understand how the product is doing is by deep engagement with real world users.  We do this this through a number of mechanisms that gradually expand the number of customers involved.

Early in the process we meet with a very small number (10-20) customers who spend days with us here on campus and learn about the product.  We walk them through all the details and solicit their feedback and input.  We did this for Office12 last summer and it was critical to our ability to get to Beta1 with a product that reflects real world usage and learning.  As a PM you will be responsible for getting together with these customers and learning from them.  We often follow up on site.

Another group we learn from that is a bit larger are our MVPs -- the most valued professionals.  These folks are the power users of Office. Our PMs all got involved with the MVP summit on campus and again worked with the MVPs in small groups to get their feedback and expertise into Office12.  The MVPs know more about Office than any other customers on earth--they are a wealth of information.

We're currently in the phase of learning from a broad set of beta1 customers.  We are doing this through newsgroups and through direct communication. 

You might also notice that many of our PMs are blogging (see the links to the right).  This is new for us (well for everyone) and also a great source of information and a great way that PMs are connecting with the web community.

Of course our senior program managers are also responsible for working with the press and product management.  So a lot of time is spent on communicating Office12.  There are a lot of reporters interested in Office and a lot of information to get out there. 

All of this Refine work feeds back into the developers where we prioritize and make sure that the very best product is built.  Of course that doesn't end with RTM since we're always refining and listening to customers (even though we're not "Web 2.0").  As I mentioned previously, we make over 100 changes every month to Office based on customer input -- so the product is always improving, and we're always learning!

PM Attributes

So those are the phases of program management and what you do as a PM in Office.  I would say that there are many unique elements to the role of PM in Office that are not emulated by other companies who have tried to create this role.  A good book that describes the uniqueness of PM at Microsoft is Michael Cussumano's book "Microsoft Secrets" or his new book, "The Business of Software".  If you're considering a PM role at Microsoft (or Office), from my perspective a couple of things you will get:

• A small team dedicated to solving customer problems and bringing the best technologies to the table
• Access to dedicated developers who are there to implement your ideas if you can live up to creating a great idea and making sure the details are thought through
• A very strong mentor who as part of small team will be there for you on a daily basis

If I had to think of the qualities that make a great PM I might list a few, but your recruiter and the interviews will help out a lot so don't let these discourage you from applying:

• Strong interest in what computing can do -- a great interest in technology and how to apply that to problems people have in life and work
• Great communication skills -- you do a lot of writing, presenting, and convincing
• Strong views on what is right, but very open to new ideas -- the best PMs are not necessarily those with the best ideas, but those that insure the best ideas get done
• Selfless -- PM is about making sure the best work gets done by the team, not that your ideas get done. 
• Empathy -- As a PM you are the voice of the customer so you have to really understand their point of view and context 
• Entrepreneur -- as a PM you need to get out there and convince others of your ideas, so being able to is a good skill

PM is unique to Microsoft and I think it is fair to say this is a role that is often copied but never duplicated.

--Steven

Over the last several months in my role here in China, I have given talks at several leading universities and met with many of the leading faculty and students working on technologies related to the Data Platform. I’ve also spoken at several industry conferences, meeting with customers, partners, analysts and other industry folks. There are many topics that come up at these meetings – changing technology trends, distributed development, the tremendous growth of Asia etc. But one topic that seems to come up more than almost any other is the question of how we organize and conduct our product development in Microsoft. I suppose this is only natural – Microsoft is one of the most successful software companies in the world, and the software industry here in this region is poised for tremendous growth, so it makes sense that people in the industry are eager to learn from the our experience over the last quarter century.

This is actually a very big topic and within Microsoft we have an Engineering Excellence group that actually runs courses that can span several days and provide an overview of Microsoft’s software development methodology, our engineering system, organizational structures, best practices, tools and technologies we use internally ensure quality, reliability, security etc and a variety of related topic. By no means would we claim that we have all this figured out perfectly and have a perfect system, but there is indeed a lot of accumulated knowledge and experience that we can share. And we do actually share this information, in appropriate form, with others in our industry, worldwide and also in this region.

As this is indeed a large topic, I don’t want to get too deep into this here, but I do want to address one aspect of our engineering system – the core disciplines that we organize our R&D teams around and the particular roles that each of these disciplines plays. I want to discuss this because I believe Microsoft does this a little bit differently from the rest of the industry even in the US, and especially here in China there is not a good understanding of these core disciplines and what role each of them plays.

Traditionally, the Microsoft engineering system has consisted of 3 “core” disciplines: “Development”, “Test”, and “Program Management”, also known as Dev/Test/PM for short. I’m going to touch on each of these briefly here, but I like to introduce them in a different order:

PM: When we think of engineering disciplines, most people start with “Dev”.  For me however, things really start with the Program Management discipline. At Microsoft, “PM” means many different things, but for me the core essence of the PM role is two things:

1.       The first part of the PM’s job is to understand the customer’s requirements and translate that into a functional specification of what we should build. This is where it all begins. If we don’t understand the customer, it is not very likely that we’ll end up building the right thing.

2.       The second part of the PM’s job is to work with Dev and Test to translate the initial specification into a living, breathing product.

I find that many people, especially here in China, think “Project Management” when they hear PM. Indeed, Project Management is part of a PM’s job (under #2 above), but it is only a part of the PM’s job. The real skill that a PM brings is the expertise to listen to customers, understand the world from their point of view, and then to design a solution for their problem. This does not just mean giving customers what they ask for literally, but to truly understand them and design a solution that solves their problems even if the customers could never imagine the solution – as the famous saying goes, if we had only listened to customers, we would have looked for a faster horse, not come up with the automobile.

Dev:  Of all the engineering disciplines, this one is probably the one people think about the most commonly. Dev is short-hand for “Development”, the folks who responsibility it is to actually design and build the software that we ship. The essential job of Dev is to take the functional specification produced by PM and translate that into an actual implementation. In the world of mission-critical system-level software, this implementation better be extremely reliable, secure, manageable, scalable and high-performance.  And the designs and implementations Dev produces better stand the test of time and last for several versions and years to come.

Test: The test discipline in Microsoft is much misunderstood, certainly externally, but sometimes internally as well. When I first came to Microsoft many years ago, I was (pleasantly) surprised to find that Microsoft had almost as many, if not more, testers as developers. Coming from a company that had a much less developed testing discipline (and where as a result, quality assurance was considerably weak), it took a little while to get used to what the essence of the Test discipline really is. The reality is that, in Microsoft, how fast we can ship software depends on not how quickly we can design and implement it but rather on how quickly we can test it. This is because every piece of software we ship, especially on the systems-software side, has to pass an extremely high quality bar. The Test discipline is really an complex area, and one where have learnt a lot over the years in terms of different types of testing that we employ – unit tests, functional test, integration tests, stress and long-haul tests, performance tests, security tests, localization tests, etc. etc. The set of tools and techniques we employ in test is truly some of the most impressive and complex – automated test harnesses, automated test generators, automated test failure analyzers, automated security “fuzzers”,  fail-point and state-machine based testing.

The three “core” engineering disciplines described above are like the 3 legs of a chair – you need all three of them, and in a balance, to have a proper engineering organization. No one leg can dominate the other – otherwise, you get an organization that may not be in touch with customers needs or one that does not pay enough attention to quality. Indeed, the three disciplines are a little bit like the branches of government – they form a system of checks and balances that ensures we understand what customers want, we design and build that with high quality, and we ensure that we deliver a product that meets customer expectations in every regard.

It is also important to emphasize that we aim to attract the best talent to all three core disciplines – the bar is equally high for all the disciplines, it just happens to be that the passion and skill-set for each is a little different. PMs usually have a passion for working with customers, conceptualizing what the product should do, and then working with their Dev and Test peers to coordinate all the work to make sure we deliver exactly that. Developers have a passion for building top-quality software – software that is innovative, simple, reliable, secure, scalable, high-performance and stands the test of time. And Testers are passionate about finding all kinds of ways to break software and making sure making sure we find all the issues and bugs before we ship it to customers.

When we interview candidates, a very important part of what we do is find out which discipline the person’s talent and passion really lie in and directs them accordingly. Of course, over the course of one’s career, one’s passion and talent may change, and the person may change disciplines as a result – I myself started in the Dev discipline before switching to PM. This is only natural and we actually encourage that as a way to build better teams.

Other disciplines

It is also important to point out that although the three disciplines mentioned above are what have traditionally been considered the “core” disciplines at Microsoft, there are several other disciplines that are also becoming increasingly important. For example, User Experience (UX) professionals are essential to ensuring that products are intuitive and natural for users to use. A great user experience can make the difference a product that customers love versus one they merely tolerate. UX is certainly very important for products aimed at end consumers, but it is also important for all our audiences – Developers, IT Professionals, Information Workers.

As we move into the Software+Services era, a variety of disciplines related to architecting, building and running extremely large-scale infrastructure becomes increasingly important. Again, while this has been true for some time for our consumer facing web properties such as MSN and Live, it is now becoming increasingly important for all our product groups as more and more of them take steps to evolve their products along the Software+Services model.

Many candidates I talk to often want to discuss what role at Microsoft would be the best fit for them and how they can grow their careers. The best advice I can think of is to work on a technology and a role that they are really passionate about. As I mentioned above, we value all the disciplines equally and a well-balanced organization needs great people in all the different roles. While different disciplines appeal to people with different passions and skill-sets, all the disciplines offer opportunities for innovation and great work. And all of them offer opportunities for advancement and leadership. Indeed if you look across the senior levels of Microsoft, there are leaders who emerged from various disciplines – what they shared was a passion for what the work they were doing.

I hope this discussion of the different engineering disciplines at Microsoft and the approach we take to them shall be useful for the many people who seem to be interested in this topic. If you have any questions or comments, feel free to post a reply to his entry.

Until next time – 再见!