It is one thing to change a product in order to meet market needs, but entirely another to change the culture. Scaling the teams and processes to meet the needs of our high-paying enterprise customers was another effort, and one that came right when most external indicators made it seem like we were doing everything right, thus making change more difficult. In practice, we had significant challenges meeting the needs of enterprise customers—product, support, quality, and overall enterprise-ness. We needed to bring not just our software to enterprise readiness, but our organizations. The best way to do that is to live through a few crisis moments, whether self-inflicted or not. Microsoft never met a crisis it didn’t enjoy to some degree.

Back to 058. That Dreaded Word: Unification

Note: This post is trying out the new free preview feature.

Share

Increasingly, our newly minted enterprise customers grew frustrated with Microsoft’s readiness as an enterprise partner. When an enterprise customer is frustrated, they describe the company as a vendor rather than a partner. A vendor is what we used to be, or so we thought. We had to up our game.

Customers were sitting on a mismatched pile of software from Microsoft, some of which was by all accounts being ignored by us in the product groups. There were ATMs running OS/2, which we long ago turned over to IBM. Banks in Europe were running Word and Excel on OS/2, which we made as essentially a one-off. One of the leading business magazines had a publishing system that used Word 2.0 and Windows 3.0, from the early 1990s. That was 8 years ago, an infinity in software years.

Business is business and Microsoft needed to change. While it took us more than a year of meetings, in 2002 we finally announced a Support Lifecycle Policy. To much press and customer outreach we announced that Microsoft products would now have a minimum of five years. In the Microsoft blog post describing the new policy, the CVP Product Support Services, Lori Moore (LoriM), explained that we “worked closely with customers, business and industry partners, leading analysts, and research firms”. Noticeably absent from that were the product groups that would be on the hook to deliver bug fixes and updates to customers covered by Software Assurance.

It should be no surprise then that Microsoft’s fully distributed and empowered product groups interpreted this policy with differing levels of enthusiasm. Did it apply retroactively? What about products designed for consumers? What if we have multiple releases over five years? What if product releases took more than five years? What if Exchange has one interpretation and Outlook another? The intended effect of this effort was to do good by enterprise customers.

Instead, it was just an early step in making the transition to a new operating model. Customers interpreted the Lifecycle as a license to deploy what they could or would and then freeze the infrastructure for at least five years. Imagine in our fast-changing technology world, just freezing a company’s information infrastructure. Five years was the minimum. Customers could even buy longer support contracts and they did so in droves. It meant that even five years from now, product groups were on the hook to support products that no one was actively working on.

That said, on the Office team we created a team that grew significantly over-time of full-time engineers dedicated to what we termed Sustaining Engineering. The team, Microsoft Office Sustaining Engineering (MOSE), originally envisioned by Excel test manager Carl Tastevin (CarlT) and then led for many years by former Word test manager Jeanne Sheldon (JeanneS), prided itself on being a direct connection to customers. They would spend the time to understand the context and customer environment driving problems and were reliably the best source of information anywhere for how the product was doing in market with customers. The team was not an outsource model for quality and fixes because the product team developers that created the problems were accountable for fixes. It was a fantastic model for us and one we would later replicate in Windows which had gone full outsourcing after Windows XP shipped, which turned out to be less than ideal.1

It would not take long, not even eighteen months, and the policy would again be updated. The feedback was less than positive on the first policy, mostly because it was uneven across the company and hardly long enough compared to traditional enterprise partners. This time the product groups were deeply involved in the process, in what grew to a major corporate undertaking. Since the first announcement, most teams released major new products, and all had built out engineering teams that were able to handle the new volume of support issues from enterprise customers. I attended many of the meetings of the product leaders who were trying to agree on a more uniform policy. The group was working well together but not converging. Microsoft’s multiple billion-dollar businesses each serving distinct customer types and each with substantially different release schedules were struggling to arrive at a more uniform policy that was also longer. Some product groups aimed for very long support terms and others wanted nothing to do with previously released products. Office was in the middle. The position depended entirely on the primary buyer such as IT professionals, OEMs, or general corporate buyers.

In a moment of frustration for how long this was dragging out, I, probably the more senior product group person in the room, suggested (with some force) we should all settle on a ten-year support offering. This would make customers happy and would put this issue to rest. Our competition, such as IBM, supported products for decades. How much support would customers really expect nine or ten years from now for a product long forgotten? What a huge mistake I made. In hindsight, I was intoxicated with the idea of making sure the field (and SteveB) knew we “got it” in the product groups and also over-confident with the idea that we could execute on such a commitment. I really can’t believe I thought this was a good idea—not only for Microsoft but for customers to rely on it. Think of all that changed ten years prior or all that would change from 2000 to 2010, especially considering how most customers were still far away from deploying email and the internet. Yet, SteveB and the field support and sales teams were incredibly happy and thankful for the teamwork and support from the product groups it took to make the updated policy a reality.

You could feel the bubbles and the froth everywhere as the end of the millennium approached in the Fall of 1999.