Bureaucracy. Threat or menace? Either, both, or neither? Or it depends!


a. Management or administration marked by hierarchical authority among numerous offices and by fixed procedures
The administrative structure of a large or complex organization


I was able to spend the day today with students at Harvard Business School.  I was fortunate enough to meet a number of second year students and was invited to participate in a class teaching a case on the development of Office 2000.  I spent a semester teaching at HBS and it was great to be back in a classroom where the students bring incredible insight to the problems we face in building Office.  This post is about a discussion I had a number of times today—the topic of bureaucracy.  The topic applies equally to undergraduate computer science majors and to MBAs, and is certainly one that based on your interest will generate further posts on the topic.

Up front, it is of course impossible to defend bureaucracy.  So any attempt to justify rules, process, hierarchy, etc. are met with a groan at best or a complete rejection at worst.  In fact it is common to just assume that anyone brave enough to defend such structure is either oblivious or stupid, or both, and in all cases probably a pinhead you would never want to work for.  After all, in the world of technology and the internet the one who is out there with no rules, no process, no hierarchy is the one who is going to win big while all those sloths with their spreadsheets and dashboards are all bunched up trying to plan their way out of a paper bag.  OK, maybe I went too far.  But the basic challenge in talking about this topic is how do you say that Microsoft is not bureaucratic when there are articles out there saying that the company has become too bureaucratic?  How do you talk about this topic without at the same time sounding like you like something which everyone obviously loathes?    

It is worth noting that I am sure people can share with me stories about how bureaucracy has stifled their progress at Microsoft.  We make mistakes and we have dumb things.  But I also heard a stories from HBS students today about how difficult the HBS administration is to work with (just ask them about recruiting!).  Of course I have friends at all sorts of companies that tell me (in private) stories of how bureaucratic their organizations are as well—some of these companies are even famous for claiming not to have any bureaucracy.  Organizations of more than about 100 people are all capable of dumbness—once you grow beyond grabbing money from the petty cash drawer you have process and once you have process it is a matter of time before you don’t understand what is going on.   If you don’t believe me then you just haven’t worked with more than a 100 people or you just never happened to stumble across the processes.

In class today we talked about the development of Office 2000.  This is a case that “Describes the history of Microsoft's Office product suite. Discusses evolution of the Office 2000 project. Set at the end of the project  the team must decide upon the direction for the next version of Office, as well as make changes to the process.”  This is a case that goes into detail about how we decide what features to put in the product and the overall engineering process.  It was written in 2000 after the release.  What is fascinating for me is seeing over time how students in different classes react to the case in the classroom—believe it or not even though the case is unchanged and the facts are the same, students have different views of the important issues of the case based on the perceptions of Microsoft in the market.  I didn’t expect that for sure.  [Note: business school is often taught by the case method—this is a way of learning through narratives with the goal of discussion the situation faced and the possible alternatives, but not necessarily about finding the right answer since most of the time there is no single answer.]

When the case was first taught, a lot of the focus fell to Microsoft’s plans for being successful in the market and how the product was another release of a successful product.  There was always a lot of talk about the big plans Microsoft had for the software and how it would lead to further success of an already wildly successful product.  And while the case brings up some issues relative to the challenges the team faced, most of the focus was on the challenges the business faced—was the product late, was it the right set of features, did the company do a good job listening to customers.  That was an era where our success probably shaped the perception quite a bit.

Today, the students picked up on issues in the case related to the efficiency of the development team.  Now of course that is an issue.  In fact the reason this was in the case was because shortly after the project was completed we did our planned (and rigorous) postmortem on the project.  From that we identified that we had probably pushed too much on to developers to keep the “daily build” of the whole Office product stable.  But in class, there was definitely a feeling of “see this is that Microsoft bureaucracy that we have read about”.   But wait a minute this all happened starting in 1998!

What changed?  Well very recently a perception has developed that Microsoft has become “slow” or that there is too much “process” around getting things done.  Certainly we have talked quite a bit about our efforts on some products and how we probably tried to get too much done and that caused us to take longer than expected and caused us to make changes to products.  But that is something that we have been guilty of from the earliest days of Microsoft—we’ve always had a pretty aggressive appetite for signing up for a lot of work (perhaps more than we could get done!).  Like nearly every software project, Microsoft has had projects fail to meet their initial ship dates.  As we saw in the Office 2000 case we were about 8 months late from our original schedule. 

In class a number of students, not computer people, said that it is crazy and we should just pick the features and pick the schedule and just meet it.  Interestingly, the discussion was then “how do you do that” and of course the way you do that is planning.  And of course the more planning you do the more you probably introduce bureaucracy.  Oops.

Here’s a quick quiz.  Which project will get done faster and have better quality at the end:

  • Project A – starts off with some developers that have an idea and they just start coding.

  • Project B – starts off with some developers that have an idea and they spend 3 months not writing code, but designing the architecture and interface and then they start coding.

Project A might “finish” faster but it will likely not be finished by any stretch, will almost certainly have a set of features that are not coherent, and probably won’t be very easy to sell unless the developers happened to spend a bunch of that time doing some research to understand how to price, position, and promote the product.  Now are there examples of Project A being wildly successful—of course there are.  Remember, this is a social science we’re talking about so there is a bell curve and anything is possible.  The question is how repeatable is it.  About the only time this is repeatable is when you’re cloning something that already exists or building an identical second version of an existing system (many open source projects have the advantage of building based on existing, running systems).

