Microsoft is broken! I assume you agree with me, but if not, leave a comment or email me. Instead of talking about how it is broken, instead I’d like to look at ways that I would fix it. Based on my observations while working at Microsoft and at a startup (PHP Fog), I am making a number of recommendations Microsoft could implement. Starting from the bottom, the product team.
I am not an executive so I don’t know how to fix Microsoft from the top. I was never in any of the board room meetings or executive meetings so my guess is as good as yours. However, I was a Program Manager at Microsoft for 5.5 years working on components in Windows Server, Windows Client, the .NET Framework, and most recently Windows Azure AppFabric. The PM is one of three key roles working on product development at Microsoft, along with developers (who write code), and testers (who write code to test the developers code). Here is the list of things I would change, you will notice a few reoccurring themes.
1. Fire 90% of the Program Managers
Developers write code, testers verify. The Program Managers do everything else. The reality is that most of it is just intellectual masturbation; it rarely leads to direct contribution to the product. They are delegators and when they don’t have work to do, they create needless work for others. They seriously can spend 80%+ of their time in meetings and dragging others into them too.
2. Release weekly, not monthly or annually
Most products work on several year release cycles, and a lucky few work on several month release cycles. Whether the product is released on a longer schedule or not, the product teams should be releasing new functionality, even in small increments, every single week. Every release should be made visible to the fullest extent. Let people use it, play with it, break it, and provide feedback.
The benefits of this are endless. This will boost moral as there will be continuous gratification. The need for long term planning (“guessing”) will be alleviated and replaced with real customer feedback. Time will be saved from nasty planning and review meetings.
3. Get rid of NDAs
Saying anything publicly about plans is frowned upon at Microsoft. Keeping your mouth shut is justified by the fear of making promises to customers which can’t be delivered. This leads to an overall fear about saying anything about the product at all. It also makes it incredibly difficult to have a meaningful conversation with customers about product plans and getting their feedback on the product.
4. Fire all of the “Evangelists”.
There are a number of people at Microsoft that get the awesome job title like “technical evangelist”. These people get to present at conferences, they blog a ton, they do video demos, interviews, etc. They have it made. But they are not a part of the product team. The problem is that they are a layer between the customers and the product team. The product team built the product and they should get the glory of “evangelizing” it. But more importantly, the product team needs to have a dialog with customers and use these communication channels to hear what customers are saying directly. This is the perfect opportunity for the PMs. This is what they should be doing.
5. Say no to architects, specs, reviews, or approvals
I can’t even begin to explain how much time is spent by the product teams writing specifications, reviewing them, updating them, getting approvals from architects, peers, managers, etc. This phase of the development lifecycle takes up some %25-%50 of the time spent by the team. There are so many things wrong with this process: (1) customers are not involved in providing feedback, (2) the work is justified as a necessity for communication, yet they rarely get read after implementation starts (3) they are outdated the day the developer starts implementing them, (4) Time spent on writing specs is time not being spent on other far more important things.
6. More open community
The Program Managers, despite being “the voice of the customer”, actually get very little opportunities to talk to real customers. It’s shocking. Support is provided by some people in India, blogs are written sparsely, only the marketing department has access to the Twitter and Facebook page accounts for a given product, and there are only a few rare occasions where customers can get in touch with the product team. The product team should have control of the social media, they should be encouraged to write blogs, use the MSDN forums to the fullest extent, be on point to provide support, etc. People at Microsoft will say “but anyone can go and do this”, the reality is that there are barriers to entry which just make it inconvenient.
7. Lower the bar for testing
The testers are often identified as the “quality gates”, the people that validate that the product does what it is supposed to do and that it does it fast and that it does it well. The problem is that the quality bar is so high that so much time is spent on ensuring that the product works the way it was “planned”; however, this also increases the time it takes to get the product into customers’ hands. The real testers are not the testers that work at Microsoft, the real testers are the customers. Once the customers validate that the product does what they wanted it to do, then the testers can start banging on the product to make it work well and make it work fast.
8. Fire the release managers
When you have a complicated schedule with weeks of pre-planning, planning, implementation, integration, stabilization, etc. you quickly need to hire a special type of program managers, who are called “release managers” at Microsoft. They are responsible for the schedule, pretty much like a Project Manager elsewhere. If some of the earlier recommendations are implemented, like a more frequent release schedule, lower testing bar, no review process, the need for the release manager will also be diminished (though not necessarily completely eliminated).
9. Refocus the PM role
Now I’ve fired 90% of the PMs, I’ve fired the release managers, architects and evangelists. This creates a gap which is prime for the PM. The Program Manager shouldn’t just “speak the voice of the customer”, instead, they should be fostering a relationship between the customer and the product. They should be providing support, blogging, presenting at conferences, tweeting, talking to customers with whatever channel available. They manage the team to make sure they ship small functional bits often and getting them into customers hands for testing.
Conclusion
There are two themes: go lean, and listen to your customers.
Based on these recommendations many people would be on the chopping block. In fact, some of the best people I worked with would be fired based on this criteria. I’m no exception. In retrospect, had I been my own manager at Microsoft I would have seriously considered firing myself.
