The Decline and Fall of Microsoft? Conclusion.

What can Microsoft do to reverse the trends that I’ve talked about in the last 4 posts? First, let me admit that it’s possible that Microsoft accomplish this by doing what it’s always done: grinding it out. Keep investing in Windows Mobile; keep pouring money into MSN; invest some serious money in the Zune business. Sheer grit and determination can overcome many missteps. If Microsoft can persevere, they can wait for a competitor to make a major mistake and then step in and take up the slack. The Sony PS3’s strategy for online gaming is an excellent example of this. Sony made a bad decision and the XBox business was able to profit from it.

If I sat on the Microsoft board, however, I would be very nervous counting on the “grit” strategy. I would be looking for bolder ways to transform the company while it is still healthy and dominant. As I suggested in the first installment of this series, I think Microsoft has to start by asking itself the ultimate TQC question: what is it doing wrong that is causing it to generate bad processes? “Processes” here can refer to many things. Product design and software development processes are obvious places to consider but I think even more important are strategic planning and basic financial processes.

Here are some of my answers to these questions based on 10-year old knowledge and interpolation with what I hear from friends who are still at the company:

1. Project planning is resulting in poor products because the company has too many people involved in the design process. Microsoft Vista had dozens of program managers working on it. Microsoft Excel 1.0 had 1 program manager on it. Is the difference between Windows XP and Vista 50 times more complex to manage than Excel 1.0? If so, that’s probably a sign that you’re doing something wrong.

Update 6/19/2008 – I’m told by Microsoft folk that my numbers are way off here, that it was more like 10,000 developers and 1,000 program managers. I just can’t fathom these numbers so I’m going to pretend that there were 1,000 devs and no more than 100 PMs that mattered.

2. Complex products require huge development teams. There’s simply no efficient way to integrate the work of 1,000 developers. If you can’t do daily builds and if developers have to wait weeks for their checkins to appear in public builds, you’re doing something wrong.

3. Thousands of developers and testers coupled with dozens of program managers require large product units and even larger business units. If your business units are large, few people in the unit will truly feel “P&L responsibility”. If a unit fails to meet its goals, the BUM may feel the pain but the 2,000 people who work for him/her are not going to get fired and probably won’t even see smaller bonus checks. On the other hand, if you have too many business units, you’ll inevitably end up with overlap and turf wars between them.

4. When a company is as large as Microsoft, central planning is impossible. You can set broad goals but there’s no way that the Chairman and CEO can know enough about all their businesses to be able to contribute much to their strategies.

There’s a common thread that runs through all of my observations: Microsoft is simply too big. Its size results in poor planning, bad financial management and excessively complex products/projects that are impossible to manage.

Just like the Roman Empire, I think it’s time for Microsoft to split itself up – even more so than Rome/Constantinople. Windows, Windows Mobile, XBox, MSN, Windows Live, Applications, Hardware: each of these should become a completely separate entity. Each of them should have its own CEO and its own stock. More importantly, each of these should be its own financial entity. They can start out with a good “stake” from the parent company, but each would have to demonstrate its own profitability or go out of business. Can you imagine the MSN Company trying to fund a leveraged buyout of Yahoo for $40B+ if it only had $4B in the bank? A smaller company would never contemplate such a boneheaded move.

Ideally, each Baby Bill would start out with 1,500-2,000 people.  I suspect that over time, several of them would shrink in order to maintain their profitability. The “parent” company could, perhaps, keep the Windows business and Microsoft Research and could provide services to the others in order to avoid needless duplicating infrastructure.

The companies would still have the problems I’ve been describing. The Microsoft brand would still be less cool than Apple’s; Microsoft would still need to improve its management culture; Microsoft would still need to learn how to succeed in areas other than technical prowess. The Baby Bills, however, would allow managers more freedom to experiment and would provide more incentives for success and more penalties for failure. Removing the $20B+ safety net would make Microsoft a more dangerous place to work and, I think, Microsoft would benefit greatly from it.