Project B on the other hand has a good chance of being coherent.  It has a good chance of meeting a customer need.  And most importantly has the best chance of not having to go through a major rewrite one or more times during development.  If you’ve ever tried to build a house or remodel a kitchen, you know that you don’t just bring in tools and start sawing and hammering away.  Software is no different.  Now are there examples of Project B being gummed up and a total failure—of course there are.  On the other hand, Project B can be a repeatable process and does not depend on super human programming skills combined with psychic market knowledge.

Returning to our case and the recent change in perception that students have had does raise an issue for me.  I certainly don’t think we’ve gotten more bureaucratic.  In fact if we were to look at the number of new features, the lines of code, and the breadth of products we have offered with each release of Office we are definitely doing more with the same or fewer developers on the project teams.  The question students asked to that point was “yes, but don’t developers feel like they have too much to do to ‘check in’ their code?”  The answer is of course—because you should just be able to type a line and then boom, everyone should see it.

But that turns out to be rather difficult.  The baseline comparison for this, especially for college hires, is the “edit-compile-debug” cycle we’re all familiar with in college.  You are the master of the machine.  You have no dependencies on anyone else.  You know every line of code.  This is an awesome way to write code.  It is also the best way to write projects that are the work of one person.  Anything more than that and you have a dependency.  At the same time, if you are working well as a team you can quickly have a 1+1+1 = 4 or better.  The challenge is that you have to put in some process to make sure that you get the benefit of using each other’s code and the benefit of working as a team.  It does not come for free.  Putting in the right process is very hard work.  It is super [sorry I used that word] easy to put in process that makes 1+1+1 =2.  Process can sap the life out of a team.  On the other hand, it seems absurd that you should be able to change “on a whim” the code of a system that is used by hundreds of millions of people—customers expect and demand that you have some process for deciding what to do.  Anything of any material complexity must have that rigorous view.  If it doesn’t then the system is a toy or the system just isn’t valuable. 

Everyone who has built a software project knows that once you have customers you have an installed base and therefore you have to be careful about changing things.  But you also have customers that come to expect features in a certain way.  You have customers that might want to have say in how things evolve.  You can’t just be an “enlightened engineer” and speak for every possible customer, every compatibility issue.  It is likely you’ll need some help.  Imagine for example, you wrote the code that decides what advertising to show on a web site (like we have on many sites at Microsoft).  You have a great idea to make it better and make a change and check that in—but oops, you didn’t know that product management had come up with a clever, revenue positive, pricing scheme based on how different ads appear.  You just changed the company revenue with that “flexible” development process.  You then find yourself backing the change out in the middle of the night.  Perhaps then the team will put some safeguards in place.

Once you put in a process that “slows” down that work there is now an official bureaucracy.  So you have to minimize that so that people can spend the time they have doing the things they like—developing, doing marketing campaigns, etc.  Pick any profession—writing for a newspaper, selling cars, being a surgeon, airplane pilot, banking, etc.—in every case people do not get to do their profession 100% of the time.  In all professions there is some notion of checks and balances or some notion of planning, arguing, agreeing, deciding, revisiting, fighting again, etc.  This is all a natural part of groups of people working together—the editor gets to make you go back and rewrite the article, the FAA makes the pilot take certifications, surgeons have to see patients outside the OR, bankers need to report on their returns, etc.  And surprisingly every profession when they have complaints they refer to this as the bureaucracy. 

As Peter Parker’s father said (sort of), “with power comes responsibility.”  So if you have the ability to put something on the front page of the NY Times then your editor is probably going to get in the way.  If you want to change the user interface of Office you bet that a lot of people are going to have opinions and you are going to have to spend the time planning and developing an architecture before you just start checking in code.

But you know through all of this discussion I kept thinking about the developments we have done in Office over the years (since the Office 2000 case) and Office12 in particular.  We decided to change the file format to XML in Office – actually the team decided to do it and we just did it.  We did not have any corporate oversight, no approval process.  We just did the work to make it real.  The new user interface in Office was decided on 4 levels down from BillG – it was done so without a big approval meeting, without “top down” forcing of a specific design.  Perhaps in a future blog, if I don’t get too many flames on this whole topic, I’ll go through the bottom-up process that led to the new UI.  Of course there were many big “fights” about *how* the UI should be done, but if it should be done, or who should do the work, or should we change our mind—none of those were mucked with unskilled by middle managers 🙂

One thing we did in developing Office 12 was take our organization and break the work down into very small “design/build teams” that go below the feature team organization I talked about earlier.  These “feature crews” allow essentially 1 or 2 developers to work side-by-side with test and pm on their feature areas with a private branch of the source code for as long as they need to in order to get the work done.  The “isolation” this affords worked very well for many teams.  It is a new process and we’re still learning.  But if you look at the feedback from the PDC and TechEd (and soon you can hear from our MVPs) we made a lot of progress in this product cycle that really impressed folks (we still have a lot of work to do).

Another thing that came up in the discussions today was the notion of “it sure takes a long time to do one product cycle”.  This is definitely a choice we make for Office.  Actually, we release over 100 product changes every month for Office XP/2003—these are customer requests, maintenance updates, and robustness fixes based on our instrumentation.  We just released a service pack as well, which rolls up ~6 months of these product changes into one installation.  We could release these “automatically” but we choose to do this on a more regular interval because that is what most of our customers request of us (obviously if we had a high priority fix we would be more aggressive).  For the full product releases, customers tell us different things.  Corporate customers sometimes say they would like a new version approximately every…10 years or so J  At the other end of the spectrum, popular computer magazines could use a new release twice a year since subscribers like that J  We choose about every 24 months or so since that is a good midpoint. 

