Something that Tony wrote about the other day got my mental wheels spinning. He wrote a pointed explanation of the seemingly inexplicable fact that IE9 and the Exchange Management Console don’t work together. This is no fault of the Exchange team; the EMC is built on top of the Microsoft Management Console (MMC) core, and it’s the MMC that has a problem with IE9.
Tony pointed out that the problem in this case is due to poor coordination between two different teams. That’s true, but it’s actually a symptom of a deeper problem that Microsoft has: it’s made up of a bunch of loosely coupled business units. Each unit has its own business challenges, its own resource constraints, and its own strategy for winning in the marketplace. That seems reasonable on its face; after all, the challenges, constraints, and strategies for the Xbox team aren’t at all like the ones for the Exchange team, and both are different from the Dynamics CRM team.
The real problem arises when these items collide, or even when they fail to align. The IE9-MMC problem is one example. It certainly looks like the IE9 team released with an incompatibility that should have been fixed before release. Did their schedule constraints drive that release? Maybe. That leads to the bigger question of what Microsoft’s strategy is with IE– how does it drive revenue for Microsoft, or prevent them from losing revenue? Given that their biggest browser competitors, Chrome and Firefox, are both free, it’s not clear to me what strategic importance IE has.
Then consider the alignment of the Windows Phone 7 team and the Bing business unit. Bing is very tightly integrated into WP7; this would seem to put the lie to my claim that many of Microsoft’s problems are due to loose coupling. Au contraire; this case proves it. The WP7 release schedule (and market constraints) are almost completely decoupled from Bing. The desire to get tight integration between Bing services and the OS led the WP7 team to take a dependency on Bing that has resulted in new Bing features being released first for iOS. That’s not 100% accurate, as there are some technical constraints around the first release of the WP7 SDK that played a role too, but it’s a close enough approximation. Or consider PhotoSynth, not yet available for WP7 because the SDK doesn’t yet support the features it needs.
Exchange and Outlook have been down this road before. If you think back to the ill-fated Local Information Store (code-named “Rosebud”) in Office XP, you’ll see the same pattern at work: the release schedules and business objectives of the Office and Exchange team weren’t in alignment, and that led to schedule slips and feature cuts on both sides. Each time Exchange or Office release a new version, both sides have to coordinate to ensure that their “better together” strategy continues to bear fruit. “Better together” is one of the few clearly articulated and executed strategies that Microsoft has had over the last few years; in fact, it’s expanded to draw Lync in as well. Of course, the Lync team has had its own challenges, as witness the continuing lack of mobile Lync clients for iOS, Android, and WP7, or the lack for that matter of a desktop Linux client.
It’s a tough problem to solve.
Paul's Down-Home Page 