There’s been a lot written about moving very fast and getting new things out there.  That is all well and good.  For new markets this is definitely something that Microsoft and many companies do—we released big updates for InfoPath and OneNote less than a year after the first release (about the time between releases of things like the search bars that are popular these days).  But the truth is that as a developer you know very well that you can only write so much code in say 6 months.  And this is even harder if you don’t have any time to plan.  And of course if you are an MBA you know that you can only make a big deal in the marketplace about a very significant innovation—and doing that is hard if there is not a lot of engineering to support that.  Every once in a while a small amount of engineering can yield a whole marketing campaign (red squiggles or AutoCorrect in Word).  But as we all know, most new features are no massive breakthroughs upon which you can build a whole marketing campaign.  So you have to build a set of features that solve a customer scenario or theme.  This is an area where in hindsight people always find counter examples—but the question is not can you find counter examples in hindsight, but can you define today a feature that will hit it out of the park in six months?  If you can, you’re hired—send me your resume!

Despite this defense [I know it comes across like that, but I didn’t mean it to be] of bureaucracy it is obvious that like any organization we’ve done some silly things.  We’ve put in processes that make no sense.  We’ve decided things as an organization that are plain dumb.  How do we excuse these?  We don’t. MS people send me mail. I want to know about them.

Microsoft is a learning organization. It is in our DNA.  We are hypercritical about our own work.  At the end of every milestone and project we look back and then change things going forward.  We take out process as much as we can.  We change processes.  And most of all, if something isn’t working this is a company where you can send an email rant to the very top leader and I guarantee you that you will be heard (heard is different than necessarily agreeing or acting, though).  I know when I get mail like that I am in your office right away. I know many companies have a suggestion box.  I don't know of many that have one that is near instant.

Building software that 400M end-users depend on and pay you for is a big responsibility.  We’re always balancing that responsibility with trying to push the envelope of new technologies. 

I personally like definition (b) of bureaucracy and can't stand definition (a).


Comments (50)

  1. steven_sinofsky says:

    This is rflaming’s comment — not sure of the problem:

    Steve Sinofski’s Good Bureaucracy Post

    Office Sr VP Steve Sinofski blogged about Bureaucracy: good? bad? both?.

    I like to think that two examples of how Office invests in helpful process are Windows Installer (technology) and Windows Installer XML (authoring language, built largely by Office deployment alums).


    Windows Installer (MSI) was invented in Office as a way to provide compelling deployment features for consumers and corporatations. Part of the reason I loved working in Office is fantastic way it’s willing to complete the scenarios even if it has to build stuff that might have been better provided in the operating system (another example Watson http://channel9.msdn.com/ShowPost.aspx?PostID=118317)


    As Rob noted in his philosophical musings about building setup for software the developer that wrote the feature knows best how to finish the feature. This is quintensential Office (sp? note: need a word blogger so poor spellers like me can get spell check) .


    Another thing Office12 got right is the Feature Crews VBLs rather than the Windows-based VBLs as Office’s approach focuses on customer features and experiance regaurdless (sp? again ;^) of the org chart where my experiances in other parts of Microsoft base their VBLs strictly off org chart, not customer features. (Oh lord, do I miss ohome, ocheck, osetup, and the rest of the developer infrastructure from Stephan.)

    Office doesn’t have every thing right but it was much more direct to provide customer value than I’ve found elsewhere in Microsoft.

  2. Bud Labitan says:

    <Microsoft is a learning organization. It is in our DNA.

    I am glad you mentioned this view. I would like to post the suggestion that there should be an easier, user-friendly website to post an innovative suggestion for the individual who is willing to "quit-claim" on innovative ideas.

    The development of an Opportunity Management Center was a good step forward. The next step in encouraging public generated product and feature suggestions and innovations would be a simplified posting page (with the proper disclaimers posted above the text box.)

    Bud Labitan

  3. Graham says:

    This blog succintly sums up what shareholders think about the raging bureaucracy at MSFT:


    You can defend the concept of bureaucracy all you like but the fact is that MSFT is drowning in it. I hear developers complain about having to wait weeks to check in a line of code. This is unacceptable.

    Give greater autonomy to small groups, together with the ‘grand plan’ you were talking about, and stop micromanaging everything. In particular don’t introduce too many dependencies. You’ve failed the shareholders and we expect far better.

    I cut my losses last week and sold my MSFT holding because the dividend looks pathetic and you have few businesses growing faster than mkt. I’m glad I did. Enjoy competing against Google Office.

  4. BradC says:

    "Perhaps in a future blog, if I don’t get too many flames on this whole topic, I’ll go through the bottom-up process that led to the new UI."

    Yes, please. I’m greatly enjoying both yours and Jensen Harris’ blog discussing the details of Office 12.

    I think the more you can explain WHY you made the radical UI change and HOW that process occurred, the better acceptance you will get of Office 12.

  5. Bud Labitan says:

    <Enjoy competing against Google Office.

    <Why you made the radical UI change and HOW that process occurred

    My 2 cents on competition: Think Disney Theme Parks versus all the rest. Develop SCA = Sustainable Competitive Advantages

    (Note: Back around 1966, Warren Buffett went to see Mary Poppins at a theater on Broadway about 45th at about two in the afternoon. He went to see if he thought this thing could be run over and over again in the future.)

    I would like to read a discussion of the products’ "Sustainable Competitive Advantages."


    On that OMC MMBA idea, the key "sca" is to gather and rank "important management concepts" and "best practice ideas", then cross link them using bayesian probabilities. Of course, make sure MSFT gets the patents.

  6. steven_sinofsky says:

    Bud Labitan,

    Thank you for the feedback on the opportunity management center. Right now that is the process we have in place for unsolicited ideas.

    If folks are interested in sending Microsoft ideas for business opportunities, just email them to omc_AT_microsoft.com. (using @ instead of _AT_).


  7. steven_sinofsky says:


    Thank you for your thoughts. As you can imagine I am also a shareholder of Microsoft.

    I am trying to share my perspective through this blog.


  8. steven_sinofsky says:


    Will do — thanks for the encouragement.


    PS: Jensen’s UI blog is http://blogs.msdn.com/jensenh

  9. AnonPM says:

    I moved to Office from another division recently and was surprised to see that the concept of a Feature Crew was even required. In my previous group, the dev, test & PM for a feature worked together without the need for an InfoPath form to bind us together. We worked based on a feeling of ownership and an understanding that our feature was important to our Product/component. We were answerable to the team’s management if our feature was broken, unusable or was holding back a milestone.

    The very fact that Feature Crews are required in Office stems from the fact that Dev, Test & PM are seperated Organizationally with only a common GM/VP and have their day-to-day schedules and priorities arbitrarily decided by their management. This leads to each discipline aggressively defending their work-load with little understanding or vision about the team’s or product’s priorities.

    To me, the Feature Crew is nothing but an Infopath form in which I need to set to Red, Green or Yellow every Friday so that my manager can tell others how "66% of our team’s features are doing well, while we’re concerned about 16.67%" and thereby come off looking like he has an excellent handle on the pulse of the team!

    – new Office()

  10. Derek Curry says:

    At what level of bureaucracy was the decision made that MS Office won’t support the OpenDocument format? I’m curious because it doesn’t seem like the kind of decision an engineering team would make.


  11. Bud Labitan says:

    < just email them to omc_AT_microsoft.com. (using @ instead of _AT_).

    For those with a structured business plan, I think the OMC process works well. However, for those with a novel, innovative, and germinating idea… I am not so sure.

    In my medical view, many creative types seem to cycle up and down. Not necessesarily bipolar, but a bit cyclothymic. Apparently, when they cycle upward in the positive direction, and if they have a predisposition to innovate and experiment, then more innovative features and ideas are generated. Unfortunately, many of these type would not make it through half of a structured MSFT interview.

    As an admirer of MSFT who recently read the Businessweek and Forbes articles about the pressure to innovate new ideas and products; I am concerned that a better process needs to be devised to deal with this subset of "creative types" that I mention. My perception of MSFT having labled the office the OMC, gives the user the perception of: "Here is the bureaucrat who can direct you to the next department’s bureaucrat…"

    As discussed in marketing and advertising, perception is important. Perhaps OMC should have been called ODC, Opportunity Discussion Center, and have one Psychologist and Communications expert onboard to help analyze ideas?

    Check out the PBS video: The Persuaders

    Especially focus attention on the section on Frank Luntz. A corporate consultant, pollster and political consultant to Republicans, Luntz’s specialty is "testing language" and finding words that will help his clients sell their product or turn public opinion on an issue or a candidate.



    Call me when such an Opportunity Discussion Center is up and running.

  12. Don Dodge says:

    Steve, Great post. I worked in the start-up world for 12 years, most recently at Groove, before joining Microsoft.

    Software companies go through a natural evolution from start-up to maturity and it effects how and when software is released. I describe this evolution in more detail in my blog "Don Dodge on The Next Big Thing" http://dondodge.typepad.com/the_next_big_thing/2005/09/product_release.html

    Here is a snippet from that post:

    By year four, the trajectory of the company is pretty clear. Everyone hopes to reach “escape velocity” on the way to the moon and avoid the death spiral that is so common. By year four you have an installed base of customers to worry about. New releases must be backward compatible. You can’t just blast out new features like you did in the first years. Quality becomes critically important. The test matrix for operating systems, hardware platforms, network environments, browser versions, etc becomes mind boggling. International markets want localized and translated versions. The installer code needs to be able to install from any prior release point. The sales people are constantly coming back with big deals that require “just a few little features” that we don’t have on the road map. Engineering wants to go back and fix quick hacks and old architectures that were developed on the fly in the first few years. These things must be done to achieve the quality standards and performance requirements of our new F500 customers.

    It is the natural evolution of a software company and I have seen it happen many times. This is how a company goes from delivering 4 releases in a year to 1 release in four years. It is unavoidable, and in fact necessary, in the traditional software business. Multipy this evolution by 30 years and millions of customers and you have Microsoft. Releasing a product is analogous to planning a space mission to the moon.. Incredibly complex. truly rocket science.

    In my start-up days when things got really crazy I would tell my group “Software is never done”. The nice thing about software releases is that if you do it really well….you get to do it again. If you don’t the game is over. Enjoy the moment.

    Microsoft has enjoyed 30 years of exciting moments. An amazing record of accomplishment.

    Don Dodge

  13. It’s a nit, but it was Peter Parker’s uncle 🙂

    Also, almost every part of the Vista "reset" has involved additional bureaucracy. And let me tell you, dealing with some of it has been a total pain in the neck.

    But the benefits of the overhead is absolutely worth it. We’re GUARANTEED that every single feature has a spec, because we’re forced to write the spec. We’re GUARANTEED that test is signed up and on board with it, because test is forced to write a test plan, and development is forced to sign off on it.

    It’s a pain, but I completely believe it’s worth it.

  14. Worried Observer says:

    I would like to second the question about the OpenDocument format. An answer would be interesting for shareholders, too, because it would seem that whoever made that decision is responsible for a loss of business in Massachusetts, not to mention a widely-publicized victory for Open Source. Microsoft doesn’t need this sort of thing.

    In the greater context of this blog entry the question becomes: Do we know who is resposible for this (small but annoying) defeat, or does the bureaucracy spread the blame out so thin that it ends up being nobody’s fault (again)?

  15. steven_sinofsky says:

    AnonPM — just send me a note. I’m sure there is something that is new so just unclear.

  16. steven_sinofsky says:

    Folk interested in OpenDocument please feel free to visit Brian’s blog on http://blogs.msdn.com/brian_jones.

    I am of course responsible for the development of Office and thus this decision.

  17. steven_sinofsky says:

    LarryOsterman – frack you are of course right it was Peter’s uncle!!

    Agree with you on the comments about the Vista team. There is still more to improve not just within Vista but for our whole industry. Software engineering is really only 25-30 years old or so–so building things is still a relatively new set of techniques (say relative to building bridges, making cars, or doing chemistry). We have lots to learn and improve as a discipline. 25 years ago there weren’t products in use by 500M people in 500M different ways. Our discipline hasn’t scaled to this level as effectively as we need for it to scale.

  18. Great article, Steve! /applause I have compiled my comments to my own blog in order not to having to write them twice:


  19. Ben Canning says:

    AnonPM, I would love to talk to you about the Feature Crew process and how we could make it better. Feel free to swing by and chat – anonymously if you like. I can certainly see how someone new to the team could see the feature crew process and think ‘Holy crud, they need an InfoPath form to make dev/test/pm work together!’ and I agree that would be terrible if true. But I don’t think it is. Let’s ignore the InfoPath form for the moment – it’s the least important part of the Feature Crew concept.

    The basic idea with Feature Crews is very simple – Dev, Test and PM should work together in as tight a loop as possible and make their chunk of code stable and functional *before* it gets checked into main. The latter half of that statement is the key point. We’ve always had Dev, test and PM working closely together. What we haven’t always had is a standard process for testing code in Private Release before it went into the main build. Checking into main and then testing works ok on a small team, but with 700 developers checking into Office main, you can very quickly end up with a mess of conflicts if you’re not careful. The overall build is unstable, and test gets blocked on testing until we go through a painful integration process that lasts weeks.

    A much better approach for a project of our size is to identify discrete ‘testable chunks’ of work, and then facilitate the process of dev, test and pm iterating on that piece of work outside of main until the code is solid and only then checking it in. In Office 12 we formalized that basic notion and called it ‘Feature Crews’. Every ‘chunk’ of code to be written would have a Crew built around it, and we’d ensure that appropriate testing and design review was done on each ‘chunk’ before it was checked in. To facilitate this, we built tools to make publishing Private Builds, tracking bugs and scheduling the Feature Crew work easier, including the creation of an InfoPath form to help us keep track of what crews had been created, and how many were done or not done.

    Overall I’d say Feature Crews have been a big success this release. Despite the vast amount of change in Office 12 – new file format, new drawing layer, new user interface, etc – Test was able to find bugs at 3 times the normal rate during implementation compared to prior releases In other words, test was not blocked by unusable builds and was able to find bugs sooner than usual. And overall stability improved as well – we were able to produce a stable dogfood build at the end of every single development milestone and push that out to the entire Office organization, something we’d never achieved before. Dogfood 4 went out to several thousand folks inside and outside Microsoft as well, providing us with earlier customer feedback than ever before.

    For all its successes, there are definitely things we need to do to streamline the Feature Crew process. The toolset is not currently integrated into our dev scheduling process – teams are currently forced to keep two sets of books. That’s painful and silly and we need to fix it for next time. There are folks thinking about how to do that right now – I’ll be happy to put you in touch with them. To your specific comnents about the InfoPath form, I agree that late in M3 we started to use the forms more and more as a schedule management tool – thus the homework around marking things ‘red/yellow/green’ and so forth. Although I was one of the architects of that plan in my ship driver role, I’m pretty sure that was ultimately a silly bit of bureaucratic overkill that we will want to rethink for next time. It is useful on the one hand to have a higher level set of ‘chunks’ that you can track at the Office box level – we haven’t had that before this release, but I think we’re still figuring out the right way to track that without imposing a bunch of silly homework on folks. My goal for next time is to integrate the Feature Crew concepts into the basic dev scheduling we already do, so that as much as possible any tracking of FCs that we do just falls out organically from what folks are doing anyway.

    Please feel free to follow up with me here or offline about any ideas you have for how we can improve things.

  20. Bud Labitan says:

    Ben Canning, I enjoyed reading your post on Feature Crews and a standard process for testing code in Private Release before it goes into the main build. I wonder how much code and library "code reuse" you have these days. And, how far the state of the art has come in the past five years. Are there dlls that are so good that they are locked in stone for "enduring use" over the next 10 years?

    Does a feature crew ever think in terms of "sustainable competitive advantage"?

  21. Ben Canning says:

    To Bud’s questions – the group I work in is Office Shared Services and we are pretty much all about shared code and code reuse. The idea is that wherever possible we try to build shared functionality in our organization that the app teams (Word, Excel, etc.) can then just leverage in their apps. (Of course it’s complicated in actual practice – how much can we do in shared versus how much custom hookup do the apps have to do, etc.) There is not much code that is ‘set in stone’ in the way you describe. If nothing else the continuing evolution of security threats requires that you go back and re-evaluate and improve even older libraries that you thought were ‘done’ all the time.

    ‘Sustainable Competitive Advantage’ is higher level than the typical feature crew’s scope – if you want to think of the hiearchy of scope you have the broad system level vision, then the vision for an individual application, then a feature specification, then a feature crew working on that feature, then the individual dev schedule tracking individual work items in hours. The feature crew is down at the level of implementation – so they are worrying about whether or not they are solving the particular customer problem they’ve set out to solve, and particularly whether the given implementation is stable and useful, but they are not really thinking about higher order strategy per se. Not to say that those same folks don’t think about that in other contexts.

  22. Bud Labitan says:


    Here is my idea and challenge for a HD project that I give up freely. No claims attached. With your work in Office Shared Services, you can imagine the development processes this might require. If you were assigned this baby with a mandate to minimize bureaucracy and a target release date of 1st quarter 2007, where would you start?

    Microsoft MBA ( vision summary for the 50 GB disc version )

    Microsoft MBA would join the list of products as a multi-purpose HD-DVD, Blue-Ray, and X-BOX "A.I. inspired software product" targeted at business, business owners, business education, college students, government, and training users.

    At a baseline minimum, Microsoft MBA for HD-DVD, Blue-Ray, and X-BOX would deliver the core content of a basic MBA education, and highlight the top 50 concepts and best practices from each business academic discipline.

    Its core competitive advantage over potential rival products would be an A.I. inspired hidden helper system developed by Microsoft Research that uses Bayesian Probabilities for anticipating linked concepts in management education. This MMBA logic engine would also be designed to weave together case simulations that merge real and generated video clips to engage a user like a well designed Madden NFL football game. Thus, it would offer a customized learning and review experience based upon the user’s prioritization of interests. MMBA would expand an opportunity to support audio, video, and software tools compatible with Microsoft Office Tools, Encarta, and X-BOX Technologies. Its enduring competitive advantage would center on upgrading a superior core logic engine and graphical interaction experience.

    Robert F. Bruner of Darden wrote that the ideal MBA graduate should be able to:

    Level 1. Retain basic understanding of core tools and concepts. The task of the student here is to acquire "the basics" of the Areas. The intellectual challenge is one of induction: to assemble a working grasp of core knowledge from its various parts.

    Level 2. Applying good practice. The task of the student here is to develop sound judgment about the efficient and effective application of core knowledge. To "apply" means not only to use the tools correctly, but also to extract practical insights and actionable recommendations from the results of those tools. In many MBA programs, this is as high a level of development as many students achieve.

    Level 3. Modification and reinvention of practice: building critical judgment. The task of the student here is to develop an inquiring and challenging mind-set. Skills of advanced problem identification, clinical probing, capacity for independent and original learning, and systems thinking are evidence of attaining this level. Critical thinking should be a desideratum of any excellent university education.

    Level 4. Creating new ways of thinking and new analytical tools. This highest level is characterized by an ability to invent: to take creative leaps from a base of commonly understood core knowledge, which has been applied well through an inquiring and challenging mind-set.

    On a PC, MMBA should help the user accomplish Levels 1 and 2. And it should set simulations experiences that stimulate the user to develop an inquiring and challenging mind-set. Skills of advanced problem identification, clinical probing, capacity for independent and original learning, and systems thinking are evidence of attaining level 3.

    On a PC, the MMBA program would generate a customized case simulations and offer up an arrangement of linked management video clips, tutorials, and outlines in an A.I. generated linked sequence based upon the user’s interest. Similar to the use of probabilities in an old dos program for the medical field called QMR (Quick Medical Reference), which was capable of generating a list of differential diagnoses based upon signs and symptoms, the MMBA logic engine could generate a list of linked video clips, audio clips, best practice ideas, and review outlines; and act like a simulated professor or mentor customizing your business education/review.

    Build in "enduring greatness" into "the user experience" by studying these TOP 100 AMERICAN FILMS (Adjusted).

    Gone With the Wind (1939)

    Star Wars: Episode IV – A New Hope (1977)

    The Sound of Music (1965)

    E. T. The Extra-Terrestrial (1982)

    The Ten Commandments (1956)

    Titanic (1997)

    Jaws (1975)

    Doctor Zhivago (1965)

    The Exorcist (1973)

    Snow White and the Seven Dwarfs (1937)

    An X-BOX targeted version could offer a generated graphic experience where the A.I. generated graphics appear near-reality, and the video clips are rerendered closer to the near-reality resolution. That way there would appear a seamless continuity to the generated simulation or lectures. Advanced versions of MMBA could be engineered to run with simple speech commands to generate audio review clips in the mobile setting. Continuing research on human-computer interaction from MR can be applied to make MMBA a perennially valuable office, home, and classroom edutainment tool.


  23. steven_sinofsky says:

    Bud Labitan,

    I appreciate your comments but this is way off topic. Perhaps your own blog would be good for ideas and writing of this length?

    Thank you for your understanding,


  24. James says:

    Your points are all fairly good, but ignore the bigger picture. Firstly, not all product groups in Microsoft are the same – Office would tend to attract the best people and so be among the better groups in the company, but there must be tens if not hundreds of groups managed by 3.0s that never make a profit. Secondly … I had a comment here, but lost it. Possibly something about incumbent monopolists and open formats, I dunno.

  25. budlab says:


    Thanks for the idea. Which blog base camp do you suggest? Is blogs.msdn.com open to the public for setting up a blog?

    I do have a small site on yahoo that has sort of turned into my blog. I maintain it as an independent group created to provide a competitive advantage in the networking and development of Alumni, Students, and Friends of the Purdue University Calumet School of Management. The university is MSFT friendly, although IBM had recently made some gestures to the CS department. I would like to see the School of Management there innovate more tools and templates for Office. They run Office 2003. If my long winded vision ever got off the ground, I believe that some of the management content and video clips could be developed at the PUC School of Management more cost-effectively than HBS and others.



  26. Andras Ludanyi says:

    Graham wrote: "This blog succinctly sums up what shareholders think about the raging bureaucracy at MSFT:


    I know it’s off topic, but…

    I’ve been reading this http://msftbagholder.blogspot.com/ blog, and it is ridicules. First the above statement that this is the sums of what shareholders think about MS is a “don’t even comment stuff”, then this blog is repeatedly calling for “It’s time for Bill and Steve to go”… just to clarify to our friend who own this ridicules blog, the shareholders don’t appoint management and this means they don’t call for “to go of someone”, they simply appoint members of the board of directors, and these directors hire or fire executive management. The shareholders can buy or sell shares, and vote that’s what they do. The corporation has a purpose to make profit, and long term profitability is strongly associated with customer satisfaction, and as I know MS is profitable and have a growing high customer satisfaction rate. And the only kind of shareholder opinion represented by this ridicules blog is the one who want some quick money, the very immature kind which still couldn’t figure out that the .com kind of emerging technology market is gone forever. Owning MS shares in this moment is the best investment one can have considering mid and long term investment strategies.

    And about the post; it’s great one and it’s only made my beliefs stronger, that every state of the things is depend on the circumstances, which means in a company as large as Microsoft and which has such a great responsibility, the existence of organizational structures is a must, and of course there is some mistakes, but generally I think Microsoft is really doing a great job on organizing development.

  27. Andras Ludanyi says:

    I think the story is that Microsoft is in a paradigm shift from the Knowledge to a Creative area (from Knowledge Economy to a Creative Economy), the focus is shifted from the technology to the anthropology objectives, so Office 12 is 100% a move in that direction. The whole bureaucracy stuff is just a kind of a misunderstanding of an ongoing concept of get things done, by the people who are mostly inexperienced with large scale development with customer focus. So as Mr. Sinovsky said most of the mistakes is originated from the fact that this completely new approach is not yet established and until the appropriate tools, methods and metrics would be developed some of the more inert and obviously not enough creative people will experience this as a slow down and slow downs is usually associated with bureaucracy, but most of the times it is a lack of clarity, the lack of understanding, the state of a chaos which is a natural step in the process of change. Microsoft extraordinary focus on innovations is just another prove of this trends.

  28. AnOfficeDev says:

    I don’t equate engineering process with bureaucracy. We need processes as we’re lots of developers all changing the same code. Maybe we don’t have enough processes as anyone can change code almost anywhere. We don’t have stable components that can be used as building blocks as we’re rev’ing the components as fast as the higher level applications.

    The thing that depresses me about our development process is the amount of time that we spend writing code versus the amount of time it takes to ship a new version of the product. That’s not because of bureacracy; its because we have so much old, crufty code written by smart people right out of college. I think feature crews will help this ratio over the long term.

    Regarding infopath forms and other kinds of real bureaucracy, I try to stay below the radar and let PM and my lead take care of those. I try to ignore pesky leads and managers who take too much time asking about particular bugs and number of bugs.

  29. AnonPM says:

    Ben, Thanks for taking the trouble to write a thoughtful reply. I appreciate it. I see that others have brought up my concerns and more on the mini blog. I’m also busy with Beta 1 (and sure you are too), so I won’t follow up with a response now.

  30. AnonPM says:

    Ben, Thanks for taking the trouble to write a thoughtful reply. I appreciate it. I see that others have brought up my concerns and more on the mini blog. I’m also busy with Beta 1 (and sure you are too), so I won’t follow up with a response now.

  31. In the question about "Project A" or "Project B", there are more options than that, and one of the problems that MS has is that we’re stuck in the "Project B" philosophy.

    I’ve seen many Project Bs at MS that have spent 3, 6, 9, or even 12 months working on design up front that have been fiascos. The basic problem is that even experienced people with good problem space knowledge are designing without real-world understanding of the development tradeoffs (perf critical areas, customer usage patterns, usability, etc.) that only come from creating and using the software.

    This approach generally leads to overly baroque designs in which too much emphasis has been placed on code flexibility, and, more importantly, an organizational unwillingness to deviate from the plan, because of the huge investment in it. I can think of two or three groups that have slipped hugely because of this when they ignored modifying their design for too long, but I’ll refrain from naming names.

    So, I don’t want to work on Project B. I would rather work on Project A, assuming they use one of the Agile methods. Yes, it does look like they’re just "starting coding", but after 3 months, they will have gone through at least two iterations and we’ll have gained a tremendous amount of knowledge around the project *and* we’ll have something to show to people for real.

    While project B will just be entering its first coding milestone, and in my experience will not have something to show for another 9 months (given typical MS product cycles).

    That’s how to create innovative software that people love. But to do so would require a radical reduction in the dependencies and process that is in place, and I’m fairly pessimistic that that will actually happen.

  32. The biggest problem with process is that it gives product teams the wrong focus. The benchmark in which teams are evaluated is "how well do you fit into the process?", and teams work very hard to not be the visible outlier.

    The "daily beat" is all about builds, bvts, integrations, etc., and so people naturally focus on that rather than focusing on customers.

    That’s why bureaucracy is so bad. Customers think that we’re disconnected, and we are.

  33. steven_sinofsky says:

    Eric you raise two interesting points worth commenting on.

    First, as I mentioned what we are talking about is a social science. For the most part you can offer anecdotes that can prove/disprove any choices in creating a product. For every example of a product that got bogged down with planning I can probably offer a product that started guns ablaze coding and went down in a ball of flames.

    BUT regardless of ancedotes, the only thing that can be done repeatably is to have a planning phase for a product. That itself is open to corruption of a process–you can plan too long or go in the wrong direction. But your preference of Plan A is one that relies on luck, acts of God, or super-human abilities. There is no doubt that products have come about because of that, but usually not more than once per person and usually not sustainably.

    I am confused by the connection you make between having a process and it becoming the focus. This does not have to be the case. Again, it can be the case. But saying that if you have a process it necessarily becomes the focus and that it is necessarily not what customers want is not a leap I would make. In fact you need to be careful about saying we should only focus on what customers want, since that would leave out teh whole notion of revenue and costs–customers generally don’t care about either of those. However, customers do care about quality and features, and in fact they care that the product have uniform and predictable quality and substantial features that integrate with their existing infrastructure. My experience has been that process is very helpful to achieving those customer goals.

    I think what you are doing is saying that only bad things can happen if you plan or if you have a process. I think what I am saying is that it is possible for both planning and process to go wrong. But I am also saying that if you want to be around for the long term, have a repeatable software output, and have an ability to reliably address market and customer needs, then the only demonstrable way to do that is to have planning and process and to do that well.


  34. With agile methodologies like extreme programming, Project A can do the planning and refining as they go along by staying close to the customer – that’s going to work well for a limited number of customers or a limited set of customer types or where you have close integration with customers. In real life, they’ll probably be Poject A-a: they’ll have a certain amount of planning first. This has all the potential to be riddled with ‘crufty code written by smart people right out of college’ and to disappear up its own code tree if the inital approach is too wrong and doesn’t get corrected, but it has strengths too. MSN Spaces seems an excellent example of agile development based on tight feedback loops. In the end, it’s horses for courses: methodology A can work better than B for the right situations.

  35. steven_sinofsky says:

    Hi Bud — this isn’t the forum to express your views on off-topic issues. How about keeping these on your blog?


  36. steven_sinofsky says:

    Readers and subscribers,

    I apologize but I removed a comment from an anonymous person who chose to use this forum to comment on their own agenda as a former Microsoft employee. I welcome discussion and debate, but the comments section of this blog is not the place for it if it is specific to a personal situation. For that, please start your own blog and link to it from here.

    And as I keep offering, Microsoft people do not need to hide behind anonymity and are welcome to send me mail directly anytime. In addition, the contact link also works.

    I do not want this blog to turn into a /. forum where people avoid it because of the falling signal/noise ratio.


  37. Ian Beyer says:

    With regards to your comparison between projects A and B, I’m reminded of an (anonymous?) quote we have up on the project board at work:

    "If I have only eight hours to chop down a tree, I’m going to spend the first six sharpening my axe"

  38. Anonymous says:


    What do you think is an accetable proceess overhead for a project like office? If there is more than 20% overhead (the process makes you take greater 1.2 times the actual time you take to complete without the process) do you think it is still accepatble because of the reasons you quoted? Also do you have an idea of what is the current process overhead?

  39. steven_sinofsky says:

    I would not know how to count "overhead" — some might think of lunch as overhead 🙂 Are learning new skills overhead? Is spending time making sure you know what other developers are doing overhead? Is reviewing a specification before you start to write code overhead?

    I think the goal is basically that you should not have to do things in your job that don’t help you. If you are doing things that you feel are just for someone else, then that is probably unnecessary.

    A lot of folks think that for example if you are a developer, then anything that isn’t coding is overhead. This is a shortsighted view, ihmo. For example this does not allow for quality, performance, reliability work that you might have to go and backtrack or have others do code reviews. Many people think of this as overhead, which I don’t believe is right.

    One of the things I believe to be the case is that a lot of times overhead viewed by one person is just a lack of context or understanding of the bigger pictuer or larger goals overall. For example, if you have to go and remove all the compiler warnings from your code and that involves a lot of manual work you don’t like it is easy to call that "overhead". But if the larger goals of the code are to be clean and able to be managed by different sets of parsing tools, then this is not overhead but necessary withing the larger context of the project. So it is important for the developer to understand that the project is always more than their code–there are other’s code, customers, market goals, etc.

    So a lot of times one person’s overhead is another person’s objective. The trick to managing a product is not to let those things happen that no one can explain the benefit, and to avoid the situation (at all costs) where there is work that is being done that only benefits somene else.


  40. A! says:

    Where are all the articles on MICROSOFT drowning in Bureaucracy?????

  41. A! says:

    Would really like to reas some of them!

Skip to main content