Welcome to the final installment of Hardcore Software. It has been an amazing journey in the 115 or so sections including bonus posts. I owe a huge debt of gratitude to those of you that have followed along the journey of the PC and my own growth and lessons. Thank you very very much.

I have a few more bonuses planned, including a compendium of Microspeak and a bibliography of books and magazines that I collected. For paid subscribers I will be sending out an update on how billing will end and for “True Blue” subscribers please expect an email on receiving your compiled version of the work. It’s not too late to order that and also have access to all the old posts. I will also be filling in audio for the first 70 posts in early 2023.

Hardcore Software describes a personal journey. It is also one that happened to coincide with the PC revolution—the early days all the way through the final days of the revolution. The PC still marches on, but it is different. The PC remains essential though is no longer central to the agenda of computing as it was. That is what I mean by the end of the revolution.

This post is free and comments are turned on for all Substack users.

Back to 107. Click In With Surface

Windows 8 was a failure.

Hubris. Arrogance. Lunacy. Egomaniacal. Pick any word to describe the product; it was likely used somewhere. No one knew, or felt, the weight of the product failure more than I did.

Nearly every successful Microsoft product had survived our it takes three versions to get it right modus operandi. Esther Dyson, a technology investor and journalist, writing for Forbes in an article “Microsoft’s spreadsheet, on its third try, excels” said “It’s something of an industry joke in the software business that it takes Microsoft three tries to get it right. There’s Windows 3.0, Word 3.0, and now Excel 3.0.” She wrote that in 1991, reviewing the third version of Excel.

No Windows leader made it through the odd-even curse of releases, certainly not three major releases of Windows from start to finish.

My hope had been for a credible Windows 8 knowing we weren’t finished, which was standard operating procedure for new Microsoft products. We knew where we wanted to take the product over time—the hardware, the software, and the apps. But none of that happened. For reasons I still do not fully understand, for the first time I could remember Microsoft quickly and completely withdrew and actively erased Windows 8 in an almost Orwellian way—even Clippy preserved its dignity. I try to imagine what would have happened had Microsoft given up on Windows the first time, or Windows Server, Exchange, Word, Excel, or PowerPoint. All of those took multiple iterations to find product-market fit, to win both hearts and minds.

Requiring three versions was not a Microsoft thing. It is a product development thing. Even in a big company you must ship the first version—shipping a “V 1.0” (v for version) is always a miracle. Then you need to fix it and that was version 2.0. Then by version 3.0 not only does the product work, the sales, marketing, positioning, pricing, and more work. Product development is always a journey. Always.

With years of hindsight including the new mobile market, the PC market, and Apple, many of the initial problems with Windows 8 were not nearly as egregious as much of the commentary made them out to be. Or maybe the commentary was right and what was egregious was not that we made a product that did what it did, but that we made Windows do those things? Or perhaps we simply did it all too soon? Or that we, surprisingly, lacked patience to get it right?

There was commentary on me as a leader, as a person. I knew that was borne of immediate frustration and not enduring. That’s why I remained quiet and did not speak out in 2012 as I moved on to a new experience in Silicon Valley and working with entrepreneurs. I understood and even respected the emotion from where it came and the forces that produced it. Over time individuals who facilitated that commentary have since apologized directly. I was proud to be part of more than two decades of building products, processes, teams, leaders, and people—a culture—that were the highest quality, best equipped, and most talented at Microsoft in the PC era.

The problems we needed to solve with Windows 8 and Surface were readily apparent, as I strongly believed the moment we shipped. Nothing anyone wrote about either was surprising or news to those of us who had lived with the products. The commentary on the severity of the problems, and how and what to fix, was debatable.

Microsoft had become synonymous with the PC, but could it also reinvent the PC? That was what we set out to do. The problem was that the people who loved PCs the most weren’t interested in a new kind of PC. They wanted the PC to get better, but in the same way it had for decades—primarily, more features for tech enthusiasts and more management and control features for enterprise IT managers. They simply wanted an improved Microsoft PC from Microsoft—launching programs, managing windows, futzing with files, compatibility with everything from the past, and more like that. They wanted more Windows 7.

Instead, they got a new era of PC, a modern PC, from other companies, and it would be called iPhone, iPad, Chromebook, or Apple Silicon Macintosh and they would be okay with that. Today in the US, Apple’s device share is off the charts relative to any past. Apple holds greater than majority share of phones. Macintosh is selling at an all-time-high 15-20% of US PCs depending on the quarter. As for the iPad, the device loathed by so many who believed thinking about tablets was the underlying strategic failure of Windows 8, Apple has perhaps 500 million active devices and sells about 160 million iPads per year, or more than half the number of PC sales. The business and personal computing market is no longer the PC market, but vastly larger, and the only position Microsoft maintains is in the part that is shrinking relative to the whole and on an absolute basis.

The iPad is worth a special mention because of the tablet narrative that accompanied Apple releasing their product just as we started Windows 8. The iPad had a clear positioning when released—it was between a phone and a PC and great for productivity. It was an odd positioning considering it was precisely a large, but less featured, iPhone. Soon Apple would say the iPad was the embodiment of the future Apple sought. Since then, however, the iPad has been mired in a state of both confusion and poor execution. While taking advantage of the innovation in silicon and the undeniably impressive innovation in Apple’s M-series of chips, the software, tools, frameworks, and peripherals directed at the iPad have, for lack of a better word, failed. For all the unit volumes and significant use as a primary device, it has not yet taken on the role Apple articulated. I would not have predicted where they are today.

Jean-Louis Gassée, hired by Steve Jobs and former leader of Apple hardware and later creator of BeOS, had this to say in his wonderfully reflective weekly newsletter, Monday Note:

The iPad’s recent creeping “Mac envy”, the abandonment of intuitive intelligibility for dubious “productivity” features reminds one of the proverbial Food Fight Product Strategy: Throw everything at the wall and see what sticks.

In competition it takes the leader to drop the ball and someone to be there to pick it up. Whether Apple truly dropped the ball with respect to the iPad or not, it is certainly clear that Microsoft in a post-Windows 8 environment was in no position to pick it up. That is a shame as I think Apple created an opportunity that might have been exploited.

Instead in the Windows bubble, as much as anyone might have wanted new features or improved basic capabilities, they wanted compatibility with all that had come before. Legacy applications, muscle memory, and preservation of investments were the hallmarks of Windows, not to mention the ecosystem of PC makers and Intel. Why question those attributes with a new release in 2012?

There was a comfort in what a PC was already doing and refining that while leaving paradigm shifts to other devices was, well, comfortable. Many saw the PC as both irreplaceable and without a substitute. Like the IT pros who knew the Windows registry, they were comfortable with their mastery of the product even if the world was moving on.

Unfortunately, what is comfortable for customers is not always so comfortable for the business. Without a dominant and thriving platform, Microsoft is like a hardware company or an enterprise-only software supplier—reliant on deep customer relationships, legacy product lock-in, pricing power, and big company scale to drive the business. Those can work for a time, and perhaps even bide time hoping to invent the next platform. IBM continues to prove this every quarter, much to the surprise of technologists who today don’t even know what IBM makes or does.

Windows 8 was not one thing, and therein lies its main challenge. Windows 8 was not simply a release of Windows, some new APIs, and a new PC. Windows 8 was a paradigm—it could not be disassembled into components and still stand. If we had just built a Microsoft PC for Windows 7 that would not have changed the trajectory of the business, just as we have since seen with hardware efforts. We already saw how touch on existing desktop software didn’t deliver. Moving from Intel to ARM without new software or worse just porting existing software was running in place at best and taking focus away from worthwhile endeavors at worst.

To shift the paradigm and to enable Microsoft to have assets and compete in some new way required an all-or-nothing bet. Everything we know about disruption reveals how companies do what they can to avoid those situations and try to thread the needle. I was totally guilty of aiming to avoid that.

The temptation to cling, or leverage depending on perspective, to the Windows legacy was constant. As I learned over every previous, and smaller transition, giving customers a little bit of the past—a compatibility mode or a way to opt out of changes—meant customers would take advantage it. The new product wouldn’t be new to most customers. With Microsoft’s decade-long commitment to supporting that new-old state, we would have been shackled to the very platform that was already in an anemic state—Windows and the APIs for apps, Intel and the ever-increasing transistor march, and an ecosystem of OEMs and ISVs focused elsewhere.

There were five hot buttons I felt weakened our all-or-nothing bet. There was no quick fix for these, even in hindsight. Worse, each proved more early than incorrect. In technology, however as I have noted several times in this work, early is the same as being wrong. People will debate these even as I write them years later. I think we will always have fun doing so. I certainly will. It is the nature of engineering to forever debate the causes and decisions that led to failure.

First, the Start screen clearly served as the emotional lightning rod for the release. It was, to some, as if we ripped the heart and soul from Windows. I didn’t see it that way, obviously. I saw a mechanism that had outlived its usefulness just as we saw menus and toolbars outlive their usefulness in Office, or even character mode decades earlier. Despite being there in the summer of 1995, I did not see the quasi-religious significance of the menu. I saw something that people had mostly stopped using—the taskbar, ALT-TAB, search, email attachments, and browser tabs replaced launching and switching programs. Tech enthusiasts, however, had many more programs, dozens of utilities, and elaborate custom configurations. I know because they sent us the screenshots in protest. I would posit today that most tech enthusiasts are using the taskbar and search to find and launch programs, exactly as we designed Windows 8 to work. I also think they would have been fine turning off their computers with the power button and would have survived not having shutdown on the screen all the time, though they would miss the chuckle from the timeless hilarity of Start -> Shutdown.

Phone app screens grew to become the way computer programs are launched and managed. They take up the full screen and they are super easy to navigate, unlike the Start menu, which even with a mouse grew increasingly finnicky and awkward. Apple’s home screen evolved to be more like Windows 8, including search and an All Applications view. Windows ultimately evolved to become more like a phone screen and far less like the formerly beloved menu, but nothing would have appeased people at the time. Nothing, other than providing (an option, of course, everything is an option) the Start menu back for “non-touch” or “Intel” PCs or something arbitrary like that—a compatibility mode. We had compatibility mode—it was Windows 7.

Second, the presence of the desktop in Windows RT, the version of Windows that didn’t run any existing desktop apps. Additionally, the desktop not being the first thing to pop up after starting any version of Windows proved to be “disorienting” in ways that were more reactionary than actual. From the first demo at All Things Digital when we were asked about “two modes,” I was not able to find the way to describe this feature. If a product requires explaining, it’s already lost.

On Intel Windows, we wanted to remove a level of indirection and simply have a place to start. The desktop, with its cacophony of uses, had become a hairball. It did not roam between devices well (due to screen size and contents), and the slew of uses as a file cabinet, scratch pad, dashboard, and program launcher made improvement impossible. Alas, it was viewed as sacrosanct and another place where the world was changing but disproportionately less so for power users. The move to phones, browser apps, cloud storage, and multiple devices relegated the desktop for most. We were just too early.

Third, on ARM we faced another challenge: Our own desire to ship meant we shipped a product that was knowingly incomplete. We simply had too many places to return to the legacy experience. Apple chose to hide those capabilities on the iPad until they were ready and perhaps that would have been a better approach for us too. We should recall that the iPhone shipped without copy and paste, and the iPad was literally a big iPhone with fewer built-in apps and no phone capability. We wanted to embrace the capability of the operating system without compromising quality, security, and so on. For example, the iPad had no files or file management capabilities, including using devices such as USB thumb drives, until 2017. We supported those out of the gate, but that sometimes required using the legacy desktop and explorer. We didn’t have time to build the WinRT file manager app we had already designed, as an example, or update everything in the Windows control panel. The vast ecosystem took time to move, but we had to begin a transition.

Many believed omissions presented a weird modality or duality. Our explanation that this was always how Windows evolved failed to satisfy or reduce perceived confusion. Windows carried the DOS box and command line (and still does) and even .INI files, for those who cared, for decades—and it was widely used by tech enthusiasts and administrators alike—even for copying files! Having some of the old along with the new had always been the Microsoft way. It just seemed so inelegant compared to Apple.

I, we, did not love that we had to do this. While we considered many alternatives, we didn’t have a better approach without taking forever to ship. The enemy of the good is the perfect. The industry was moving away from Windows, and we had to get in the game. That is decidedly different than Apple releasing a phone to a market that was far from settled and expected little from Apple which had nothing to lose. We had everything to lose and were losing everything.

Fourth, there was one very significant reason we required the desktop and why it was not simply a bonus like the old command or DOS box.

Office.

The shift to touch, phones and tablets, and a modern operating system with new apps was much larger than any one of those individually. To decompose the strategy into components is to wield the technology buzzsaw or fall victim to taking on disruptive technology shifts like entrenched incumbents tend to when failing. To have a viable product, we needed to execute on all, simultaneously.

These shifts happened all at once not because the PC did not take on each feature individually, but because the PC model itself could not possibly address the shortcomings that built up over years. Loosely aggregated features, engineered across adversarial partners, combined into a product was well-suited to the invention of the personal computer, but not the optimization of the experience. The idea that the PC could move forward into a new era by simply adding touch, or some new user interface features on top of what was there or adding an app store while still supporting downloading code from the internet, or even adopting ARM, each as a point solution was simply the old way of solving problems, the PC way.

Surface RT was designed to be the epitome of productivity for mobile information work. We wanted Surface to be people’s primary work computer, the way they used a laptop (PC or Mac), but with all the reliability, security, battery life, and mobility of an iPad. To accomplish that we needed Office: Word, Excel, PowerPoint, and (some would say) Outlook. The problem: I was not successful at evangelizing the new platform opportunity to the Office team. Let that sink in.

The hallmark of Microsoft’s strategy had always been apps and platform, platform and apps, and if necessary, by force. Early on the apps were forced to work on Windows against their judgment, and then later Windows was forced to be good for the apps even when it thought Office was not the focus, and this see-saw continued for the benefit of the industry. It was like we had reached a point where both businesses were so entrenched that their own worldviews precluded a bigger, all Microsoft bet. Perhaps we reached a level of fatigue in cross-company bets after the Longhorn and .NET eras.

When we presented the Windows 8 vision years before, I sat next to SteveB and friends from the Office team that were invited. It was during that meeting that we began to make the case that the new runtime existed to build new apps—new ways of working, focused on collaboration, sharing, tasks, cloud storage, and less on massive amounts of formatting, scattered document files, and so on. The collective questions were more about how to maintain compatibility for Visual Basic for Applications, third-party add-ins, and the Ribbon. We never bridged that gap. The whole product cycle, Office wanted to port existing Office to ARM and run it. The biggest irony was that the entire time the Mac Office team was busy building Office for the iPad, which is why it was ready to release on the heels of Windows 8. There are two sides to this story. The Windows 8 leaders knew both sides because we were previously the leaders of Office. There was a view that even that cross-pollination contributed to the challenges. Ultimately, there was a need for both the old Office and a new set of tools. Silicon Valley was hard at work creating new tools for information workers—modern, mobile, cloud, web, SaaS tools for productivity—while Microsoft continued to pay the bills with existing apps, even if they sold under the 365 cloud moniker for much higher prices.

Office was part of a symptom, a fatal symptom, of having no WinRT apps, which was obvious. Everyone in the industry knows that if Microsoft is serious about something then Office will participate. If Microsoft was not serious, then there was no Office support. Desktop Office sent the clear message that Microsoft was not serious about WinRT. It didn’t matter what we said as our actions spoke louder than words. We had OneNote and some experiments. But without Excel, there was no WinRT. We had many debates in executive staff meetings about juicing the ISV ecosystem. That whole ecosystem was focused on the browser while still suffering from the strategy fatigue from Windows Phone 7 (and soon 8) and the failed Longhorn strategies. We needed Office. We got OneNote. I still love OneNote to this day.

We chose not to build a phone first or simultaneously. Perhaps the entire platform strategy would have been different if we had indeed executed on the mythical plan of having a phone and first-party hardware out of the gate. Since that would not have finished perhaps until 2015, debating it at all might be irrelevant. By 2015 the world would be solidified around iOS and Android leaving little headroom for us, plus we would have had a couple of more years of failure of Windows Phone, services, and an aging Windows 7. Fans of Windows Phone will continue to debate and champion that legacy the way people fondly remember the Amiga or Newton, so this is one debate I intentionally avoid.

And fifth, Windows RT and even Windows 8 were the product names. Many argued that any product without a traditional Start menu and full compatibility could not be named Windows. More would argue that naming Windows RT as we did, “confused customers” as to what would run where. That was true, but Windows had long had variants that came with limitations or exceptions: Windows NT, Windows CE, Windows Embedded, Windows Media Center, even Windows 2000, and most recently Windows Phone. All of these were confusing in some relative sense, but all were given time to rationalize the confusion.

Should we have abandoned the legacy that was embodied in the Windows name? I certainly thought about that a lot. Here again, everything about disruption would have said absolutely name it something different. Heck, put the team in another building, get them new card keys, and so on like the Zune team did. That same theory also showed how no one ever does that because they look at the cost and effort, along with splitting all the energies of the company, and reject any such approach as heresy. As someone who grew up knowing that Windows NT or even Windows XP didn’t really run everything Windows 95 ran, I felt like we could pull it off. I was wrong. I don’t think a new name would have worked any better and would wager that any new name would have been cutesy and clumsy at the same time given Microsoft’s history. Then again, many chuckled at iPad too.

There were a host of smaller reasons as well, some related to timing and others to just trying to get a product to market. The original Surface did not support LTE, which undermined our mobility and mobile chipset message. We chose a unique aspect ratio for the screen, which proved to just be wrong for productivity. SteveB pushed on this as he personally began to like eReaders on Android that had paperback book aspect ratios. We all agreed, but it was too late. The original Surface RT keyboard, the Touch Cover, was innovative but not productive. There were other software aspects as well, like my refusal include Outlook, which would reduce battery life by 1-2 hours simply because it wasn’t a modern app and had incomplete connections to our services backend. The lack of support for traditional group policy irked IT Pros who felt they needed to secure any device using invasive methods used on PCs. Those methods were battery draining while opening up a host of Win32 compatibility requirements. Modern mobile device management tools are far better than what IT did at the time, and we built those capabilities into the first release.

I tend to look at the failures of the product strategy because that is where most of the focus sits. But I had failures in the go-to market as well. I am rather fond of pointing out that success and failure are elements of the 4 Ps of product, price, place, and promotion. In the case of Surface RT, we got the price right assuming we sold a lot of them, and surprised some people even in the face of super cheap Android tablets. We got the place, the distribution strategy, entirely wrong. The Microsoft Store retail team was insanely excited to have exclusive access to Surface, but there weren’t enough stores to sell the number we needed or wanted to sell. I was unable to make the math clear to leadership. We literally could not sell all we made even if the stores operated at multiples of capacity, 7 x 24. I begged and pleaded to expand distribution, and so did our partners, right up until the end. In the process we angered our Windows retail partners around the world. Then we had a whole bunch left over, and in 2013 Microsoft took an inventory write-off to complete the erasure of Windows 8 from memory. I remain convinced, perhaps naïvely so, we could have moved many more units had we opened the retail strategy. That would have allowed for the potential to iterate to a second and ultimately third version.

No matter what happens, someone always said it would, and when a product fails those predicting that are quick to make themselves known. I admit I found it enormously frustrating to see the revisionist views appear, whether with the press or with people at Microsoft. President John F. Kennedy famously said, “Victory has a thousand fathers, but defeat is an orphan.” I certainly felt alone in defeat. It is well-known that as a leader, a huge part of the job is to stand alone and absorb the defeat. I think I did that at least as well as making sure any successes achieved over decades were those of the team or specific individuals and definitely not mine alone.

While our issues are quite clear in hindsight, they were also visible at the time which only serves to further the told-you-so reactions. Every technology shift had doubters focusing on some specific issue, or challenge, rather than seeing a complete package like all those people who said the Macintosh was not a real computer because of the mouse, or how the iPhone touch screen would not work. Had the iPhone failed, it is easy to imagine the self-congratulations from those who noted in their reviews the lack of copy/paste, missing Adobe Flash support, incomplete push email, or the new on-screen keyboard.

I knew the feedback on each of the specifics, but also, and naïvely, hoped the whole system could be seen for what it was trying to do…and it would do if given a time and effort. The story of the ribbon in Office, one of the biggest and most successful UI reinventions undertaken in a product, was one filled with doubters inside Microsoft and outside as we discussed. Today some of those who were the most negative about the change even find themselves leaders in today’s Office.

But why should people have been patient? They had the iPhone, iPad, Android phones and tablets, and Chromebooks all to choose from. They were happy to use those and just stick to Windows for all the familiar legacy work.

As we progressed to the October 2012 launch of Windows 8, a lot was happening that perhaps marred our ability to see clearly and, more importantly, collectively. It was an anxious time. We spent the summer in leadership team meetings gearing up for the yearly sales meeting ahead of a big launch year. The past ten years of flat stock price and lackluster product success had taken its toll.

The difficulties with Windows Phone were compounding, despite poorly grounded optimism. Phone apps were not gaining traction and worse the hacks to gain apparent traction were backfiring, such as paying developers to write apps or adding apps to the store that were simply web sites. Fingers were pointing. With Surface, the question became: Should we build our own phone? Should we kick off a skunkworks project like Zune (that team was available) to build a phone? Would that truly address what we were seeing in the market? The phone was the next platform, a platform for the entire planet, and we were not even registering as a viable third place. The opportunity to align Windows and Windows Phone long passed and there was still no appetite to weigh down the phone strategy with a full Windows-centric approach. It was always as if the phone was on firm footing, and it just needed to borrow a bit more code from Windows. It was never on a path to success.

The Windows Server team seemed to resist embracing the new Azure product, which remained organizationally distinct. In hindsight this proved reasonable as Azure came to be dominated not by Windows as hoped but by Linux. We were obligated to support them, so that was creating a lot of extra work for us, delivering for both the on-premises server and the new data center product. The enterprise server and server apps data center era, as we knew it, was over. It was archaic and unmanageable. Microsoft was barely able to keep its own Windows data center running. The future of the server business was the cloud, but our enterprise customers were strongly resisting, or more likely entirely unaware, of that fact. AWS was still almost entirely a Silicon Valley novelty. This made it easier to ignore.

Our commitment to online services, what I saw as a key component of the Windows platform as we knew it, from communications to identity to storage, were all seen as cost centers despite the obvious need to own and build widely used cloud services across devices. A complete device experience required services extended to the cloud, built natively for the cloud rather than ports of existing Windows and Office servers. The device experience as we knew it to be was coming to an end without services.

Microsoft’s transformation to an internet company—well documented as one of the most successful pivots of all time—turned out to be great for our revenue but lousy for our platform technology. The level of internet savvy across the company paled in comparison to Google and Facebook (yet the much-sought-after Yahoo rapidly faded). Little, if any, Microsoft technology or platform were part of the rise of these huge new powers. The only organic internet scale business was Bing, which continued to struggle, though ironically has today found a niche disguised as the anti-Google DuckDuckGo.

Across Office, Windows, and Servers, the reality was our pricing power, distribution moat, and enterprise account relationships combined to provide comfort in the face of shifting platforms. The reality of business disruption was right in front of us. It was plain to see. Yet the business was apparently thriving, just as the classic book on disruption would predict.

Despite the massive revenue success and great numbers, the technology story looked bleak to me. I felt alone in that concern. I sent a memo to the leadership. It was a plea to develop a point of view that these technology shifts implied that went beyond defensive—Without a Point of View, There Is No Point. I tried to argue that we had been lulled into a sense of complacency by having succeeded through the dot-com bubble yet ended up weak in every technology shift that followed. We were losing everywhere, except revenue. We did not have a platform, which as a platform company was a big deal. My memo, which turned out to be the last one I wrote, was decidedly a polemic meant to stir people up.

I also wondered whether it even made sense to keep score, so to speak, with products and technologies. Maybe all that mattered was leading by business metrics like revenue, profit, and cash flow. There are worse things than being a huge money-making corporation.

Leading Microsoft to reimagine Windows had been accomplishment enough for me. I knew what I had signed up for more than five years earlier. It was much more than even I had planned on. But it was time. Ultimately, I could not break the odd-even curse.

After the October launch in New York, it was time to mark the end of my career with Microsoft. With great clarity, I knew it was time to use that resignation letter I’d been holding on to. One last meeting with SteveB, and some quick rounds across my direct reports, and then I hit send. Our split was undeniably mutual. I felt a sense of relief. Compared to leaving the Office team for Windows, I was much more certain this was the right decision. I was eager for a context switch.

Once the decision was made, moving on immediately was best. I never wanted a big send-off. Quite the contrary. I had gone through two years or eight depending on how one counts of Bill “transitioning” (not that there is a comparison). Then there was the year transitioning through Windows Vista I experienced. I’d seen too many people stick around for too long, confusing the team and dragging their departure out.

What I failed to understand, and deeply regret, was that in our collective haste to move on I left behind the most superb team, ready to take over and move things to the next level, but not prepared for what would actually follow. I was selfish and the people who gave the most to create the new Windows team paid for that.

The “post-Sinofsky” unwinding of Windows 8, not just the product, but the organization and processes as well, became even more painful than market reception of Windows 8. I let the team and my best friends down. I left them to pick up the pieces I should have been picking up myself. The management above them failed to show them the respect they deserved. Nearly every one of them represented in these half-million words—the best leaders Microsoft created across every discipline—has left the company. So many of them are creators, entrepreneurs, and thought leaders in ways that Microsoft does not even participate today.

BillG had always been fond of saying that tech companies have a remarkably difficult time leading as technology crossed generations. Leaders of each era might maintain scale, rarely evaporating, but losing influence and presence in the market. Technology analyst and friend Benedict Evans wrote:

Every day of Windows 8 development, I worried about losing our audience of developers who hung on every word of not just what new features for Windows and Office were being shipped, but what code they could write, what business they could build, what customer problem they could solve by making a singular bet on Microsoft’s inventions to power them. I’d seen the relevancy of Office fade even while the business grew. Many companies have core fan bases, but Microsoft was blessed with people and companies building businesses on our technology, uniquely and singularly, and many of them moved on. Developers are not the end, but a means to a force-multiplying economic relationship with billions of people. I’d seen how easy it is in a large organization to find a bubble to hide out in—a bubble where our products are as popular and relevant as they once were.

Paul Graham, fellow 1980s Cornellian, founder of the Y Combinator startup accelerator, and described as a “hacker philosopher” by author Steven Levy, wrote two essays on Microsoft that were rather prescient, if not spooky. They were written so early as to be easily dismissed or perhaps wishful thinking. In 2001, he wrote “The Other Road Ahead” a nod to the book by Bill Gates. In this essay he described the new Web 2.0 paradigm relative to the desktop computer. He aptly described the bubble Microsoft was in, that I was in, and we just didn’t know it:

Back when desktop computers arrived, IBM was the giant that everyone was afraid of. It's hard to imagine now, but I remember the feeling very well. Now the frightening giant is Microsoft, and I don't think they are as blind to the threat facing them as IBM was. After all, Microsoft deliberately built their business in IBM's blind spot.

I mentioned earlier that my mother doesn't really need a desktop computer. Most users probably don't. That's a problem for Microsoft, and they know it. If applications run on remote servers, no one needs Windows. What will Microsoft do? Will they be able to use their control of the desktop to prevent, or constrain, this new generation of software?

The essay is long and well worth reading for its predictive powers. While not every technical point landed precisely as described, especially the iPhone and apps, it is a brutal read that was aptly ignored by us at the time. As if to double-down, in 2007 he wrote another essay “Microsoft is Dead” wherein he described what took place in the mid-2000s that killed Microsoft. This was just after Windows Vista when it was easy and rather popular to assert an end. That was because of Vista, however, not because of the four factors in his essay: Google, the desktop is “over”, broadband internet, and Apple OS X on new Macs. He concluded with a candid and brutal take:

Microsoft's biggest weakness is that they still don't realize how much they suck. They still think they can write software in house. Maybe they can, by the standards of the desktop world. But that world ended a few years ago.

I already know what the reaction to this essay will be. Half the readers will say that Microsoft is still an enormously profitable company, and that I should be more careful about drawing conclusions based on what a few people think in our insular little "Web 2.0" bubble. The other half, the younger half, will complain that this is old news.

Despite Graham’s dire predictions, people continue to rely on Microsoft and bet on the company today. Microsoft is an enormous business. It is undeniably a different kind of leader, more a comfortable companion than a guide taking you to new places.

It is popular to say that the operating system is no longer key, that the definition of a platform has changed, and that the battle is now above the OS. That’s a great rationalization, and as Jeff Goldblum’s character in The Big Chill said, “Don’t knock rationalization. Where would we be without it? I don’t know anyone who can go a day without two or three rationalizations.” The biggest business at Microsoft remains Microsoft/Office 365, and as valuable as email and video conferencing are (and as important as transferring the capital and operational costs to Microsoft in exchange for a huge price increase was too), the unique intellectual property in Office 365 that defies competition is Word, Excel, and PowerPoint. These remain key tools used in daily mission critical work by perhaps 300 million information workers. Those people, at least 90 to 95 percent of them, rely on Windows to do that work, which is Microsoft’s second largest business.

Bundling the new Microsoft Teams with the 365 service perfectly reflects this legacy approach, a well-worn strategy to support the existing business and pricing rather than risk building a new business and creating a new revenue stream. In this work I described the bundling of Outlook, OneNote, SharePoint in this same regard during the expansive period of enterprise software. Microsoft loved a good bundle. Customers did to. I suspect this time with Teams will end differently primarily because the computing world is in a different place and the requirement that customers settle for a bundled product is nowhere the same as it was in the early or middle stages of the PC era. Certainly, the macroeconomics of 2022 will provide a foundation for a bundle, but that has not proven sustainable.

The virtuous cycle of apps and systems envisioned by BillG in the 1980s stands as the hallmark of Microsoft, but it is not growing in users and is not part of a thriving ecosystem. New customers aren’t coming to PCs with Office even at a rate to replace those that retire. Windows PCs are not benefitting from advances in a hardware ecosystem that transitioned to mobile. Developers aren’t building new software for Windows. The cycles have been broken.

PC sales in 2022 will likely have declined 15-20% over 2021. Many will point to the economy or foreign exchange rates or length of a replacement cycle, or maybe even Apple’s inability to figure out its own product strategy. At some point the only conclusion is that the PC, like the mainframe, minicomputer, and workstation before it, was a mature and saturated market. There will be good years and not so good years, but the PC or PC server running Windows will never be the platform it was. Even if people develop new products on it, those products will not take advantage of what a new PC has to offer, which is the definition of a platform.

The web and smartphones have assumed the role of the information platform for the world. This time is different, however. Together these two have touched every human on the planet. That hasn’t happened with any other foundational platform, to use the term broadly, in history except for perhaps fire. All the amazing, connected platforms from the 20th century reached their limits long before reaching every person everywhere, including rail, car, roads, airplanes, telegraph, telephone, television, electric grids, sewage, and more. Whatever comes along next will also be the greatest technology displacement in the history of humans as it will replace the internet-connected smartphone for every person on earth. That is going to be an incredible innovation.

Craig McCaw, one of the earliest pioneers of mobile phones in the US via his namesake company and graduate of Seattle’s Lakeside School a few years before Bill Gates, described humans as inherently nomadic when it comes to the technology they use. He first made this observation with respect to mobile phones compared to land lines that tethered users to a wall. Technology is broadly adopted first when it meets their needs, and not before. Then over time when a product fails to meet their needs and something better comes along, they simply move on. Smartphones came along and when they became good enough, people simply stopped demanding new PCs.

BillG once said to me of another legendary company facing challenges that things always seemed brightest before a precipitous decline. That’s what Windows PCs were facing. Windows 7 was peak PC the way Office 2007 was peak Office. Peak, not in terms of financial success, but peak in terms of influence, centrality, excitement, and general interest. Microsoft was in the midst of disruption, to use that overused phrase on more time. Not everyone agreed about where we were in the arc, and that was the problem.

Either way, it was the end of the PC era.

We knew that because we could read, watch, or hear about it all by swiping with a finger or by asking about it on that modern computer in our pockets or one of the hundreds of millions of tablets on sofas, in the back seats of cars, or in airplane seats. That computer was the reinvention of the PC. In no shortage of irony, the company that brought us this new computer was Apple—the company that for all practical purposes invented the PC in the first place.

Windows PCs are never going to reach 500 or more million or more units a year as analysts had once predicted. The question was not how high sales would go but how low could they fall—peak PCs ended up being the Windows 7 upgrade cycle that resulted from a combination of poor demand due to Windows Vista, delays due to the recession, and lengthening PC lifetimes. A market of 300 million PCs is a fantastic business (about the same as 2007), but it isn’t two billion iOS devices in use or the more than three billion active Android devices. It certainly isn’t the growth opportunity of bringing PCs to every home and desk across emerging markets in Asia and Africa like we had hoped a year or two earlier.

Did Windows 8 cause PC sales to decline because it was the wrong product for the PC? Or did the substitution of phones for PCs in the eyes of customers cause the decline in PC sales which made Windows 8 the wrong product? Years later all I can say with certainty is that those both happened at the same time, each correlated with the other. Importantly, would a more incremental and traditional release of Windows have really saved PC sales or even have spurred significant growth? Does anyone really think this today? I didn’t then and certainly do not today.

Looking back, there are small things that I might have changed, though I can say with confidence that would not have altered the outcome. To date, no one has offered up a plan that would have had a better shot at helping Microsoft achieve the same level of impact and influence in this next era of computing. It makes for a fun column or Gedankenexperiment to explore the counterfactual, but I didn’t really have a way to do that in real time. There’s no A/B test in building Windows.

Microsoft was going to be big for decades the same way IBM had remained significant, but it deserved its chance to earn a spot as influential and central a platform to computing as it had been originally. The most obvious answer is also the most difficult for me to accept, which is maybe there just wasn’t a plan. Maybe, unfortunately, where the world settled was inevitable. People moved on.

It is easy to poke holes in this sort of logic. We were not caught off guard or in denial. This was not New Coke. We did not see that the youth market liked a slightly different PC, so we tried to tweak the PC to make it more stylish and appealing. Our strategy was similar to what Apple had done, though our approach brought our unique perspective. There was a clear case of parallel evolution, but Apple came to market first (again!) and there were many reasons to believe being second would have advantages, as had been the case for the PC, Windows, Word, Excel, Windows NT, Exchange, and so many other Microsoft success stories. That was not the case.

When I look at the Tablet PC, Media Center, Windows Phone, or a host of other products, one thing is clear. Those products did not have the right substrate relative to how the market would evolve. There was nothing in those implementations that represented a first step in a progression to the products that did eventually dominate. It is fair to say the concepts were right, but the technical foundation was wrong because elements were simply not ready. Windows 8, in my biased view, had the right ingredients that were also market-ready.

There is one exception to Windows 8 having the right ingredients, and I don’t know if the market gives Apple enough credit for what they have done. The Apple Silicon work is, at least for now, unparalleled. There was no likely outcome over the past decade that I think would have left Microsoft and likely NVIDIA in the position to compete with Apple Silicon, though a stronger Microsoft might also have influenced how Apple evolved. Apple Silicon was really in Apple’s DNA from the earliest days and was almost an inevitable outcome of the failure of Motorola, PowerPC, and then Intel to contribute to what Apple saw as its destiny. I look at that work and wonder how we might have responded because we most certainly would not have gone down that path. It was one thing to assemble the components and PC and bring it to market. It would have been quite another to have the audacity to create a chipset.

Since leaving Microsoft at the end of 2012, I’ve spent many hours discussing and debating the specifics of Windows 8 with friends, former coworkers, current employees, start-up founders, reporters, and, well, people who are just curious. Most of the time is spent discussing platforms, ecosystems, and tectonic shifts that one faces after unimaginable success, at least when we’re not just tackling my favorite topic and the bread and butter of Silicon Valley, which is growing and scaling innovative companies and teams. There remains a desire, especially among the reenergized Microsoft community, for more about specifics on the perceived misdirected product choices. In many ways that discussion is both easy and impossible. It is easy because there are only a few things to point to. It is impossible because if the situation could have been so easily addressed by changing something that was so readily identified, then that would have made for a quick fix.

Maybe wanting so much more for Microsoft’s products was the bigger mistake, more than changing the Start menu or breaking with legacy compatibility. That apocryphal Henry Ford adage about cars and horses was meant to point out that people express their needs relative to what they understand the possible solutions to be. Windows customers wanted Windows, a faster Windows, but they didn’t want something different…until they did.

There’s an old USENET meme used to make fun of seemingly trivial problems by claiming something is the “hardest problem in computer science.” It might very well be that the actual hardest problem in computer science is a company reinventing its own successful computing product for a new era in a way that existing customers are willing and excited to use. The irony is that those same customers always seem willing, and excited, to jump to the next era of computing using products from another company. Maybe that is a net positive and it is nature’s way of restoring, even rebirthing, our technology foundation.

The impact of Windows 8 and the way Microsoft chose to move on so quickly did have one important and chilling effect. Not only did so many people leave or were made to leave, but the culture that replaced them became risk averse and one that rewarded not failing more than taking risk. There was a fear of repeating a Windows 8, whatever that might have meant. For all the focus on growth and the ever-rising stock price, that meant growth of revenue more than new customers, scenarios, or business approaches. Soliciting feedback, voting on features, listening to customers, or creating products for all platforms are not substitutes for a point of view or strategic moat, as our industry has shown time and again—as counterintuitive as that might be.

A decade has passed since Windows 8 and product releases from the company have done little to avoid the IBM fate, a fear of which BillG firmly implanted in my psyche.

Half will read that and mock me for suggesting any of it and that explains all that’s needed to understand the failure of Windows 8. The other half will read that wondering who IBM was and when exactly they mattered. I started my career when IBM cast a shadow over every aspect of the technology industry and was fortunate to experience when Microsoft rose to that position. Bill instilled this very fear into all of us even before the internet or the split with IBM.

Ibn Khaldun, an Arabic philosopher during the Middle Ages, wrote that in war “the vanquished always seek to imitate their victors.” In business it is often the other way around. The victors end up becoming what they vanquished, as victors inherit the same problems on a new technology and product base. It might take years, but creative destruction is just as certain to take place. My Harvard Business School friend and previous co-author Marco Iansiti once joked to me that the school considered rebranding disruption theory as physics or math, not simply theory.

Despite how the product landed and then crashed, Windows 8 was the most committed, skilled, and brilliant Windows team ever assembled and it had one mission: to give the PC a new direction for a new world. Ultimately, under my leadership and management we failed to build a product that would change the trajectory of Windows or PCs. We failed, however, with elegance, grace, and an amazing group of people doing their most memorable and rewarding work. Unlike many failed efforts at Microsoft, we had remarkable execution. Like many failed efforts at Microsoft, we had the right ideas but the wrong timing. The Windows market wasn’t ready, but when it was ready, Microsoft was too late. Windows 8, therefore, was both too early and too late.

Windows 8 was the last product to be made by Microsoft’s definition of hardcore software. Some will say that is a good thing. It is neither good nor bad, but simply is. It is how eras evolve and the torch passes from one generation to another.

I was attracted to Microsoft by the level of product and technology acumen of every single person I spoke with all the way up the chain to the founder and CEO, the office with a door, the free drinks, and the Pacific Northwest. What really got me was what I saw as the true nature of hardcore software.

To be hardcore is to be wildly optimistic about what can be achieved tomorrow while harshly pessimistic about what works today. Creating software is an art. It is computer science and engineering. It is inspiration, and perspiration. It is inherently individual yet relies on a team. Most of all, building software is a group of people coming together to conjure something into existence and turning that into a product used by billions.

And that is Hardcore Software.

Happy Holiday to those in the US. This is a special double issue covering the creation and launch of Microsoft Surface, an integral part of the reimagining of Windows from the chipset to the experience. To celebrate such a radical departure from Microsoft’s historic Windows and software-only strategy this post is unlocked, so please enjoy, and feel free to share. I’ve also included a good many artifacts including the plans for what would happen after Windows 8 released that were put in place. The post following this is the very last in Hardcore Software. More on what comes next after the Epilogue.

As a thank you to email subscribers of all levels, this post is unlocked for all readers. Please share. Please subscribe for updates and news.

Back to 106. The Missing Start Menu

In 2010, operating in complete secrecy on the newest part of Microsoft’s campus, the Studios, was a team called WDS. WDS didn’t stand for anything, but that was the point. The security protocols for the Studio B building were strengthened relative to any other in the entire engineering campus. Housed in this building was a team working on one of the only projects that, if leaked, would be a material event for Microsoft.

WDS was creating the last part of the story to reimagine Windows from the chipset to the experience.

When we began the project, it was the icing on the cake. After the Consumer Preview, it had become the one thing that might potentially change the trajectory of Windows 8.

As Windows 7 finished and I began to consider where we stood with hardware partners, Intel, the health of the ecosystem, and competing with Apple, I reached the same conclusion the previous leader of Windows had—Windows required great hardware to meet customer needs and to compete, but there were structural constraints on the OEM business model that seemed to preclude great hardware from emerging.

At the same time, the dependence on the that channel meant there was no desire at Microsoft to compete with OEMs. In 2010, the Windows business represented 54% of Microsoft’s fiscal year operating income and Office was 49%—yes you read that correctly. BillG used to talk about that amount of revenue in terms of the small percentage of it that could easily fund a competitor or alternative to Windows. The “Year of Linux” was not just a fantasy of techies but a desired alternative for the OEMs as well. So far the OEMs had not chosen to invest materially in Linux, but that could change especially with an incentive created by Microsoft’s actions.

Like my predecessors, I believed Microsoft needed to build a PC.

Building PCs was something BillG was always happy to leave to other people. In an interview in 1992, Bill said, “There’s a reason I’m the second-biggest computer company in the world…. The reason is, I write software, and that’s where the profit is in this business right now.” On the other hand, the legendary computer scientist and arguably father of the tablet concept, Alan Kay, once said, “People who are really serious about software should make their own hardware.”

Microsoft was founded on the core belief that hardware should best be left to others. In the 1970s hardware was capital intensive, required different engineering skills, had horrible margins, and carried with it all the risks and downsides that pure software businesses, like the one BillG and PaulA had pioneered, did not worry about. With a standardized operating system, the hardware business would quickly consolidate and commoditize around IBM-compatible PCs in what was first a high-margin business that soon became something of a race to the bottom in terms of margins.

Microsoft’s fantastic success was built precisely on the idea of not building hardware.

BillG was always more nuanced. He and PaulA believed strongly in building hardware that created opportunities for new software. Microsoft built a hardware device, the Z-80 SoftCard, to enable its software to run on the Apple ][. Early on, Microsoft created add-in cards to play sound. PaulA personally drove the creation of the PC mouse, the famous green-eyed monster. Modern Microsoft built Xbox, but also Zune and the Kin phone.

Apple built great hardware and together with great software made some insanely great products.

To build hardware in this context meant to build the device that customers interacted with and to build all the software and deliver it in one complete package or, in economist’s parlance, vertical integration.

Mike Angiulo (MikeAng) and the ecosystem had the job of bringing diversity to the PC ecosystem, a diversity that Apple did not have. This diversity was both an enormous strength and the source of a structural weakness of the industry. PCs in any screen size or configuration one might need could always be found or even custom built covering any required performance and capacity. If you wanted something like a portable server or a ruggedized PC for a squad car or a PC to embed in 2 Tesla MRI, Windows had something for you. Apple with its carefully curated line essentially big, bigger, biggest with storage of minimum, typical, maximum across Mac were the choices. Even a typical PC maker like Dell would offer good, better, best across screen sizes and then vary the offering across home, small business, government, education, and enterprise. Within that 3 x 3 x 5 customization was possible at every step. This is the root of why Apple was able to have the best PC, but never able to command the bulk of the market.

The idea of vertical integration sounds fantastic on paper but the loss of the breadth of computing Windows had to offer was also a loss for customers. It is very easy to say “build the perfect hardware” but the world also values choice. One question we struggled with was if the “consumerization” of computing would lead to less choice or not. In general, early in adopting a technology there is less choice for customers. Increased choice comes with maturity in an effort to obtain more margin and differentiate from growing competition.

One bet we were making was that Windows on ARM and a device from Microsoft was the start of a new generation of hardware. It would start, much like the IBM PC 5150, with a single flagship and then over time there would be many more models bringing the diversity that was the hallmark of the PC ecosystem.

That is why we never built anything as central and critical as a mainstream PC, and never had we really considered competing so directly with Microsoft’s primary stream of profits and risking alienating those partners and sending them to Linux. The Windows business was a profit engine for the company (and still is today) and that profit flows through only a half dozen major customers. Losing even one was a massive problem.

Microsoft had also lost a good deal of money on hardware, right up to the $1.15 billion write-off for Xbox issues in 2007. Going as far back to the early 1990s and the original keyboard, SideWinder joystick, cordless phone, home theater remote, wireless router, and even ActiMates Barney our track record in hardware was not great. Microsoft’s hardware accessories were at best categorized as marketing expense or concept cars. It was no surprise my predecessors backed off.

Like the mouse, the sound card, and perhaps Xbox, I was certain that if we were to succeed in a broad platform shift in Windows that we would need to take on the responsibility and risk of building mainstream and profitable PC devices. We tried to create the Tablet PC by creating our own prototypes and shopping them to OEMs as proofs of concept. We repeated this motion with the predecessor to small tablets called Origami, same as we did for Media Center. Each of these failed to develop into meaningful run rates as separate product lines even after the software was integrated into Windows.

OEMs were not equipped to invest the capital and engineering required to compete with Apple. As an example, Apple had repurposed a massive army of thousands of aluminum milling machines to create the unibody case used in the MacBook Pro. Not only did no OEM want to spend the capital to do this, but there was also no motivation to do so. Beyond that, the idea of spending a huge amount capital up front on the first machines using a new technology until a process or supply chain could be optimized was entirely unappealing even if the capital was dedicated.

The OEMs were not aiming for highly differentiated hardware and their business needs were met with plastic cases that afforded flexibility in design and components. In practice, they often felt software was more differentiating than hardware, which was somewhat counterintuitive. The aggregate gross margin achievable in a PC software load was a multiple of the margin on the entire base hardware of a PC. The latest and coolest Android tablet was a fancy one made by Samsung, with a plastic case. The rise of Android, a commodity platform, all but guaranteed more plastic, lower quality screens, swappable parts, and the resulting lower prices.

The OEMs were not in a battle to take share from Apple. They were more than happy to take share from each other. Apple laptop share was vastly smaller than the next bigger OEM making Windows laptops. Each OEM would tell us they could double the size of their entire company by taking share from the other OEMs. That’s just how they viewed the opportunity. The OEMs were smart businesspeople.

Thinking we needed to build hardware, then building it, was one order of magnitude of challenge. Choosing to bring a product to mass market was another. Hardware is complicated, complex, expensive, and risky—risky on the face of it and seen as risky by Microsoft’s best customers.

The Surface team, organized within the Entertainment and Devices division home to keyboards and mice, finished the first release of their namesake computer. It was a Windows Vista-powered table like the ones popular in bars, pizza places, and hotel lobbies in the 1980s when they ran Frogger. The new platform software provided the cool demos for Windows 7 touch. Surface came about from a research project rooted in long term efforts around optics and display technology. The effort was productized as the original Surface, with Panos Panay (PanosP) brought in to help accomplish that from the peripherals group. Unfortunately, the commercial viability of the table was limited. RobbieB, the executive of the division (that also included Xbox and phones), was looking to offload the effort or better said make Windows pay for it.

We would move the team over to take on our hardware challenge if we could figure out an arrangement that would not torpedo the Windows business. It was this step that put a halt to all previous projects.

Managing what could become a first-party hardware effort from within the Windows team posed significant challenges, even obstacles. PC OEMs would rightfully become unglued if they believed the decidedly limited, information they shared with MikeAng’s ecosystem team about their plans was shared with other OEMs. If their information were to be shared with a first-party team, that was even worse. Some of the earliest concerns expressed to regulators about Microsoft had to do with the walls, or lack thereof, between different parts of the Microsoft ecosystem and competitive parts in Microsoft, for example, between Windows and Office, where Office might have an unfair advantage. I had no desire to further a conspiracy theory.

JulieLar offered her own set of challenges, but almost the opposite in nature. She was concerned about having a first-party hardware team that acted like an OEM more than a part of Microsoft. She wanted our hardware to fully embrace, not mangle, the Metro design language. I hardly wanted a team that would embrace the economics of OEM, such as crapware and expensive accessories.

Collectively we wanted a decidedly-non OEM to be our OEM.

Both Julie and Mike spent a lot of time with Panos to help us all arrive at a structure and work process that was set up for success. Panos joined Microsoft in 2006, relatively recently, after working at NMB Technologies, an expansive 60-year-old Japanese maker of electronics components including keyboard switches and skateboard ball-bearings (that I used to pay top dollar for in high school.) The complexities for Panos in jumping into the thicket of Windows were significant, not to mention the delicate nature of first-party PCs. The concerns for all parties were legitimate.

The idea of a whole hardware team moving over, rather than building one organically, was worrisome, but we did not have the time to start from scratch. By most any measure, the idea that in about 30 months we would have a new ultramodern PC built on all new components the industry had never used before by a team that had only made a table computer was crazy. Panos’s commitment to being part of the massive effort was not just significant but deeply sincere. He saw the opportunity the same way we did—a chance to reimagine Microsoft.

Working for Mike, Panos would expand the team in every dimension. Hiring and growing engineers for hardware, firmware, mechanical, plastic, manufacturing, acoustic, industrial, and safety, with designers from graphical to industrial to packaging, along with all the support functions I neglected to mention in that long list. We even had to embark on some special construction in the buildings to account for the needs of the kind of equipment required to build a PC.

WDS was formed in June 2010 just as we were beginning to code Windows 8. We did not even send out an org announcement mail, keeping with the secrecy of the project. The name “Surface” moved over with the team and would naturally stick with the device when we were ready to bring it to the public. For now, codenames and codewords were in order. Not just one codename, but an entire system of codenames. We had codenames for every part including unique codenames used for each vendor – part combination. There were codenames for every presentation. Over the course of the project, we maintained over 200 codenames. Why? The secrecy was to maintain our commitment to keeping information separate.

It is worth noting, we were piloting ARM work on NVIDIA Tegra hardware and seeding any groups across the company with ODM-style tablets housing Tegra components. No one inside Microsoft lacked hardware for testing, evaluating, or betting on Windows on ARM.

The next 18 months were the most remarkable sprint in hardware development I could have ever imagined. Panos built an extremely tight and remarkably talented team to deliver products in relatively short time. Everyone stepped it up to a new level. One of the most critical aspects of assembling this team was his direct manager, MikeAng, who created a cocoon around the team, isolating them from all the forces internally. Mike also mentored Panos on the product development methods used to create Windows while apprising him of the best ways to integrate with the software team to avoid thinking like an OEM—the key problem we set out to solve.

One of the things that Mike had to do which was super valuable for the whole effort was to be the “vault” for information about Surface and information about the PC ecosystem. The two orgs, Ecosystem and Surface, could have absolutely no information leakage between them. In many ways, the integrity of the Windows business model was in Mike’s hands. It was easy to trust Mike since I’d worked with him since he joined Microsoft out of college, and his post-Microsoft career included becoming a lawyer, so I think it is fair to say he was the perfect person for this role. As we’ll see it was just a bonus that he was exactly the right kind of engineer for this role as well.

The core of the WDS team had previously worked together, but the scale of their previous projects was small by comparison—everything was bigger in Windows. The team doubled from the early days of mice and keyboards to a broad range of peripherals and most recently Xbox consoles. Ten years in, Xbox was selling about ten million units a year (about 800,000 in 2021) and the business remained roughly break-even due to console margins. We had much grander aspirations.

The story of the two devices, both tablet form factors, that became the first Surface PCs was one of incredible design and engineering efforts going through a remarkable series of iterations in an incredibly short time and then scaling to manufacture millions. It was also a blur. Creating a PC was new for me as well. It is not only fair, but important, to say that without the collaboration across Julie’s product team, JonDe’s engineering team, GrantG’s test team, and Julie herself, we would not have Surface. Jensen Harris (JensenH) and the entire UEX development provided an attention to detail on everything from the BIOS boot screen the on-screen keyboard, sound scheme, to the out of box experience that rivaled anything Apple did. It is one thing to build a reference PC within the walls of Microsoft—something done many times before. It is entirely another thing to deliver the innovation and scale of products that we did, and then bring it to a worldwide market.

I cannot stress enough how much of a whole-organization effort Surface was.

We did not set out to build what the industry was calling a consumer tablet or a tablet for consuming information and lightweight computing needs, as many, or just Apple, characterized the tablet market relative to the PC market. The world did not need more of that. Microsoft’s heritage and business rested with productivity, so the overarching goal was to create a PC that was great for productivity, creation, and mainstream information work. The PC would just happen to fit the current definition of a tablet, which was smaller than an 11.6” laptop and usable as a screen and a traditional laptop posture.

To justify building our own hardware we needed a unique point of view.

We believed that if we could build a tablet that worked fantastically well for the web and Office, while being ultra-lightweight and ultra-reliable, we could redefine the device that constituted the bulk of PCs used in school and work. One of our most significant challenges was that the narrative for new devices was a dominated by tablet, meaning a keyboardless slate focused on consumption. This created the situation that even if we achieved our vision technically, we had an enormous communications challenge.

The first Microsoft device, code-named GT or Georgetown for no real reason, was a premium ARM tablet able to deliver on the promise of PC-style mobile productivity. The whole point of building hardware as a first party was to do what the PC ecosystem would likely struggle or simply decline to do, and ARM was first among the challenges faced. The PC makers had all been struggling to enter the smartphone market, and ARM required a significant amount of product engineering and investment that was inconsistent with the low-priced mindset. Besides, they were fully occupied with Netbooks and later Ultrabooks and seeing little success with smartphones. As described in section 101, those OEMs working with ARM were genuinely enthused and supportive, but somewhat like Detroit’s reaction to electric cars, the internal tension proved too great to create and bring to market ARM, at least for the launch of Windows 8.

Whether premium implied premium price along with a premium experience was an ongoing debate. Typically, in hardware designs, manufacturers work backward from a retail price goal, assuming a certain BOM, margins, volume to manufacture (impacting the BOM or bill of materials), marketing and sales costs, returns, and so on. As product makers, this makes intellectual sense, but it frontloads so many constraints that rarely do great products emerge. I chose to start from the user scenario and see how far we could go and what we could get for what price, knowing that as we converged difficult decisions would arise.

This was a point of constant discussion with SteveB, who—and this was not news or even unique to this project—favored low prices and high volumes. Gaining market share was always preferable and what had gotten Microsoft to where it was. I felt this time we needed to take a different approach—reimagine what a Windows device could be even if that meant we start at the high end, perhaps like Tesla was doing at the time with Elon Musk’s famously not-so-secret secret plan to iterate to a lower price with greater scale, funding that iteration with earlier high-priced products.

Early in the process, Mike and Panos set the tone for the role WDS would play in the overall strategy for Windows 8. It was extraordinarily helpful. The mantra for the joint efforts of hardware and software coming together was expressed as, “our job is to build a stage, a stage for the operating system and software.” This fit well with the whole design for Windows 8 software, which itself was viewed as a stage for apps and user creations. The idea that every layer of the system was trying to get out of the way of the other layers above aligned entirely with the Metro design language, and also exactly what no one ever did, especially OEMs. This was in stark contrast to typical PCs and even typical OS iterations of the past, which felt the need to announce themselves whether via branding (those Designed for Windows or Intel Inside stickers, for example, that don’t even appear on Apple laptops because they drove Steve Jobs crazy) or via icons, popups, or notifications.

We were not designing the hardware experience after the software experience (or before); rather, we were designing the hardware and software experience together—a reimagined experience.

I tried to keep my own role in check. I’d seen many past hardware cycles within the company where there was so much going up and down the chain, so much approval, and so much tweaking by executives. Plus, it is crazy easy to have an opinion on a device and act like some enlightened big-shot executive. Panos’s experience with executives at Microsoft rightfully made him wary of me at first. Executives often had an outsized view of their contribution while underestimating the amount of work, backchannel, and eyerolling they caused. Advertising, pricing, user interface design, and feedback on hardware were places that executives easily meddled. And for that, teams suffered.

I used a lot of different laptops. I bought nearly every iPad typing cover available (and there were dozens). I was a road warrior, so I was real-time testing. I used browsing, email, and Office a lot. I could have probably justified my own opinions, and many times I really wanted to, but had to resist the urge. I had asked Mike and Panos to pull off what by any measure would be a Herculean task. My responsibility was not to meddle.

From my vantage point in developing the product, there were five inflection points in the design process—a high-altitude view since there were thousands of choices made in developing the product. At some level these were choices to be made or constraints. The project could have easily become impossible or careened off path with so many potential degrees of freedom. Anyone who looked at the typical roundup of PC laptop reviews for back to school or holiday was left browsing a dizzying array of specs, ports, dimensions, and component choices. It would have been easy to get lost in all these decisions to be made. Each one of those decisions is related to many others in an ever-complex set of linear equations to be optimally solved.

The team picked these key points in the design process: chipset, the productivity posture, typing, materials, and peripherals.

By establishing the initial platform of ARM and a sub-11” form factor many of the traditional “spec” issues of designing the device would fall out. But this understates just how many and how fast, Panos and team needed to put constraints in place—constraints that would maintain a point of view and deliver a product.

The chipset was perhaps the most straight-forward choice for the team to make on technical grounds, though hardly without controversy or for lack of a better word politics. There was a good deal of pressure from the Windows Phone team and from some OEM partners who were still trying to build phones of their own (though on Android now) to go with Qualcomm. Qualcomm was viewed as a safe choice and the choice with the most intellectual property and lawyers to support that. On the other hand, the early hardware was far from ready to build a PC especially the graphics support which was so critical. It was the first taste of developing a product where the choices had implications beyond building the best experience. My own view from dealing with Qualcomm was that they were more concerned with the volume of devices we would commit to up front than with the quality or innovation we would deliver, even early in the process.

The teams working across Windows porting to ARM were favorable to NVIDIA given the choices we had. In particular, NVIDIA was strongest on graphics which were key to the Metro-style experience. The underlying graphics chips mapped closely to our DirectX API and made developing device drivers supporting the animations and effects we needed with the performance we required as straight-forward as could be given all that was new. Aside from that NVIDIA was a joyful partner and great at working with ODMs to supply test hardware.

Ralf Groene (RalfG) led hardware design efforts for WDS. He joined Microsoft with a classic design education and experience at several marquee design houses in Silicon Valley. If we were casting a movie for an industrial designer, Ralf would be perfect. RalfG and the design team were cycling through prototypes of sizes and overall form factors at an incredible pace. Engineering for productivity and typing fell to the design team, with a very strong collaboration with the UEX team to make sure the software could gracefully adapt to the presence or absence of a keyboard and trackpad.

The kickstand was such an amazing choice. Yet I lack a clear recollection of the genesis of it, only that the moment I saw it I was convinced it was an inspired choice. Having a kickstand solved the main problem tablets had, which is how to keep using one when you wanted to put it down or more importantly to type. The kickstand could easily have been a gimmick but in fact it became an iconic element and one that served to further the point of view centered on the dual modalities of consuming content hands-free and full-time work on the go. The kickstand would have tradeoffs in real-world usability, especially with the larger devices to come later, but the for the first generation I felt it was exactly the tradeoff to make.

The design team iterated with a kickstand, something that had been found on some early media players and phones. Should the kickstand be two small legs, one fatter leg, or something else? Should it support both landscape and portrait? The team settled on a full-width kickstand, almost a fold-out foot that provided a rock-solid level of stability. That stability came from a unique hinge design, created entirely by the mechanical engineers on the team. Opening and closing the hinge had the feel and robustness of a luxury car door, a German one of course. As the hinge closed the air dampening effect would give the motion a soft cushion with a nearly inaudible, but intentionally there, sound of luxury. I once spent time in the lab with the mechanical engineer on the team amazed at just the complexity and number of choices that were considered in the design and fabrication of the hinge. It was a great example of how every small detail is vastly more complex than readily apparent.

The beauty of the hinge and kickstand were that they reduced the thickness of the whole productivity scenario by quite a bit—the plastic cases of the iPad including Apple’s own cases were true compromises. The 2015 Folio, which added two layers of material in a complicated origami-folding design and later the 2018 Magic keyboard, which was just heavy at 600 grams or 130 grams more than the iPad itself, were both awkward. The latter keyboard added so much weight and thickness to the iPad that it was more practical to carry a laptop. Whereas Steve Jobs had to sit in a chair holding the iPad, with Surface one could hold it or flip out the kickstand and watch the move while enjoying popcorn, or having a video conference with the integrated HD webcam angled precisely enough so it would capture your head and not neck or below when placed on a table.

Important for the productivity posture was the overall size. When working, a screen can never be too big, but when traveling a screen can never be too small. Finding the balance was super important. The math would work out super well to have a screen that was 10.6-inch diagonal but with a widescreen layout of 16x9, the typical HD or Blu-Ray numbers. At 1366x768 the screen was equally optimal for the new Windows 8 snap view to show two apps side-by-side—GT as a stage for Windows 8—and also to display movies full screen without the drawbacks of letterbox modification that consumers hated.

There was quite a bit if a debate over 16:10 versus 16:9 aspect ratio and the possible screen resolutions. UEX favored the extra width of 16:9, though 16:10 offered more vertical space for productivity but could not support side-by-side apps. The availability of components and cost of using the UEX preference made it a tough choice. This was also an area where we were going against the iPad trend which picked a more traditional even old 4:3 aspect ratio used on NTSC TV and VGA monitors at 1024x786 which was also criticized in reviews for letterboxing widescreen video. The iPad was between wide screen video and the traditional trade book and Amazon Kindle aspect ratio of 3:2.

From a supply chain and manufacturing perspective, the choice was more complex. The supply chain for screens was following the volume of all manufacturers combined. No single manufacturer could simply order a size not being used by others without committing to volume. In 2011 the dominant size for tablets was a 10.1” screen with 1280x800 resolution, a 16:10 aspect ratio. We saw the 1280x800 resolution as a waypoint, picked for price by the Android tablet ecosystem. It was neither good for productivity in landscape nor good for reading in portrait mode.

We were deeply committed to having a screen that supported the side-by-side view of two apps in landscape. This came with a real tradeoff, however, in the usability as a pure tablet. In other words, even from the choice of screen we were optimizing for productivity. When used as a “reading tablet” the portrait mode orientation of 9:16 was particularly awkward. Reading with one hand holding the device was tiresome, like holding a college chemistry textbook in bed. Additionally, traditional laptops with 13” or 15” screens had moved in large numbers with Windows 7 to the 16:9 and 1366x768 resolution, indicating that resolution was an excellent design point for apps and would be around for years to come.

The screen had two other technical issues to work through with significant impact on the experience. First, the core display technology for LCD screens was in the midst of a transition from MVA (Multi-Domain Vertical Alignment) to IPS (In-Plane Switching) with the latter being the newer technology. Going with the newer technology would be preferred as a basis for applying a touch sensor, but that further constrained the potential supplies and sizes.

Second, the display panel would need an extra stage in manufacturing to attach a touch panel sensor. There were two approaches here as well. The standard approach, again for Android tablets, was known as air-bonding. In this technique the touch panel does not directly touch the underlying display panel leaving a small gap which eases manufacturing. Unfortunately, this also introduces parallax, an effect by which where you touch and where the sensor detects your touch do not always align in your brain. This is seen at check-out counters and ATMs which prefer the manufacturability and low-cost of this approach. While cheaper, it is a disaster for precision work on a PC. The newer approach, direct bonding, used by Apple and more premium tablets, directly bonded the touch sensor to the display. This was more expensive and had a non-trivial defect rate increasing costs as well.

The way you know from the supply chain that you are asking for something difficult is that the price goes up and delivery goes further out. The suppliers, all singing from the same page, strongly encouraged a 16:10 screen with 1280x800. Their view was that this was the volume tablet resolution. After many trips and many meetings, we were able to secure a high-volume supply of the 10.6”, 1366x768, IPS, direct bonded screen. This was a tough choice and added early risk, but once you lock in a supplier as a volume partner risk finds a way of decreasing. I suspect over time even for the 10.6” screen we would have gone with a more comfortable aspect ratio, but by then we would have had more answers to windowing and productivity than we had with Windows 8. I’m getting ahead of myself.

Productivity without a keyboard is not really productivity. We were not confused about this point as they were in Cupertino. Productivity without a mouse or trackpad, on the desktop, was not even possible. Because Windows RT had the desktop and desktop Office, a trackpad was required. The 10.6-inch diagonal screen would create a case with a 10.1-inch long edge, which by no accident was wide enough for a nearly full-size home row of keys for touch typists. This could be a huge advantage over the keyboard for the iPad, which was only 9.5 inches across, making a big difference in key size and spacing. Our screen size allowed for arrow keys and a row of function keys with the trackpad. These small differences bring a world of benefits when designing devices with which people have such intimate reactions. This is decidedly different than a desktop PC or even a large laptop. There’s something about a device that must be held that makes small decisions so much more important.

The keyboard presented a unique opportunity to innovate to maximize portability. Panos himself personally an expert in mechanical keyboards and part of Microsoft’s own efforts in innovative keyboards was well-positioned to develop two keyboards we would introduce with GT.

Fundamental to the keyboard was the idea that it would be faster and more accurate than touch typing on a glass screen and include a trackpad for precision, or “professional,” pointing as so many reviews of iPad noted was lacking. Since GT had a kickstand, the keyboard did not need to also serve as a redundant cover for the back but when folded to cover the screen would offer screen protection. The underside of the keyboard was covered with a layer of what I always termed northwest fleece with a soft woolen feel when carrying GT around in your hand.

Our folding keyboard could make an easy transition from productivity and typing to reading or watching while lounging around. The keyboard itself was a touch-based invention from Stevie Batiche (StevieB), who was the resident scientist/engineer leading all things touch and display, and a genius. We would also add a very thin mechanical keyboard, one of the thinnest mechanical keyboards ever released to market. Our hearts would be with the touch keyboard at launch owing to its productivity and on the go scenario.

StevieB’s ultrathin keyboard invention was essentially a touch panel with ever-so-slightly raised key outlines impressed on the panel. The electronics were created by laminating several layers of materials including a touch sensor and all the “wiring” together in a hot press machine—sort of a touch screen sandwich. The keyboard, called Touch Cover, was a mere 3.2mm and weighed only 7 ounces and under 200 grams. Given the dimensions of the screen, Touch Cover was able to incorporate a trackpad on par with many small laptop trackpads and a complete set of laptop keys including dedicated keys for Windows 8 charms along the top row, which also doubled as traditional PC function keys. In US English even the F and J keys had slight outward impressions for traditional typists to find the home row. There would be many skeptics about the keyboard when it came to typing proficiency. While there were many risks in the entire project, at the time Touch Cover seemed like the riskiest part of the project. It would be so immediately visible and open to snap opinions. The press that typed for a living were used to their preferred “feel” when it came to laptop keyboards, often a sore spot for just about every Windows laptop review.

GT had a beautiful hinge and an incredible touch keyboard, but how to attach the keyboard posed another challenge. Because of the hinge the cover could not be attached to the back of GT, but that would be dumb anyway—adding weight with no purpose was what we saw on the iPad. Once again, the mechanical engineers had a go at the problem. They put magnets to work. Not just any magnets, but a series of magnets of exactly the right strength to support the device, even swinging it from the keyboard, while also easy to remove. The magnets did not just attach the keyboard to the tablet but they were the connectors for the signal and power. Attaching the keyboard had to perfectly align the connectors or it would not work.

The magnetic keyboard was a more difficult to path to perfection and reliability. Upon first seeing it, just as most others, I was skeptical. Would it fall off? Would it properly align even when connected in a sloppy manner? Would flipping it around to use as just a tablet prove “goofy” or would it really work? Would Windows correctly enable the on-screen keyboard at the right time and get out of the way entirely when a keyboard was attached? Would it work just as well for the thin mechanical model?

The process of connecting the keyboard to the device proved to be more than just reliable but something of a signature. The first time we showed the Surface to the team that would lead creating television commercials they immediately connected with the “click” sound the engineering team worked so hard to get right. That click would become the centerpiece of the initial campaign along with the profile of GT and the keyboard. A subdued version of a magnetic connector also with a click would be used for the very small charging adapter. Ironically, Apple’s pioneering MagSafe connector that was so popular on MacBooks was not used on iPad, which took its lead from iPhone for charging. Even today Apple continues to struggle with magnets when it comes to covers and keyboard cases for the iPad. The new 2022 iPad typing portfolio with a kickstand is kind of a mess.

The removable keyboard provided several advantages. To compete in the “pure” tablet market the keyboard could be priced optionally and also be reviewed as an accessory versus required. It also permitted personalization by choice of colors since the laminating process was able to substitute any color materials for the back or front. The back of the Touch Cover could be customized in both material and look, for example corporate logos or art as we later offered. Finally, StevieB’s innovative touch panel was not restricted to keys and could be used to create any touch surface. Since it could be removed easily, we envisioned the potential to have specialized Touch Covers dedicated to specific applications. One example we showed early on was a synthesizer drum app mated to a custom keyboard. At a small, private event held one night in Los Angeles I even had a chance to watch actor/musician Zack Efron of High School Musical have fun with the prototype music generating cover.

The materials choice for inner fame and device case were almost always where the OEMs made choices that were best for the bottom line—plastic provided low cost, light weight, rigidity, ample room for cooling, and agility across component and peripheral changes. This is where Microsoft’s ability to provide a significant investment could make a real difference in the final product. The engineering challenge with case materials is the triangle of cost, weight, and rigidity. Cost is not only the cost of the material, but the manufacturing cost of making the case, with all the curves, holes, and cutouts that make it a computer. Materials can be inexpensive and lightweight but too flexible to be durable—the screen is glass and needs structure to prevent it from flexing and breaking. Materials can be rigid and lightweight but cost a tremendous amount, such as ceramics used in fighter jets. Aluminum is lightweight and relatively rigid, but to bring the cost down Apple invested a huge amount of upfront capital in order to take blocks of aluminum and use mechanical milling to turn it into a PC.

We needed the device to be as thin as possible and from the start we considered every fractional millimeter we could save.  We knew that bringing over Windows in one product cycle, including the desktop, would bring real challenges to our ability to compete with the nine hours of video playback possible on the iPad. We needed every available millimeter for battery. An innovation in materials could prove a game-changer.

In research, the materials scientists became intrigued by a relatively new process of injection molding a magnesium alloy. Such a material was expensive and the manufacturing process complex, but the resulting parts were lighter than machined aluminum, extremely rigid and strong, and created by more flexible molding. At this point, the injection molding process had only been used for small parts such as watch frames or jet engine components, but the materials partner, Mike, and Panos’s team thought it possible to use for the much larger cases. The material could be readily colored via a permanent and robust vapor deposition process, which afforded other opportunities.

MikeAng, a mechanical engineer by training and certified alloy welder, dove into the process, visiting the factory in Asia. He returned with movies of cases being injection molded that looked like scenes from 20th century industrial America—sparks flying, molten flows of metal, giant machine presses.

Betting GT on this new process was one of the more uncertain aspects of the hardware design, and also very expensive, relatively. The high upfront costs made us all nervous. With any upfront cost, called NRE, or non-recurring engineering costs, the only way of justifying them is to make a lot of the product which spread the cost across many devices. That was certainly our intent.

The material would get the name VaporMg, pronounced vapor mag. Finished in a smooth, so smooth, black-gray, the material was another manifestation of the collective efforts of design, materials, and manufacturing coming together. While we originally planned to make the entire case out of VaporMg, supply constraints resulted in a more traditional aluminum frame with VaporMg used more sparingly. While that resulted in a bit of increased weight, the resulting scaled manufacturing and cost reduction were a good tradeoff.

There’s no doubt that VaporMg was the most extravagant choice in the whole project and one I felt the most over-extended in considering. In a big company with plenty of money, it is not uncommon to see branching out into new areas take on almost comically bad cost controls relative to industry norms. Without experience or baselines to compare and with all the excitement of “those other people doing this must be dumb” it is so easy to do this. Across the product, Mike, Panos, and team had extremely good controls and constant attention to the BOM, bill of materials, and NRE. Mike was a product of our frugalness in Office and brought that to this project and team. The VaporMg choice was one I felt we should go with even though it was so uncharacteristic for me or much of Microsoft.

One thing we considered was that we could reuse the materials process and plant capacity with other OEMs and license it to them for whatever devices they wanted to build. The idea of acting as a source for various components was a step we considered for trackpads and touchscreens as well as we saw OEMs unwilling or unable to take on the NRE costs to create competitive laptops. Once again though, I probably failed to consider they also viewed such costs unnecessary when it came to their share battle competing with other OEMs more than competing with Apple.

VaporMg was so strong that the team turned a standard GT chassis into a skateboard, on a lark. As a former skateboarder this thrilled me to no end. At one of the many press events hosted on campus offering a behind-the-scenes look at developing hardware, I skated around the lobby of Studio A. Not to worry, I was wearing a helmet though it was a borrowed bike helmet we located just for the photos. We snapped some photos that continue to live on. To further demonstrate the strength of the material, we showed off the drop-test machine that simulated dropping a tablet with different forces and angles and even directly on the kickstand—each time GT performed admirably. Protected by the Touch Cover, the combination felt relatively indestructible. The screen was securely protected without any extra casing on the back maintaining the thin profile and light weight.

Finally, productivity for a premium laptops and tablets circa 2012 still depended on wires or more specifically dongles. Apple’s MacBook Air approach of wireless everything was conceptually great but practically a pain, certainly in the early days. Carrying around dongles to connect to projectors or to USB devices was annoying and error prone. As a tool for productivity, GT needed to show up at a meeting and get handed the slides on a USB drive, pop the drive in, launch PowerPoint, and then connect to a projector, or handle devices like microphones and speakers. As a stage for Windows 8, we had optimized this type of flow from a performance and user interface perspective—get to the user’s work product and get to work as quickly as possible.

Mike and Panos framed GT as a device that should connect in the way people needed it to connect. GT had a standard USB port, standard audio output, and a mini-HDMI port in addition to the dedicated magnetic-charging connector. The USB port was rather tricky as it set a minimum thickness that was not an issue on the iPad that did not have a universal USB connector. The fat USB port was a bit ugly and some on the industrial design team referred to it as a “missing tooth” in an otherwise sleek profile. At one point we were so close to the standard for a connector we risked losing the trade group designation and permission to use the logo. This in addition to strong support in hardware and software for all the current wireless protocols for Wi-Fi and Bluetooth including support for wireless speakers and displays. This array of connectivity defined the soul of the device and shouted out point of view that the device was not a peripheral but a full computer.

Power adapters had become the bane of my existence as someone who used a variety of devices at home and work and travel. It was still too early to have a standard connector—Apple was still using the wide pin connector, which was painful and finnicky despite the super nice magnetic connector. GT created an ultra-skinny magnetic connector. I was, however, much more interested in the power brick. I could not stand the typical PC that had a three-foot cord to the PC, then a brick, then another three-foot cord to the wall. It turned out people in Japan disliked those too and Yodobashi Camera came to the rescue with an aftermarket model, a single 2 meter cable with a brick at one end with folding prongs. I stocked up on those. I really wanted GT to have an adapter with simple folding prongs. I wanted this so much I didn’t even bother to ask about non-US plugs. As a constant traveler, I was also cursed with hotel rooms with too few outlets. Back then I almost always had to unplug a lamp which usually involved moving furniture around. I often traveled with an after-market phone charger that had an extra pass-through outlet to charge a USB device. I needed this because PC USB ports did not charge when the PC went into standby, which I usually discovered at 6 a.m. local time.

Okay, so I meddled once after complaining one too many times.

One day RalfG invited me over to the studio and brought me through dozens of models for power adapters. I knew as soon as I got to the studio that Panos was managing me, but in a way that was entirely okay given how close we’d become. As we walked from 3-D model to model, I opined and envisioned about what it would be like in a hotel room. They explained to me all sorts of stuff about thermals, tolerances, UL standards, and even patents. One company had a patent on prongs that folded into power bricks! I picked the smallest adapter with folding prongs and a built-in USB charger. I like to think this was another iconic choice. It was not. It was merely useful. Ultimately, GT did not have a USB port on the charger but did have folding prongs. The second device had the USB port I wanted on a slightly higher-powered charger.

From the project start we had been considering a second device. Early on, Mike had suggested to me that the team could build a desktop all-in-one using a screen with the next generation touch panel technology from the Surface table running an Intel processor. This device was the concept for a follow-on or successor to Surface table. It was a beautiful device. The prototype followed the same lines and hinge as would appear much later after many iterations as the Surface Studio all-in-one.

We really wanted to showcase desktop productivity, especially the all-in-one form factor, which had no presence with PCs. Apple made all-in-one Macs as their desktop Mac and those, as with iPads and MacBook Air, made their way into every movie, high-end retailer, and boutique office setting. An all-in-one with the GT premium aesthetic could put Windows in those spots too.

PC makers finally decided to wed the displays they were making with the laptop parts they made to create all-in-ones competitive with Apple iMac. Windows 7 saw a broad introduction of low-cost and reasonably performant all-in-ones, which was great to see.

The arrival of PC all-in-ones and the reality that the next generation screen technology was not ready, especially in a large size and at scale led to us abandoning the all-in-one product. A good deal of work had gone into the basics of developing an Intel PC, which presented us with an opportunity.

Standing around the now defunct all-in-one prototype, we discussed the idea of creating an Intel-based GT with the Surface BOM, or a derivative of it. At first, I thought this was entirely against the spirit of the project as it would simply compete with our OEM partners and cause more of a rift than not. At the same time, I’d been so happy with the progress we were making while equally aware of the limitations customers would see in ARM-based Surface. The early prototype tablets like the \build Samsung had the promise of being great tablets for using and testing Windows 8 apps while also working as platforms to build those apps or use any existing x86 Windows development tools.

Would the existence of a Microsoft-branded Intel device help address customer concerns, or would it create more confusion? Would OEMs see such a device as an inspiration, or would it further annoy them? What would Intel think?

I had many concerns about forging ahead with an Intel-based PC coming from Microsoft. It did not seem prudent. Frankly, it felt more like an extra poke at OEMs when our main goals were embodied in the ARM-based device. 

What could we offer uniquely as a stage for Windows 8? The Ultrabook investments were ongoing, but Intel’s specifications called for them to be large-screen devices for Intel-specific channel strategies. Everything that was a tablet or Netbook-like computer, less than Ultrabooks, on Intel was running low end chips that had mediocre performance on Windows. What if we mated mainstream laptop chips, Intel Core, to the GT form factor? We would have an ultraportable Intel-based Windows 8 device in an ultra-convenient Netbook-sized package. There was nothing like it in market, an ultra-portable Ultrabook.

The team took this as an opportunity to up-level all the specifications from GT. More of everything including a full HD screen, faster USB, support for dual monitors, bigger battery, more memory, and storage, and by default it would use the Type Cover with mechanical keys. We were super confident in the Touch Cover, but we saw in early usage that it did not have the throughput for a full-time professional user on this professional-oriented device. We weren’t going to be religious about it and quickly adapted.

The up-leveled GT could in fact contribute something that would help enormously to smooth over the risk of building hardware. We could offer a super high-quality pen experience, exactly what BillG wanted. Since the device would be more portable, resembling a typical paper notebook, lighter than scarcely available Tablet PCs, it might prove to be the ultimate pen-based notetaking device. The fact that we could focus an Intel SKU on the pen and handwriting and deliver a size that the OEMs were not considering provided a reasonable justification in favor of the device plan. The up-leveled GT filled an obvious gap in the whole ecosystem lineup.

Why did we not put a pen on GT? The power draw and thickness of another layer added by the current state-of-the-art pen digitizer would impact the competitiveness with iPad. Prioritizing the ARM device to be competitive with hardware specs of the iPad was a key factor, and a good tradeoff for us to make. Given my own reticence about the pen it was also an easy tradeoff, though I had to repeatedly defend it with BillG.

This was enough positive and with MikeAng we considered or gamed out how the OEMs would respond to an x86 device. Our main point was that the OEMs were focused on Ultrabooks in order to gain the advantages of Intel pricing. Our device would fall outside Ultrabook specs and thus prove more innovative and less part of the crowded Ultrabook space.

From my perspective, I viewed the device as an objection handler. It was a way to signal to the market that Windows 8, the x86 product, was well-suited to playing in this new world. Instead of a focus on ultra-mobile and all-day battery life, the focus was on power and all the needs of professionals in an ultra-mobile package. This reflected the early reviews of Windows 8 and the challenges we were having with the tablet narrative as put forth by Apple and reviewers.

GTX, or Montlake, was the code name for this second device. It looked bit like a puffed-up GT. Unlike GT, GTX would have all standard Windows PC components from the chipset to the BIOS to storage and RAM. It would also have a fan, and to mitigate that the team developed innovative cooling slots all around the device to keep internals from overheating or creating a hot-to-the-touch exterior. By virtue of it being Intel based, GTX had noise and heat that GT did not, and had about half the battery life more typical of the real-world numbers being seen for the first generation Ultrabooks, about 4-5 hours, compared to the 9+ hours we would see with GT.

GTX was about three months behind GT. I was clear that GT was the priority should trade-offs in any dimension be required. By the time we announced GT we would announce that GTX would be available three months later. For many that gap felt amateurish compared to the most recent Apple launches which had announced new devices on a Tuesday for sale on a Friday. As we know now, that was not the long-term norm for Apple nor was it how the iPad, Apple Watch, or other devices launched since. Nevertheless, Apple was doing everything right at the time so as agile as I thought we were, it was still less than was expected of us.

By the early spring of 2012, the manufacturing team started making small runs of test devices. It took months of work to scale up an assembly line, and it was expensive to make devices in any quantity for testing. Plus, everything was top secret. We had made about 1,000 test ARM devices partnering with NVIDIA, which were being used mostly in labs. They were also shared with teams across Microsoft contributing to WOA under the strictest security protocols. We never had enough of these test machines for everyone who might have wanted one to just check out, but we had enough to build the software across Windows, Developer, and Office. These devices cost over $1,000 each and were great to have but decidedly test machines. I was still using our NVIDIA test device, but, as with anyone who knew about GT, I was anxious.

Time was passing both slowly and quickly. We were closing in on finishing the Windows 8 software schedule, August 2012, which meant time was slow as each day fewer and fewer code changes were made. GT, however, was getting close to the point where it was time to commit to manufacturing. Spinning up a line means you want to ramp it to full capacity and not stop, otherwise we’d just be burning cash.

Surprisingly, there were absolutely no leaks. Even across Microsoft no one suspected anything, certainly not first-party hardware. With Windows 8 RTM approaching, the overall messaging for our reimagining point of view would start to diffuse through Microsoft. That meant talking about hardware. At a regularly scheduled Board Meeting I was asked to provide an update on Windows 8. As the code was essentially done and we had broad disclosure already there was little to do but assure the Board that we were on track and to discuss the worries we all collectively shared. The Board, however, had not yet seen the final GT hardware. In many previous meetings we discussed ARM and the strategy, including building first-party hardware, and I had previously shown demonstrations using the NVIDIA testing prototype. My sense was that the gravity of the decision to make first-party hardware had not really sunk in—the general view of “competing” with our OEM partners was still viewed as a challenge, especially because the Windows Phone Team had tried to create a phone but ended up partnering with Nokia, before later acquiring the company.

Whenever I spoke with the Board, I was always excited to show the progress of our product—so long as we were ready to, and it would not be over-promising or confusing. I would almost always drive a demo myself casually and without much fanfare—not only was this more authentic, but it also permitted a more casual interaction. With GT I did just that. At one point I just pulled it out of my bag and began to show it off just as we had been doing in incredibly limited ways. The pitch was easy because it was what we had aimed to build. Promise and deliver.

The Board and Steve, however, were much more focused on the big decision to sell first-party hardware and the bottom-line impact to the overall Microsoft P&L and earnings. I think the Board was still smarting from the Xbox write-off five years earlier. This ended up being the discussion, which seemed awkward to me as we had articulated this as the strategy from the start of the project. At the meeting, I was starting to get the feeling that I had in 2001 when we suddenly backtracked on the fully-baked Office.NET product plan. Only this time I felt I had laid all the groundwork and had discussed this at several other meetings. In hindsight, I suppose it was the reality of seeing the actual device and that we were delivering that made it all seem that much more real.

There was a tense discussion about the costs, especially the hundreds of millions of dollars to build out the final assembly capacity and the balance of creating enough units to keep the cost down by spreading the non-recurring costs over as many units as possible but not too many that we’d flood the market. One thing I had done specifically was not play any games with the budget or expense approval. Many projects at Microsoft spent a lot of money by spending a little bit at a time so as not to exceed an executive’s approval limit. My whole career, with the help of CollJ, I kept my spending authority artificially low. The spirit of my mentor JeffH was always looking over my shoulder reminding me it was Microsoft’s money and not mine to spend. This meant SteveB had to approve all the spending and we would have to have the discussion up front. At the end of the meeting when the Board asked the final approver question, there was no doubt in my mind. At the same time, strategically and from the perspective of how well we had executed there was no doubt. I was accountable for the result and was certain we should move forward and said as much. SteveB and I would have several more discussions, mostly centered on the price point and volume before he hit approve on the invoicing tool.

Before the first public showing, I wanted to show the device to PaulA. Paul was an early advocate of Microsoft building hardware and had several forays into leading-edge hardware through his Vulcan innovation company. I brought a device over to his office near the stadium used by the Seattle Seahawks. As someone who said he believed the old saying about those serious about software building hardware, Paul was excited to see what the team had accomplished. We spent most of the time in a deep discussion about hardware manufacturing, the bill of materials, and how Microsoft would scale the business. Paul’s Vulcan had built an ultra-portable PC powered by a novel Transmeta chip, which aimed to be Intel-compatible and consume less power. He was profoundly connected to the challenges of making hardware and at the same time agreed on the need to do so.

We set a date for a public unveiling in mid-June 2012. Just two weeks before at the All Things Digital Conference, we wanted to make sure one reporting team got a bit of a preview, only one team. I was using my Surface RT all the time, but not in any public places, and essentially handcuffing my messenger bag to me. D10, the 2012 conference, featured Apple’s Tim Cook, Mayor Michael Bloomberg, and a host of top-shelf guests, including SteveB, but no Windows demo, Phew.

We prepared to give a brief and private demo at the conference. We did not schedule any time but instead sort of set up a bit of an ambush outside on the terrace of the show’s green room. I messaged show co-host Walt Mossberg and asked if we could find 15 minutes between his on-stage interviews to show him and Katherine Boehret something very cool and secret. He was intrigued and they both of course agreed.

JulieLar and I would meet them and provide a surprise sneak peak of Surface. This was the first showing to anyone outside the Microsoft “tent” to see it. I grabbed my top-secret messenger bag from the hotel safe and met Julie and our audience of two backstage.

I offered a brief lead up, reminding them of the Windows 8 vision and goal of reimagining Windows from the chipset to the experience. I then took out Surface RT from my bag and said, “So, we built a computer.”

We showed them all the bells and whistles. And they were, at least by my account, speechless for a more than a brief moment. We just smiled while they took turns handling the fully functional sample.

Then they had a lot of questions. How much would it cost? What would the OEMs think? What was the battery life? When would it come to market?

Wait…would it even come to market? Katherine asked if it was a prototype or one of those PCs we built to encourage better PC design. We assured them that this was going to market as a first-party device.

Walt asked about one of his most significant issues with Windows PCs, the prevalence of crapware—that software added by PC makers to “enhance the value” by offering trials, advancing PC makers extra hardware (such as buttons to launch specific software), and other add-ons that you probably don’t want but significantly impact performance. On this topic I was extremely confident in answering. The whole point of creating Surface was to show the marketplace what the very best Windows experience could be. Little did I know just how difficult it would be to maintain this seemingly obvious point of differentiation.

While I had many fun moments described here in Hardcore Software, this surprise for a team I respected so much was one of the highlights. I wish I had a photo of the moment.

Invitations were later sent out for a mysterious event in Los Angeles with no hints of what to expect and little notice. The venue was a Hollywood production facility, Milk Studios. More than 200 press, financial, and industry guests made their way to the sound stage the morning of June 18, 2012. Some were still complaining about the short notice, the time, the location, and the lack of detail.

On stage, SteveB introduced Microsoft’s move to hardware, emphasizing that we would not let barriers between hardware and software prevent us from innovating and serving customers. At the end of his section, he unveiled Surface, not the keyboard or the kickstand or any specs. It was the CEO photo op lending all his gravitas to the event.

The stage was small but had been designed with a runway making an intimacy possible, which would become a hallmark of Surface events. The risers were beveled at 22 degrees, the same angle as the kickstand.

As I looked on, I stepped through the demo in my head for the 1,000th time. I had my Surface RT in hand with the screen polished as bright as a signal mirror, using a trick the team had of buffing with hand sanitizer and a microfiber cloth. As Steve was finishing, I touched the power button like I was supposed to and noticed the slightest little screen twitch. I brushed it off.

Rookie f*****g move.

I walked out on stage, as excited as I could ever possibly have imagined. About 10,000 people had worked on what was about to be shown for the very first time. Microsoft had never done such a surprise announcement before. We had never spoken to a room of people without pre-briefing them. Everyone was on edge.

Proudly, after making my way down the narrow runway, I announced Surface, a stage for Windows 8.

Two minutes and thirty-one seconds into the presentation, I was showing the new Internet Explorer. As I touched the screen for the audience, nothing was moving.

I muttered “Oops” and skipped backwards up the runway to the demo table and grabbed the backup. What felt like ten minutes was nine seconds, the longest nine seconds of any demo I had ever done. Who crashes the hardware during a reveal we practiced two dozen times flawlessly? Me. The guy on stage who should have swapped out the machine when the screen twitched. I could physically feel Mike, Panos, and the demo team backstage cringing.

Then the teleprompter went out too.

I kept going. In a bit of stage craft, I introduced the magnetic connector and a nice cover with smooth fabric on the outside, jokingly referred to as “Fine Northwest Polartec®” (it was just nylon), an innovation as well. I attached the cover with a memorable click—that great work of the mechanical team.

I posited to the audience: Why shouldn’t we do something more than cover the screen? To oohs and aahs, some gasps, and then applause, I extended the cover to reveal the full multitouch keyboard. At least that worked I thought.

The main reveals were complete. Phew. I made it through the crash. Backstage the team was despondent but also worried about how I would react. I was so disappointed in my failure to switch devices. That it happened at all still nags at me a decade later.

MikeAng then came on stage and flawlessly demonstrated the Intel-powered GTX, newly named Surface Pro, including writing on screen with a pen. I know that made a certain person back in Redmond very happy. Mike then introduced Panos. Panos detailed the team culture and design process: RalfG, StevieB, Pete Kyriacou (PeteK), Brett Ostrum (BrettO), and so many featured in a video Panos showed before a deep dive on all the technologies in the product.

We concluded and then opened up an area offstage where the press could experience the device. Despite my troubles on stage, letting them see the device in action proved the right call. It wasn’t a free for all, but it was something.

As the press and guests filed to the open area, one of the best in the business stopped me. By all accounts hyperventilating, Joanna Stern then of ABC News had just one question, “How did you keep it a secret?” I like to think we got more done than that, but that was a remarkable accomplishment for Microsoft. Some inside the company would be critical of the secrecy, specifically critical of me, but especially for Surface the nature of the business required it. The test hardware running essentially the same componentry was available to all participating teams.

With the product in hand, I started to use it more regularly. Just after the show I made it a point to use it on my regular places around headquarters. I had a photo snapped while eating lunch at Kidd Valley, my favorite protein and low-glycemic index spot right by campus.

One of the most useful traits of Surface running Windows RT was how even if something failed it took only a few seconds to restart the device and get back to where I left off, especially while under development. That made it more worry-free than a Windows laptop, as we expected and designed for. It was also so fast to resume from standby, and the Metro Mail app connected to Exchange was constantly fetching email even when in standby.

When AnandTech’s  Anand Lal Shimpi reviewed Surface at availability in an extraordinarily detailed and in-depth review of almost 9,000 words, the conclusion was just what we hoped to achieve.

I don't believe Surface is perfect, but it's a platform I can believe in. What I'm most excited about is to see what happens after a second or third rev of the design. [. . .]

If you're ok being an early adopter, and ok dealing with the fact that mobile devices are still being significantly revved every year, Surface is worth your consideration. If you've wanted a tablet that could begin to bridge the content consumption and productivity divide, Surface is it.

My first day of work I could not even get a PC the size and sound of a small refrigerator to connect to a network and run reliably. How far we’d come. I held in my hand a PC that could survive a 10-foot fall, rebooted in seconds, running the best software Microsoft ever created, weighed under 2 pounds travel weight, and easily connected everywhere. I could not be prouder of the work the team had done.

Over the summer as the product wound down we began planning for what would come next. This almost sounds crazy with all that was going on. We had created a machinery for delivering products. It was incredible to be part of. To think that just five years earlier the team, mostly the same team, had just struggled for six years to create one release and we created two releases on time, with none of the stress and strain relatively speaking, and with very high quality. We needed to keep moving.

Windows 8 was a 1.0 release. Perhaps by many accounts it was a 0.9 release, at least for the reimagined part. The Win32 and Intel part of the release was incredibly solid. It was indeed Windows 7 plus more. The team knew we had set out on a multi-year, even decade journey. I knew we would need to operate completely differently.

There would not be a Windows 9 next. In a very short time over the summer, we organized and began planning on “Windows Blue” which is a name I picked to signify it was not another big release. We had a lot of finishing to do. Microsoft never got anything right in the first version, or even the second. We needed to move the team to think about acting with precision in a timely manner so we could, in Microspeak, crank out a release every year.

We created a vision and a schedule for a release to finish in one year. The entire goal of the release was to refine everything from RTM. Refine the platform. Refine the user experience. Refine the core built-in applications and service connections such as SkyDrive and Outlook.com. Decide on a long-term Surface roadmap. The list was very long. Above all we’d fix the things that were so obviously not complete, such as requiring a trip to the desktop to use files or change a PC setting. And yes, we would pay close attention to the reviews as they came out. Though I can say even today, we would not have planned on a full retreat, a redo, or a reset.

Microsoft takes three versions to get things right. We grew up with that reality. The world was moving ahead with or without us. We were determined.

On August 2, 2012, Windows 8 went to manufacturing. We finished 120 days late from our original schedule. The Surface assembly line went into operation. We had a fantastic event on campus. Once again the administrative assistant team outdid themselves.

August was always a busy month at Microsoft. The field sales organization held their annual rally/strategic coordination meeting with almost all of the global staff. Microsoft usually held a company meeting around that time. There was also a Wall Street event or shareholder meeting. These events are the rhythm of a large corporation.

August/September 2012 was also when the company came together to get behind Windows 8. For all the concerns and issues raised as the product progressed, there was an electricity and a sense of excitement. People had seen the doldrums for the past decade. People had seen PC numbers declining. People had seen Microsoft lose in mobile, fall behind Linux, and not yet have a role in cloud computing. While the financials the company was putting up were fantastic by any measure, the buzz was gone. More than a buzz, the company wasn’t a leader. The company wasn’t, for lack of a better word, relevant. We all believed, and genuinely hoped, Windows 8 would offer a chance to be the industry leader again, not just the biggest company, but the most relevant company.

At both the global sales meeting and the company meeting we presented Windows 8 and Surface. The global sales meeting told the story of Windows 8 and why it could win. The field of course were worried about the missing Start menu. I shared some usage data comparing how the Start screen compared to the Start menu. Rather than trying to jam all the functionality into a tiny corner of the screen we showed how people saw the information from Live tiles and made full use of the screen, all maintaining familiar positional memory and muscle memory. It was just one point but the kind of message you send to the field that says, “we heard” and here’s what we consider to be the case. It was not spin. It was what we believed.

What I remember though was not apologizing for the Start screen, but the absolutely incredible and over-the-top reception just when I walked out on stage. I have never felt so much gratitude from 30,000 people all at once. I got to stand there, head bowing, absorbing that gratitude for the team back in Redmond. I stood on stage to applause for nearly a full minute. Humbling doesn’t begin to describe the feeling. I couldn’t say it enough at the time, but I can once again say thank you to the global field team for that welcome and appreciation on behalf of the team. It was so genuine, so unexpected, and just so wonderful.

Just a week later we gathered at the Key Arena in Seattle for the company meeting. While much of the message was the same as MGX, this was headquarters and that means it was mostly the product development groups and company staff. They wanted to see the long version of everything. We did everything to deliver. We had the biggest hardware lineup of Windows 8 PCs MikeAng had ever assembled. PanosP came out and “debuted” Surface once again. Tami Reller walked everyone through all we had done to bring the products to market. We had an amazing and relaxed time. Once again, the reception was just over the top. It was amazing.

We had one more surprise even after all of this. One of the many great joys of being part of creating Surface was the chance to work with a creative team in Hollywood who would bring Surface to television and web advertising. The team was headed by movie producer Andrew Panay, brother of Panos. He assembled a team of creative people to write, visualize, and direct the television spots, the sound stage for the launch event, a worldwide street art campaign, and a plethora of other materials. Andrew was already a seasoned film producer (Wedding Crashers), and their early ideas and pitch made it easy to decide to collaborate with the team on a whole new approach. Andrew, with his keen eye for talent, brought in the director Jon M. Chu to create the marquee television debut for Surface, called Movement. The commercial featured the iconic “Click-In” sound, the hinge action, colorful touch covers, and a troupe of talented au courant dancers. Astute viewers and frequent travelers would later recognize some of the dancers from another well-known spot from Chu, the Virgin Atlantic safety video. Chu would later direct G.I. Joe: Retaliation, Crazy Rich Asians, and In the Heights among his dozens of credits.

We debuted the spot not only for all of Microsoft HQ, but for SteveB as well. Steve did not like surprises, but I had a strong feeling he would love this commercial. It was high energy like Steve, and it sold hard on the attributes of Surface. It was cool. It was hip. It was, well, everything Microsoft was not.

Steve, MikeAng, Tami Reller, Panos, JulieLar, and some others stood by the green room looking on to the full venue of 20,000 or so employees as the lights went down and the commercial debuted. The arena and SteveB went bonkers. Score another awkward high-five moment for me and everyone within a 20-foot radius. The commercial was a moment. The campaign went on to win awards in the advertising world as well, something that Microsoft had not accomplished in ages.

Both events really demonstrated that Microsoft’s headquarters personnel were excited, optimistic, supportive, and a great many were direct contributors. Certainly, we had not experienced anything like that in the past decade of Microsoft.

For the October launch, the Microsoft Store team secured New York City’s Times Square, for a Surface and Windows 8 block party celebrating the opening of the new flagship Microsoft Store. The launch event itself was in an enormous hall downtown. It was filled to capacity. For me personally it would be mostly anticlimactic like all launch events usually were.

Walking around Times Square that night among thousands of people at our own party was crazy. But my mind was not there. I was thinking about what was going to appear with reviews and more. The plan was to only sell Surface RT in Microsoft stores. I was thinking about how we would sell all the Surface devices we built. Our plan was to sell exclusively through only the few Microsoft Stores. I did the math on that, and it was scary. I worried about the aggressive pricing of $499, or $599 with Touch Cover. I was thinking about the Start screen. The desktop. The App Store. The Windows team. Windows Blue. All those people who had done so much, given so much, done such a fantastic job.

I loved this company. I was also exhausted.

About a year before that big launch, I wrote an email that I would deliver on my last day of work at Microsoft. Unsent then, I knew it would go out in the not-far-off future. I stored it in my email drafts folder and held onto a printed copy, undated and unsigned, in an envelope in my Windows logo Timbuk2 bag along with my Surface tablet and my 16 pages of printouts of the vision, staffing, budgets, product reviews, compete info, and the dev schedule that I always had with me. I told nobody about that letter.

I wrote it after a big debate at a cross-division executive meeting over the degree to which Windows 8 would be designed to sell other parts of Microsoft—how many of those colorful Metro tiles would be pushed to customers, not because each was a good product choice but because we wanted to sell them something else. I was being excessively principled, as I was known to be, believing in the primacy of the customer experience. I believed others were being too flippant with our role as a platform provider and a significant reason why we could make a better PC for customers. “It is not the user’s PC, it is our PC,” one exec opined. “Sure, it is crapware, but at least it is our crapware” and “We fought the DOJ so we could own the screen” others chimed in.

Product cycles are emotional roller coasters. Anyone who has ever gone through one knows there are dozens of times when it just gets to be too much. The more seasoned one becomes the more one knows never to do anything precipitously. I knew it was time for a change. I intended to get through the launch. The plans were in place.

I was spent.

Equally clear to me was that the company was spent too. Microsoft needed to do things differently, without me.

On to 108. Epilogue: The End of the PC Revolution

The planning for Windows 8 was moving right along. But something wasn’t right as we wrapped up Windows 7 activities at CES 2010. It was looking more and more like the plans and the way the ecosystem might rally around them would yield a watered-down result—it would be Windows and a bunch of features, or perhaps irreconcilable bloat. The way the ecosystem responded to touch support in Windows 7 concerned me. How do we avoid the risk of a plan that did too much yet not enough? Oh, and Apple scheduled a “Special Event” for January 27, 2010, just weeks after a concerning CES.

Back to 097. A Plan for a Changing World [Ch. XIV]

In early January 2010, I was walking around the show floor at CES the evening before opening day as I had routinely done over the years. CES 2010 was a mad rush to build a giant city of 2,500 booths only to be torn down in 4 days. This walk-through gave me a good feel for the booths and placement of demonstrations. It was just two months after the launch of Windows 7. Walking around I made a list of the key OEM booths to scope out first thing in the morning. It wasn’t scientific but visiting a booth had always been an interesting barometer and sanity check for me compared to in-person executive briefings. Later in the week I would systematically walk most of the show and write a detailed report. The next morning, along with the giant crowds, I made my way through a few dozen booths with the latest Designed for Windows 7 PCs mixed in among the onslaught of 3D-television controlled by waving your hands which garnered much of the show’s buzz.

The introduction of touch screens was a major push for Windows 7 and there was genuine excitement among the OEMs to offer touch as an option, though few, okay none, thought it would be a broadly accepted choice. Touch added significantly to the price. With two relatively small suppliers for the hardware, OEMs were not anxious to make a bet across their product line. TReller, the new CMO and CFO for Windows, made a good decision to provide strategic capital to one component maker to ensure Dell would make such a bet.

There were touch models from most every PC maker, but they were expensive—most were more than $2,500 when the typical laptop was sub-$1,000. For the OEMs this was by design. If a buyer wanted touch there was an opportunity to sell a high-end, high-margin, low-volume device. OEMs had been telling us for months that this was going to be the case, but it was still disappointing.

Taking advantage of Windows 7, and wholeheartedly, were a sea of Windows 7 “slates” all based on the same design from the combination of Intel and Pegatron, an ODM. These slates were essentially netbooks without keyboards. They fit the new Intel definition previously described—MID or mobile internet device. They were theoretically built as consumption-oriented companions to a PC. They were shown reading online books, listening to music, and watching movies, though not particularly high resolution or streaming given the meager hardware capabilities. All of them were relatively small and low-resolution screens. To further emphasize the Intel perspective, they also launched AppUp for Windows XP and Windows 7, a developer program and early content store designed to support rights management and in-app purchase as one might use for books and games.

The buzziest slate was from Lenovo, not a product announcement, but a prototype model kept behind glass at the private Lenovo booth located in a Venetian Hotel restaurant. The “hybrid slate” Lenovo U1 was a 11” notebook that could also be separated from the keyboard and used as both a laptop and a slate. As a laptop, the Windows 7 PC used a low-power Intel chipset, a notch slightly above a netbook. Detached as a slate, the device ran a custom operating system they named Lenovo Skylight based on Linux running on a Qualcomm Snapdragon chipset. The combination weighed almost 4lbs. The Linux tablet separated from the Windows-based keyboard PC somewhat like the saucer section of the Starship Enterprise separated from the main ship. Lenovo built software to sync some small amount of activity between the two built-in computers, such as synchronizing bookmarks and some files. Economically, two complete computers would not be the ideal way to go, bringing the cost to $1000. Strategically for Microsoft this was irritating.

Nvidia, primarily known for its graphics cards used by gamers, was always an interesting booth. Nvidia was really struggling through the recession and would finish 2010 with revenue of $3.3 billion and a loss of $60 million. As it would turn out it was also a transformative year for the company, and for one of the most legendary founders in all of the PC era, Jensen Huang. To put Nvidia in context, my very first meeting with Intel when I joined the Windows team in 2006 was about graphics, because of the Vista Capable fiasco. Intel was digging their heels in favoring integrated graphics and was not at all worried about how their capabilities were so far behind what Nvidia and ATI, another graphics card maker, were delivering, which Intel viewed as mostly about games. The rub was that AMD, Intel’s archrival, had just acquired ATI for $5.4 billion making a huge bet on discrete (non-integrated) graphics, which was what Nvidia focused on. Intel seemed to believe that the whole issue of graphics would go away as OEMs would simply accept inferior graphics from Intel because it was cheaper and easier while Intel improved integrated graphics over time, albeit slowly. A classic bundling strategy of “a tie is a win” that would turn out to be fatal for Intel and an enormous opportunity for ATI/AMD, Nvidia, and Apple. Intel could have acquired Nvidia at the time for perhaps $10-12B if that was at all possible.

In their booth Nvidia was showing off how they could add their graphics capabilities to the Intel ATOM processor and dramatically speed it up. Recall, ATOM chips struggled to even run full screen video at netbook screen resolutions. With Nvidia ION it was possible to run flawless HD video. Nvidia made this all clear in a “Netbook Nutrition Facts” label that they affixed to netbooks running Nvidia graphics. This was a shot across the bow at Intel, but Nvidia had an uphill battle to unseat bundled graphics from Intel. Nevertheless, we were acutely aware of the strong technical merits of Nvidia’s approach, Jensen’s incredible drive, and the needs of Windows customers. This will prove critically important in the next chapter as we further work on non-Intel processors.

More disappointing was how the OEMs chose to demonstrate touch capabilities in Windows 7. We provided OEMs with a suite of touch-centric applications, such as those demonstrated a year earlier—mapping, games, screen savers, and drawing, for example. We even named it Windows Touch Pack. The OEMs wanted to differentiate their touch PCs with different software and viewed the Touch Pack we provided as lame. Touch had become wildly popular in such a short time because of the iPhone, and the iPhone was a consumer device used for social interaction, consumption of media, and games.

With that frame of reference, the OEMs wanted to show scenarios that were more like an iPhone. The OEMs were going to do what they did, which was to create unique software to show off their PCs. This is just what many in the industry called crapware or, as Walt Mossberg coined in his column, craplets. To the OEMs this was a value add and important differentiation. Worst of all, there was no interest from independent software makers who had dedicated few, if any, resources to Win32 product updates, let alone updates specific to touch that was exclusive to the new Windows 7. We never intended to support Windows 7 touch on earlier versions of Windows—something developers ask of every new Windows API. This compatibility technique we often relied on but was a key contributor to Windows PC fragility and flakiness, also referred to colloquially as DLL Hell as previously described.

The overall result: Windows 7 provided no impetus for third party-developers, and we failed to muster meaningful third-party support for any new features, including touch.

What I saw was a series of new OEM apps taking a common approach. These apps could be called shells in typical Microsoft vernacular, an app for launching other apps—the Start menu, taskbar, and file explorer in Windows constitute the shell. In this case, these new shells were usually full-screen apps that had big buttons across the top to launch different programs: Browsing, Video, Music, Photos, and YouTube. These touch-friendly shells did not do much other than launch a program for each scenario, the browser, or simply a file explorer. For example, if Music was chosen then a music player, created by the OEM or chosen because of a payment for placement, would launch to play music files stored on or downloaded to a PC. The use of large touch buttons was thought to give the PC user interface a consumer feel. The browser used part of Internet Explorer but not the whole thing, just the HTML rendering component; for example, it did not include Favorites or Bookmarks usually considered part of a browser. This software, as well intentioned as it was, would fall in the crapware category. This was expected, but still disappointing.

In booths with mainstream laptops we were offered a glimpse into the changing customer views of what made a good laptop. The Windows 7 launch was just a short time ago, so most laptops had incremental updates, primarily with the new version of Windows and perhaps a slight bump in specs. Some show attendees picked up the laptops and grimaced at the weight and thickness—these machines were hardly slick. It had been two full years since the introduction of the MacBook Air and the PC industry still did not have a mainstream Windows PC that fit in the famous yellow envelope wielded on stage by Steve Jobs. The prevalence of Wi-Fi in hotels and workplaces had changed the view that a work PC needed all the legacy ports present on Windows computers, and the fear of dongles had faded. Most every Windows PC still shipped with an optical drive, significantly increasing the height of the PC. Show-goers were openly commenting on the size, weight, and lack of portability of Windows PCs compared to the MacBook Air, which was what many were fully lusting for and based on the numbers had already switched to. For the two years since the MacBook Air launch the PC makers were pre-occupied with netbooks.

Apple broadened their product line with an even smaller and lighter MacBook Air using an 11.6” screen. They also added MacBook Pro models that were more in line with Windows PCs when it came to hardware, for example they included optical drives and discrete graphics. These laptops were expensive relative to mainstream business PCs running Windows. For example, the Dell XPS 15 debuted in 2010 was praised by the press, though only relative to other PCs. Compared to MacBooks, the Dell lost out for a variety of reasons including noise, keyboard feel, trackpad reliability, screen specs, and more. In reviewing the new Dell XPS, AnandTech, a highly regarded tech blog, said:

We've lamented the state of Windows laptops on numerous occasions; the formula is "tried and true", but that doesn't mean we like it…what we're left with is a matter of finding out who if anyone can make something that truly stands out from the crowd.

Of course, if we're talking about standing out from the crowd, one name almost immediately comes to mind: Apple. Love 'em or hate 'em, Apple has definitely put more time and energy into creating a compelling mobile experience.

If only there had been a Windows PC like MacBook Air for Windows 7. The closest we had was the low-volume and premium priced Sony VAIO Z that was new for 2010. This model featured a solid-state drive like the MacBook Air but was much heavier and larger than the famous envelope and could easily top $3000 when fully specified.

This knocked the wind out of me. I was happy that there were Windows 7 PCs at the show. But seeing the reaction to them only reinforced my feeling that the ecosystem was not well. I was hardly the first Windows executive to bemoan the lack of good hardware from partners, especially hardware that competed with Apple. Six years earlier, before the MacBook Air but also around CES, my predecessor JimAll sent a polemic, intentionally so, to BillG, Losing our way…in which he said, “I would buy a Mac today if I was not working at Microsoft.” As with many of these candid emails, this one made its way to an exhibit in a trial—it added nothing to the case, but such salacious mails that have little by way of legal implications are often used to attempt to gain leverage for settlements or stir emotions in a courtroom.

By the time the show ended, I wrote up my CES 2010 trip report as I had been doing since about 1992 or so. I loved (and still love) writing up these reports. No matter how down I was or how boring I thought the show was, I amped up the excitement as though it was the first CES I ever attended. I think it is important to do because otherwise the aging cynicism that seeps in—often seen in the press covering the event—makes it too easy to miss what might be a trend. My report ran 20 pages with photos and covered everything from PCs of all shapes and sizes to 3D television to iPhone accessories (lots of those.)

Not lost on everyone at the show was how Apple loomed over the show even though it had zero official presence. The vast majority of accessories located the edges of the Sands Exhibition Center were cases, docks, cables, and chargers for the iPhone. The camera area was filled with accessories to turn an iPhone into a production camera, such as a Steadicam for an iPhone that I even mocked in my report, oops that was way off base. The real news, however, was that the gossip of a forthcoming Apple tablet was everywhere. Nearly every news story about the show mentioned the one tablet that wasn’t there.

The week before CES in a classically Apple move, invites were sent to the press for an Apple Special Event to be held January 27, 2010. Leading up to the event, rumors swirled around how Apple would introduce a new touch computer and eventually converged on a 10” tablet to be based on iPhone OS. As we see today, the rumors were wildly off base, and only days before did the rumors mostly match the eventual reality.

After the first day of CES and our contribution to the main keynote by SteveB, that evening, I was in a mood and not a good one. I skipped yoga (at the awesome Vegas HOT! studio) and a previously planned celebratory team dinner that I arranged (!) to write a memo. Maybe memo isn’t the right word. It was another dense thought-piece from me, a 6000-word SteveSi special for sure. I think JulieLar, MikeAng, and ABurrows are still angry with me for missing that dinner.

I knew mainstream PCs were selling well. PCs from Dell, Acer, and HP met the sweet spot of the market, even among a marketplace overdosing on netbooks. People were over the moon for Windows 7. Office 2007 was doing quite well, despite not having compatibility mode, which had receded to a non-issue. Windows Server and associated products were going strong even though cloud computing had taken over Silicon Valley. Even Bing was showing signs of life six months or so into its rebranded journey, which had been managed by Satya Nadella (SatyaN) for the past few months. These all made for the bull case that Microsoft was making progress.

For customers and the tech industry, well, their attention had by and large moved to non-PC devices, Apple versus Google in phones, and the potential new tablet form factor. Microsoft launched the HTC HD2 running Windows Mobile 6.5 at CES. It was a well-received and valiant effort while Windows Phone 7 progress continued even in a decidedly iPhone world.

I remained paranoid, Microsoft paranoid. The dearth of premium PCs to compete with Apple and the lackluster success with touch gave me pause. Even though we had tried to right all the wrongs of introducing new hardware capabilities with new approaches, we had failed. There were no Windows 7 touch apps. There never would be. It was totally unclear if the industry would ever come together to create a MacBook Air, and even if it did it was unlikely to have the low cost, battery life, and quality over time of a Mac, even though it too was running on Intel. The browser platform consumed most all developer attention, with iPhone and then Android drawing developers from the browser. Apple’s App Store, 18 months old, had 140,000 apps up from 500 at launch, growing at a rate of 10 to 20 percent per month. To put that in perspective, during the Windows 7 beta I shared what I thought was an astoundingly large number—883,612 unique Windows applications seen across the massive beta test. By mid-2022, the Apple store had more than 3.4 million apps!

A sense of dread and worry came over me when I thought about our converging Windows 8 plans. It wasn’t a panic attack. It was more me wondering if I failed to give clear enough direction to the team about how big a bet we were willing to make on Windows 8. Was I too subtle, which I was definitely known to be, and gave too much room for the plan to turn into an “and” plan? An “and” plan means we would do everything we would have normally done, “and” also take into account all the new scenarios. Such plans are easy to sign up for because they don’t involve tradeoffs. At the same time, they force no decisions and lacked the constraints that yield a breakthrough design.

An “and” plan is what I saw across the CES show floor and even from Intel. It is a plan where the PC is a Windows PC and the new stuff, as though the new stuff is just another app one could take or leave. The extra launcher shells, content stores, and touch interface were bolted on the side of Windows and did not substantially alter the value proposition that was under so much pressure. Related, an “and” plan would also presume a traditional laptop or desktop PC as the primary tool, which itself would prove as limiting down the road as it was right then.

We needed a plan with a point of view about how computing would evolve. That point of view needed to be built upon the assumption that Win32 was not the future, or even the present. We needed to realize that an app and content store were of paramount importance. We needed to account for shifting customer needs in their computing device. We needed a plan that assumed the web is the defining force that changed computing and smartphones were themselves changing the web. We needed a plan that substantially changed the futzing, viruses, malware, and overall fragility of the PC so it acted more like a consumer electronics device. Most of all we needed a plan to engage developers in a new way to become interested Microsoft’s solution this opportunity, and not the solutions from Apple or Google.

We had the ingredients of a plan that might be adequate to quell the forces of disruption. Would executing such a plan be possible within the context of Microsoft? What does a plan look like when it also involves Windows itself?

The Windows 8 framing memo I wrote and the planning memo and process JulieLar had started contained the core of a point of view. We had set out to investigate “alternative hardware platforms,” potentially “distributing applications in a store,” designing “a modern touch experience,” and much more. As interesting and innovative and outside the box as these were, they all suffered the same risk. The problem was that for the team they were viewed as additions to Windows, as add-ons to the next release, as nice to have, an addition to. We had—and this is where the discomfort came from—created a classic strategy of the incumbent when faced with disruption. Our strategy treated the forces of disruption—in this case mobile hardware platforms, modern user interface, and the app ecosystem—as incremental innovations in addition to what we had. We were thinking that we would be competitive if we had Windows and other features.

This is not how disruption works.

Disruption, even as Christensen had outlined a decade earlier, is when the new products are difficult for the incumbent to comprehend and are a combination of inferior, less expensive, less featured, and less capable, but simultaneously viewed by customers as superior replacements.

As a team, we had faced this before, and I had spent the better part of three releases of Office fending off those claiming Office was being disrupted by inferior products built on Java, components, or browsers. In all those instances, I stuck to what I believed to be the case and defended, effectively, the status quo until we took the dual risks of expanding Office to rely on servers and services and then redefining the user experience for the product. Patience paid off then. The new technology threats were immature at best and a distraction at worst. 

What gave me the confidence to believe, as they say, this time was different? Was it my relative inexperience in Windows of just one release? Naivety? Arrogance? Was it envy of Apple or Steve Jobs?

It was none of those things.

It was simply the combination of the shortcomings I was seeing on the CES show floor and the fact that we’d all been using iPhones. We were not talking about a theoretical disruption where someday Java Office could have all the features people wanted in Office or that someday all the performance and UI issues would be squeezed out of the browser. The disruption had already happened, but the awareness of that was not shared equally by everyone involved.

To use a phrase attributed to William Gibson, “The future has arrived—it’s just not evenly distributed yet.”

Windows had 100% share of the Windows PC market and 92% share of the PC market. iPhone and Android (phones, and soon other form factors) were making a compelling case that the Windows position, as a percentage of computing, was declining. This decline in computing share would only accelerate.

In technology, if you are not growing then you are shrinking.

Holed up in my hotel room while the rest of the team had dinner, I banged away at my netbook keyboard a screed about the future of the web, apps, and how consumers would interact with content—and, importantly, ways in which the PC was deficient. I wrote 6,000-plus words, making the case that the iPhone was so good the internet was going to wrap itself around the phone rather than the phone becoming a browser for the existing internet—the web would tailor itself to the phone via apps. The experience of the web was not going to be like it previously had been—the iPhone was not going to deal with the desktop web and attempt to squeeze it on to the phone. The browser itself would become a form of legacy, “the 3270 terminal” of the internet era. The 3270 is the IBM model number for a mainframe terminal, replaced by PCs and applications.

As the office workers I gave first PCs to in 1985 did not realize, the business forms they filled out with their Selectric typewriters would change to work on a PC, not that the PC would get good at filling out carbon paper forms. A key part of a technology paradigm shift is that the shift is so significant that work changes to fit within the new tools and paradigm. There’s only a short time when people clamor for the new technology to feel and behave like the old.

I sent the memo to a few people that night. It received a bit of pushback because it felt like what we were already doing, only restated. I kept thinking this was how disruption really happened—teams went into denial, say “We got this” and believe adding a bit more would make the problem (or me) go away. IBM added a 3270 terminal emulator to the original PC for this reason, but that didn’t make people want a PC more or even use it; rather, they complained that the terminal seemed more difficult to use than a standard 3270 terminal. The PC I most frequently installed in the summer of 1985 was the IBM PC XT/3270, a hybrid mess if there ever was one.

It was clear we were falling into the trap of thinking incrementally when the world around us was not only changing but converging. The Windows team could no longer think of modern mobile platforms as distinct from the PC. People’s technology needs were being met by phones and were moving away from the PC.

This was not a call to turn the Windows PC into a phone. Rather this was a chance to up-level the PC, to embrace the web, embrace the app store model, embrace the shifting hardware platform and associated operating system changes, and embrace internet technologies for application development.

Most of all it was about “apps” except I couldn’t quite find the right word to use. Apple talking about “apps” for the past couple of years really bugged me. When I was in Office, we were the Applications (or Apps) group at Microsoft and an app was just the techie word for another more broadly used techie word, program. Word and Excel were apps and I was trying to define a new kind of app. App was such a weird word that even our own communications team didn’t think we should use it. Lacking a better word that night in the hotel, I called the memo “Stitching the Tailored Web” which was a horrible name and worse metaphor that took a lot of time for me to explain to people in person.

The key ingredients of this new world as I described it were a computing device, content store, and the tailored web itself. The computing device encompassed an interaction model for the device and for the new tailored apps. The content store is where users obtained apps created and distributed by developers along with consumable content such as movies, books, and music. The tailored web included the APIs used by developers and the OS platform, the new tools required by developers, as well as the core technologies of Internet Explorer used to create these applications and to browse the traditional web. All three came together to create what I described as the more “consumable internet.” I even had a fancy diagram I made with PowerPoint to illustrate the point.

My main point was that mobile phones were so huge and such a force that even the internet would change because of phones, the iPhone in particular. The notion of going to web sites would be viewed as quaint or legacy compared to apps. Today, there are plenty of people who do not take this point of view to be where we landed. There are those that use desktop PCs and live in a desktop browser and defiantly believe that to be the only way to get real work done. They use the highest-end PC tools such as Visual Studio, Excel, AutoCAD, and Adobe Premier and did not (and still do not) see phones or mobile software replacing those any time soon. Yet there is no disputing the vastness of mobile. Depending on the source (and country) about three-fourths of all web traffic is mobile-based, and about 90% of time spent on a mobile device is in an app. With this dramatic change in how the web was used, it is fair to say that the web became a component of mobile, not the other way around.  The browser-based Web 2.0 juggernaut would be subsumed by the smartphone.

The most dramatic expression of this would not happen for another 2 years. In the summer of 2012, Facebook, the posterchild of Web 2.0, dramatically pivoted from desktop browsing as the primary focus for the Facebook experience to the Facebook mobile app. That legendary pivot is often touted as both remarkable and responsible for the success and reach the company subsequently achieved.

The Tailored Web memo was much better delivered as a passionate call to the team. I waited until just after Apple’s scheduled event and later that same day held a meeting with our senior managers (the 100 or so group managers across all of Windows, each the leader of dev, test, pm for a feature team.) This was my favorite meeting and one I held at least quarterly going back to the late 1990s in Office.

Working with Julie, this became our own version of a pivot. It was not as much a pivot as simply a focusing effort. We still had about three months until the vision needed to be complete. This was by no means a major change. Rather it was relaxing the constraint that Windows 8 had to do two things, an “and” project, and it could focus on making sure we were set up for the future. The call to action was a call to prioritize the new over the legacy and interoperability between the legacy and new was not a priority. We wanted to break away from what was holding us back, a legacy neither of our primary competitors dealt with.

To the team, I wanted to make the case about apps by showing a series of screen shots of web sites versus Apps on various platforms and rhetorically asked “Which would you rather use?” Facebook on iPhone or a desktop? Crowded, ad-filled Bing on a desktop or the Bing search app on Windows Mobile? Outlook or the Mail app on iPhone? Reading a book in a browser or on a Kindle? A traffic map on a desktop browser or in the Microsoft Research SmartFlow traffic app?

The answer was obvious for all of us and remains obvious even today. The call to action was a doubling down on the developing planning themes “Defining a Modern PC Experience” and “Blending the best of the Web and Rich Client” with an emphasis on consumption and the internet. Specifically, it was “Windows, in all form factors, needs to be the best platform and experience to consume internet content while enabling ISVs and IHVs to build the software and hardware to do that.”

It was early in the potential for this disruption, and it was easy to point to thousands of tasks, features, scenarios, partners, business models, ecosystems, and more that required a PC as we knew it. Every situation is different, but it is that sort of defensiveness that prevented companies like Kodak, Blackberry, Blockbuster, and more from transitioning from one era to another.

It is easy to cycle from anxiety to calm in times like this. It was easy for me to look around and find affirmation of the “and” path we were on. Every stakeholder in the PC ecosystem would be far happier with incremental improvements to the status quo rather than embarking on huge changes with little known upside and significant immediate cost and potential downside. It would have been easy to fall back on the financial success we had and leave dealing with a technology shift for the future when technology specifics were clearer. It would, however, be too late as we now know. We would also lose the opportunity to lead a technology change that had just begun.

Worrying seemed abstract. Developing a clear point of view and executing on that seemed far more concrete and actionable.

The announcement from Apple and their tablet turned out to be far more than our poorly placed sources had led us to believe. What was it like in the halls of the Windows team on that day, January 27, 2010? It was not magical for us.

On to 099. The Magical iPad

Welcome to Chapter II. In short order I learn that Microsoft is way behind in the products I work on. BillG is really concerned about Steve Jobs NeXT computer. I move offices and find out I was part of a reorg.

This is a quick setup for a chapter about the creation of Microsoft Visual C++ 1.0.

Back to 007. Windows 3.0 Buzz

1990 to 1992: The big bet on Windows begins to pay off, but Microsoft struggles to win over developers who were enamored with object-oriented programming and C++ to more easily build GUI programs. Within Microsoft, differing cultures emerge between groups, and eventually define the company.

Microsoft was starting to lose its edge, even with Windows taking off.

The company got its start with languages and developer tools, but by the early 1990s tech enthusiasts and hobbyists were moving away from BASIC toward more advanced or professional languages and tools. Developers were being wooed by an exciting upstart, Borland International. Led by an energetic Frenchman, Philippe Kahn, Borland captured the hearts and minds of enthusiasts with a line of TurboTools that integrated a compiler, code editor, and debugger into one slick package. It was fast, really fast—fast the way that got under the skin of BillG. With support for both Pascal and C, and priced favorably, the products and the company became a favorite among independent developers. It also didn’t hurt that Borland expanded its product base to include a killer spreadsheet in Quattro Pro (get it, it came after Lotus 1-2-3) and Paradox, an industrial-strength database for MS-DOS.

Microsoft secured the professional end, particularly with Microsoft C 5.1, the product we were using for our ET++ experiments. The successor product, Microsoft C 6, re-upped the professional standard but was late (as everything was) and lacked the pizzazz of Borland. Microsoft responded to Borland with Quick C, a similarly integrated all-in-one product for MS-DOS. With C 6 a Windows version was added. Quick C was viewed as a defensive move. It was. We were focused on the high-end commercial developers, not the hobbyists or solo developers.

Being squeezed from the low end was one thing, but the high end was becoming problematic for Microsoft. Not only was the C 6 product late, but it was C and neither C++ nor object-oriented. This challenged Microsoft’s perceived leadership. In addition, Borland’s products performed better than the anticipated C 6. Internally, the teams, particularly Excel, began testing whether they could move to the Borland tools. This was especially noteworthy because it was coupled with a move away from Microsoft’s proprietary C-like language CSL.

As if this wasn’t enough, the growing importance of the graphical user interface would soon require a wholesale reinvention of tooling. Microsoft was way behind. Windows was our platform, but we lacked convincing and competitive tools. Squarely between Windows and OS/2, the Tools teams all but sat out developing new tools for GUI programming and focused simply on the programming language. The additional tools for developing the interface of menus and dialogs, as well as the complexities of making a GUI program, were left to the respective platform teams. These teams shipped tools in a software development kit (SDK), which was complete but not as polished a product as Borland sold.

This was my first experience with disruption, though that word was years away from business vocabulary. In 1990, we just called it competition. And losing.

While our marketing team talked all about revenue and market share, like any good business, in reality Tools was not really a business. An important lesson about Tools and platforms that I was learning in real-time was that a robust platform company invests (that is spends money on) Tools at an irrational level to support the platform. The reason Borland could have a Tools business was because it was spending much less than Microsoft, and so could be profitable. Microsoft was spending more money and making a worse product. In other words, I was part of an irrational investment that wasn’t paying off. We were a poor business, and we were failing at building tools professionals wanted to use. Losing control of the Tools was akin to losing control of the platform.

Apple invested heavily in tools for the Macintosh, just like a winning platform should. There was also a vibrant market for many different languages and tools for creating apps for the unique graphical platform. This was well known within Microsoft because so many of the Apps engineers got their start writing Mac software in college, including me. There was always a sense of envy regarding the elegance of building GUI applications with a GUI toolset on Macintosh—bootstrapping was when programming tools created themselves. Historically, programmers viewed bootstrapping as an important, if mostly symbolic, step in developing a platform. Microsoft was far from bootstrapped, as it was still using Xenix and OS/2 to develop for MS-DOS and Windows. Worse, most developers at Microsoft thought this was a superior way to build software. All that marketing we were doing explaining that a GUI was easier to use had the effect of telling programmers that GUI was how lesser programmers worked. Worse, that is what our own marketing team was telling us about our own customers.

Besides, even with those great tools and a lead of several years, Apple was still far behind in PC sales. Steve Jobs was no longer at Apple and his new company, NeXT, was top of mind for BillG and the industry. As successful as Windows was for Microsoft, there was a strong belief that no single system would dominate. NeXT was new. NeXT was led by Steve Jobs. And most of all, the product was clearly innovative and setting the bar by which BillG would judge our product and technology.

Steve Jobs at an event in San Francisco launching updated NeXT computers and tools. A key part of this presentation that caught Microsoft’s attention was the presence of Lotus CEO Jim Manzi describing how they built a unique new spreadsheet product on NeXT, called Improv. “We would not have been able to invent such a revolutionary new product on any other platform” definitely gets your attention.

Microsoft had to do something, something about Borland and NeXT.

Moving offices at Microsoft was a constant. It was time for our first move, to new buildings that were even bigger than the big double-X layouts. These were the new buildings for Apps: 16, 17, and 18. Rather than low slung grey these new buildings were 3 stories of glass and brick and featured their own courtyard and fountain, which would be the site of our future ship parties. The buildings had huge atriums of open space and skylights while still maintaining the sacred 9x12 foot single office with a door. The three buildings were connected by an enclosed tube system that looked like a Habitrail. The uniqueness of these tubes meant that they were frequently used for photo shoots and videos.

The night before a move (my first of a dozen I would experience), MSMOVE dropped off a stack of boxes, a roll of tape, and a move form. A paper form was used to draw placement of the huge oak desk, return, guest chair, and developer-issued folding table. The movers showed up at the end of the day, unplugged phones and computers, and put everything on carts and trucked them to the new office. Unpacking could happen 12 hours later. The MSPHONE person eventually showed up to make sure the newly hooked up phone worked with your assigned number.

This was going on every night in every building at Microsoft. It was like a giant nine-square puzzle, where at any given time an entire group existed in the moving trucks in the parking lot because there was never enough space for everyone, even with the new buildings.

My new office was right around the corner from a connecting tube and for the first few months I could hear the door slamming every time someone entered the tube. There was a design defect that turned the tube into a wind tunnel, making the door difficult to open while also forcefully closing it with high-speed wind. Eventually some vents were added solving this problem.

As with every hallway of developers, there was a deep sense of personalization that came with the private office space we were each allotted. Since most people were not yet grown-ups, there were no family photos, or traditional memorabilia. Rather, offices were filled with some form of personal collection representing youth. I saw a collection of vintage car license plates, a wall of album covers, and a beer can collection sitting on a custom shelf high up on the wall. And most every office featured a pyramid of used beverage containers, usually Mountain Dew or the ever-present Washington apple juice, and the occasional chocolate milk containers (the ones from elementary school).

Next to each door, there was a full-length window (a relite), about one foot wide, made with that type of institutional glass from high school with wires inside that gave a sense of involuntary confinement. While designed to let light in form outside, it often served as an outward-facing sign of personal expression. Usually the first thing decorated in a new office, relites were covered in stickers, signs, news articles, Dilbert comics, jokes, and bad code examples or bug burn down charts, all expected to be updated with some frequency.

Like the first day of high school, people wanted to stand out, but they didn’t want to stand out. I nervously attached a few items to my glass, mostly American tourist-trap kitsch from my recent cross-country drive: a Wall Drug sticker, a Corn Palace postcard from South Dakota, and a copy of Elvis Presley’s death certificate I had acquired in Memphis. Road and street signs were popular, and my “Slow Children At Play” road sign also followed me around for a decade.

I didn’t realize it but our ET++ team had just been reorganized. Not only did I move offices, but I found myself on a new and bigger team with a clarified mission.

On to 009: Password is ‘NeXTStep’

A continued thank you to subscribers for the comments and discussion we’re having. It is an amazing part of writing a book this way that we can share in additional memories and reflect on experiences we have all had. This section marks the end of “Chapter I” and so please feel free to drop me a line with feedback or thoughts on how things are going. By all means share this with friends as we’re about to start diving into product development—and I’ll be writing code finally.

Back to 006. Zero Defects

With spring 1990 approaching, the buzz for Windows 3.0 was becoming deafening within the halls of Microsoft. One of the most exciting things was seeing the visual appearance of the product. Windows 1.0 and 2.0 were, to put it kindly, garish, or at best excessively blocky and utilitarian. Much of this was out of necessity as computer monitors only displayed about the equivalent number of pixels of one app icon on today’s iPhone and only had access to 16 colors (or no colors at all). Windows 3.0 also added overlapping windows like on Macintosh which made a huge difference in how the product felt.

Windows 3.0 was the first integrated release of Windows, meaning sold along with MS-DOS on a new PC. The notion that Windows was an “operating environment” added on to MS-DOS was giving way to Windows the operating system. While seemingly arcane technical jargon, the change in vocabulary was also a change in how the product was sold to computer makers and how software developers should think about Windows. Windows coming with a new PC meant it was no longer a question developers would need to ponder when deciding how to write software. The landscape was changing from IBM-compatible PCs to Windows-compatible PCs. This was huge.

To emphasize this point, the company scheduled a major (for Microsoft) press event in New York in May 1990. What was months earlier a side project was now front and center for the whole industry. While Microsoft had previously held launch events at trade shows, this was one of the earliest examples (and certainly the most expensive) of a major event for a single Microsoft product.

This event was going to be monumental for the entire company, except perhaps for the people working on OS/2. We were all using OS/2 every day as a main development machine, and many people were working hard but struggling to get Word and Excel working on it. But it was also viewed with a good deal of skepticism internally. Much of this was because of the stories that made their way over to Apps from Systems about working with IBM and the disconnect between engineering cultures, but also our own experience in the poor quality and difficulty in using the product.

There were many stories of IBM’s dysfunction that were common knowledge. IBM used to measure their programmers on lines of code produced; more lines meant higher productivity. Except Microsoft believed fewer lines of code to create the same feature was better. IBM thought Microsoft engineers were less productive while Microsoft thought IBM engineers produced bloated code. Microsoft was young and confident. IBM was…experienced.

While IBM was a few decades into writing software, their experience was rooted in making highly custom and highly reliable mainframe software, over very long periods of time. The reality was Microsoft was at peak productivity for new lines of code being written for PCs, but we were still very early in figuring out a reproducible process for releasing products and of course we continued to have quality problems and scheduling missteps. BillG even noted our challenges in releasing software on time as he walked on stage at the event, saying that today Microsoft is announcing the completion of Windows 3.0 and had the product not been done hosting such a big event would have been a bit of an “extravagant way to announce a delay in the schedule.”

The deep tension between Microsoft and IBM was hardly visible to us and, frankly, the industry was geared toward a world with many competing computing platforms. Nearly every article about Windows viewed the product as a stepping stone to the more modern OS/2 that would shed its connection to 8-bit MS-DOS. No one was anticipating Windows 3.0 becoming a de facto standard, certainly no one at our daily lunch table. We increasingly knew Windows 3.0 was an exciting product, but we also knew that Microsoft had committed to a joint development project with IBM, a company perhaps 100 times the size of Microsoft. None of us really had a clue just how tense the relationship between Microsoft and IBM was becoming while we continued to find ways to absorb the complexities of OS/2, Macintosh, and now Windows 3.0.

Along with Windows 3.0, Microsoft demonstrated a new release of Excel for Windows, Excel 3.0, an updated Word version 1.1, and the first version of PowerPoint for Windows version 2.0. The PC software industry was a version number machine—literally everything was a 1.0 or a 5.0, or debating whether a product was a .1 or a .5. It was the source of marketing games such as “big upgrade in version 2.1” and notorious for cynicism such as “avoid a 1.0” or “wait for the ‘a’ release.” Microsoft was a varsity player in this world of confusing version numbers (and product names), and we were just getting started.

Those updates were just the software from Microsoft. The platform marketing team, which in the software industry had become known as evangelism, a term pioneered by Apple, had successfully wooed hundreds of independent software vendors to show off their latest products on Windows. The Windows 3.0 event included mentions of many of the biggest names of the day including Corel, Aldus, Iris (makers of what would eventually become Lotus Notes), and Crosstalk. Noticeably absent with Windows products were WordPerfect, Ashton-Tate, and Lotus, the leading applications for MS-DOS.

Also at the ready were hundreds of hardware companies ready to deliver a range of fully compatible computer systems, components, and peripherals. While often overlooked, the ability to have hardware and the required software to make printers, displays, and a host of accessories work with Windows was an achievement equal in magnitude to applications.

Windows 3.0 seemed to have everything that OS/2 did not. There were compatible PCs. There were new applications. There were supporting peripherals. It had the pricing and distribution too. The fact that it ran on as little as one megabyte of memory (though really two was better) and also ran all existing MS-DOS applications even better than they ran before made for an incredibly compelling launch.

Windows 3.0 represented a step-function change in the PC. The clunky world of obscure commands and text-based screens would give way to colorful overlapping windows and a mouse, something that Macintosh had for the past five years. While the PC was catching up in capabilities it was still outselling Macintosh by more than fifteen to one. What the PC lacked in ease of use and elegance, it more than made up for in lower cost hardware, a much broader base of support from software makers, and a wide array of peripherals.

The launch event was satellite broadcast to conference rooms around campus. For most of us, the idea of seeing Microsoft on a video stream like this was kind of crazy. While certainly the company was one of the biggest and brightest stars around, the world of technology and software was still a relative blip in the economy. Bill Gates was hardly a household name. About 15 percent of US households owned a personal computer in 1989, and worldwide about 17 million PC compatibles were sold (1989 was the first year more than one million Macintosh computers were sold—the Macintosh always had an outsized influence, and it’s worth noting that Word and Excel were selling to most of those Macintoshes, which was not the case for Microsoft apps on PC compatibles).

The trade press, which we devoured every week in tabloid sized print magazines at the library (senior executives were permitted to have their own subscriptions, but regular folks had to make their way to the library), covered every development of Windows and OS/2 as though both operating systems were inevitable.

Since we knew the Systems teams were hard at work at both, we had no other source of information to counter the narrative in the trade press. It is interesting to consider how much we were influenced by what we read in trade press when there was little else for us to go on. Little did we know that BillG, and the executive teams, were deep in an enormously complex “divorce.” The company was on the verge of moving away from a partnership with IBM and would go it alone with Windows. This would not happen quickly.

In fact, in the months leading up to the launch event, Microsoft and IBM famously issued a joint communication emphasizing that long term their collective efforts are squarely on OS/2 and urged independent developers to follow. When we read about this in the trade press it seemed exactly like what we were doing as Microsoft followed this advice too. Many of my friends were working super hard on OS/2 versions of Word and Excel. We were working hard to make ET++ work on OS/2 as well. At the same time, making applications work for Windows was ongoing, and going very well. The work on OS/2 was definitely not fake as many would say in the years to come, but it also wasn’t progressing. Everything was confusing and messy to those of us just doing our jobs.

Windows launched in May 1990 and sold four million copies in the first year. That was all the market proof the company needed to know that Windows was the future. The complex partnership yielding a complex OS/2 product was also looking less and less strategic. The fact that progress on the product was slow and the rapid sales of Windows were attracting all the interest of third-party developers, made the positives of OS/2 mostly theoretical. Who needs a better file system if all the interesting applications are on Windows?

In hindsight, that day in May was somewhat surreal. I had not yet even started to internalize the scale of Microsoft or its potential. To me the company still seemed so approachable. The Microsoft I knew was not much larger than my high school and I felt like I knew all the people in Apps. In reality, we were doubling in size every year.

A few weeks after Windows 3.0 launched, Microsoft closed the books on fiscal year 1990. It would be the first year the company would report sales over one billion dollars, $1.18 billion to be precise. That was almost double the revenue of either Lotus of WordPerfect, the two largest software companies. Microsoft became the first pure play PC software company with more than one billion dollars in sales.

The inevitability of Windows was starting to sink in over the summer. BillG always used to tell the interns, and by now we had perhaps 100 that summer, that he worried Seattle summers were so nice that people would not work. In fact, there was an incredible amount of energy that summer but we were in desperate need of strategic clarification. I needed it for my own job, the company needed it too. The industry, it seems, had already decided.

As far as reviews of the product, Byte magazine concluded “on both technical and strategic grounds, Windows 3.0 succeeds brilliantly. After years of twists and turns, Microsoft has finally nailed this product. Try it. You’ll like it.” Still, the technology enthusiasts were fretting about OS/2.

There was definitely a feeling that we were at some sort of new beginning with Windows 3.0, and at the end of the first era of the personal computer.

On to 008. Competing with Steve Jobs (the First Time) [Chapter II]

Go back to 005. Keeping Busy with Cross-Platform OOP

Thank you for reading along and the great comments! This post tells the story of my first memo, Zero Defects, and the impact it had on me and all of Apps. Microsoft was a company that wrote code but we also wrote memos, especially in Apps. Memos were often 20 or more pages long and printed for circulation via interoffice mail—we were building those tools after all! Also, this is my first performance review.

When it came time to write my first performance review, it simply read “attended ADC” and looking forward my only goal was to “make ET++ work.”

Still, I was nervous about writing mine. So, I shot off an email to Melissa Birch (MelissaB) asking for some tips. She was on the Word team, which was in the very final stages of shipping the original version of Word for Windows 1.0, code name Opus and another long and late project. She graduated from Brown University in 1987 (the same year I graduated Cornell). Melissa was tall, polite, and formal. We shared the East Coast rhythm and sensibilities. MelissaB was an astute engineer, tuned into the challenges of making projects work. I knew she could help.

Thanks to fellow Apps Tools developer Kirk Glerum (KirkG), I’d made my way through the gauntlet of a seemingly cliquey lunchroom of regular tables, seated at a table with MelissaB, KirkG, DuaneC, Jodi Green (JodiG), and many others on the Word dev team.

Kirk was a hacker’s hacker. He spelled his name Glærum (which wasn’t spelled that way by the facilities name-changers and was quite a trick to type on US English keyboards in MS-DOS) in reference to his family’s Nordic heritage. KirkG was as Northwest as one could get—he was the first to inform me that I was no longer allowed to use an umbrella. He grew up in Oregon. He attended the University of Washington and was a die-hard Husky fan right down to his purple Converse (when meeting people, where someone went to college was often the first fact Softies revealed since so many of us were straight from college). Most interesting was how he ordered a sandwich at the cafeteria. When asked what he would like, he always said, “Surprise me.” I could never have ordered like that. I later learned his business card listed his title as “Software Alchemist”—back then you could make up your job title and mine said “Computer Scientist” since I was convinced I would eventually go back to graduate school.

A New Yorker, JodiG joined Microsoft early on. It was immediately apparent that she was a manager because at lunch she was always asking other members of the team about their bugs and progress. She was another graduate of Brown. It was common for graduates of the same school to find each other at Microsoft, even if they weren’t classmates, because alma mater recruiting was something developers did, mostly because they knew the department, classes, and professors. I would soon be making recruiting trips to Cornell.

To help me with my review, MelissaB, over lunch, talked about the new mantra at Microsoft called Zero Defects. We would continue this discussion over a long email thread, as was all too common.

Zero Defects was a memo that was circulated by the leading development managers (the most senior engineering managers) in Apps and Languages. It was an effort to attempt to get a handle on product death marches and ever-increasing bug counts that were contributing to a broadening view of inevitability as products became more complex.

A key underlying argument put forth was that we were rewarding developers for checking in new code and declaring a feature done, even if it was not. Testers then found a lot of basic bugs. That meant they were preventing more interesting testing from taking place and that more code to fix those bugs was quickly written, delaying the new work, and testers would continue find even more bugs.

In any software project, adding or changing code had a good chance of introducing a bug approximately 10 percent of the time (a number floating around in academic circles for decades), whether it was fixing one line of code or adding whole new capabilities. The cycle of trying to complete a feature by finding bugs could never really end—this was called infinite bugs and was plaguing the development of Omega, Microsoft’s first Windows database, and to some degree Opus, Microsoft’s first Windows word processor, which began in 1984 but did not RTM until 1989.

RTM, release to manufacturing, was a phrase heard constantly. Everything was about getting to RTM. RTM was the ultimate goal. RTM was shipping. For the first decade or so of Microsoft, RTM literally meant to a factory, a Canyon Park facility about 10 miles north of Redmond where there was a shrink-wrap assembly line of boxes, manuals, and floppy disks. At the end of every product, at RTM, teams took a trip to Canyon Park and watched the first boxes roll off the line. We might have made software but we shipped it in boxes to retail stores.

The specification for Opus from BillG famously was “build the best word processor ever” and finish by October 1985, to align with the release of Windows. This was likely the first edict for Apps to align with a Systems schedule, a topic that emerged again and again. It was also as likely as two golf balls colliding mid-air.

Zero Defects was probably one of the most profound engineering documents I had ever read, and yet it was also common sense and blindingly simple. I remember one sentence well: “The hardest part is to decide that you want to write perfect code.” This was an impactful memo, in part because it was my first exposure to the collision between the idealized world of hacking and the pragmatic world of engineering products for millions. It was so practical and made so much sense, yet it was such a dramatic change from the hacker ethos that the most and fastest coding wins.

It might sound over the top to call a single memo that is literally about how to code without bugs as something “profound.” Certainly, for me it was profound because it was the first business memo I read that was also about why we are doing what we are doing, not just how. In a broader context, however, the memo was about the novel enterprise that was Microsoft at the time. Apps was building software for millions of people that were not trained computing professionals. That was new, for everyone. This memo was a realization that the company was at a crossroads and the old way—the way of hackers and hobbyists—was no longer acceptable.

This memo also marked a change in the entire Apps division, now numbering hundreds of people. With two big projects that were late and buggy, Omega and Opus, and several other challenging projects such as the recall of Macintosh Word for quality issues, Apps needed to do something different. No other company was building software at scale across so many categories and so many platforms as Microsoft Apps was doing. While all this was going on, Excel version 3.0, for both Windows and Macintosh, was under development and would soon ship merely 11 days late and with rock solid quality—a feat that would not be bested for a decade or more.

From my vantage point, Zero Defects, marked the start of Apps culture of shipping. A culture that included an organization structure to scale development teams, a process to plan and schedule products, techniques to maintain engineering throughput, along with methods for ascertaining quality through the entire development schedule. Excel 3.0 would be proof that projects could be on time and have superb quality. Apps would iterate and hone this process for years to come, but it is neat to have a sense for when it all began.

That is somewhat hindsight. The memo would have been more profound to me if I ever experienced a death march or worked on a large and complex shipping code base. I had no experience shipping a product, so what did I know? As MelissaB shared her perspective with me, I came to understand what ZD as we called it really meant. There was no system-wide integrity (in an engineering sense) and that the wrong people were writing too much code. Some developers wrote a lot of code to make it look like a feature worked, even if all the boundary conditions weren’t handled or if the code was fat (a Microsoft expression for verbose code that took too much memory or was too slow—a quick reminder that PaulA’s and BillG’s original Microsoft BASIC fit in four kilobytes of memory, or about two pages of this book). Worse, those developers received high praise for getting “so much done.” System-wide, the schedule was used not as a tool to get work done but more as a system to stretch goals without reflecting the complexity and interdependence of the work of the team.

Something MelissaB said to me during one of our lunches and many emails on the subject resonated for decades and proved to be a cornerstone, not only for me but for how the entire Apps division (and later Office then Windows) operated. Her reading of Zero Defects and her own observation was that everyone should be focused on clearly communicating what work they did and be measured by achieving that. No games. No stretch goals. No race to check off things that were not yet done. No doing the minimal work to make a feature demonstrable. Later, we came to call this promise and deliver.

Melissa also connected some dots for me and explained that the way groups were rewarding people who ultimately contributed more bugs than code was in practice rewarding some men and penalizing some women on the team. Teams that were small had few women. There was no hiding that fact. Melissa’s view was that the women were routinely delivering the code they said they would, when they said they would, and at the same time getting feedback about the need to do more. As potentially controversial as such a statement was, it was simple to demonstrate by looking through the schedules and at the RAID database. While Microsoft was just starting to appreciate how different developers worked, Melissa’s explanation of ZD in the context of specific people and their approaches to work (and rewards) made everything far more concrete. The specifics Melissa shared became a rallying cry for me later in my career as a manager and I would often share what she taught me.

Underlying this memo was the beginning of the idea of continuous quality. Every day the product should be shippable and of high quality. Work that was not yet completed was not part of the checked in (completed) code, but that code was kept in sync with the main product. This is something analogous to today’s continuous integration and continuous delivery, and it took decades for Microsoft to achieve this level of engineering, which began in a moment of crisis and self-reflection. Although this seems obvious today, software projects were not typically run in this fashion, certainly not PC software.

That’s the long way of explaining that MelissaB’s answer for my performance review question was to “make sure you put in that you will practice Zero Defects in everything you do.” That was a bit cynical, but it worked for us, and everyone. Those were performance reviews circa 1989.

With those goals in hand, we spent the fall of 1989 and winter of 1990 hacking away at ET++ and making it work on OS/2 and Windows. Little sample programs, like a calculator, worked. Along the way we found a lot of bugs in the new version of the Microsoft C compiler. And we continued to test out the programs we created on Windows 3.0.

In many ways, those early months were a second ADC or an ADC practicum. The opportunity to be on the ground floor of a new computer language was great, and the added challenge of trying to make it work on a bunch of operating systems that didn’t work only added to the fun and, also, the frustration. I guess I had not really considered that my job might be frustrating. It had not yet occurred to me how truly messy the company was.

Nevertheless, experiencing this while waiting for other groups to finish so we could collaborate seemed better than any alternative. Once performance reviews were complete and thinking about all my friends shipping Windows 3.0, Word 1.0, and Excel 3.0, left little doubt my project was busy work and it was dragging on.

Go on to 007. Windows 3.0 Buzz

Back to 004. Everything is Buggy

I finally have a project to work on. Unfortunately it feels a bit like make-work and I have no idea how it fits into the big picture of Microsoft. Actually, I’m not even sure what the big picture is as we’re all in the middle of the strategic shift to GUI and Microsoft has multiple operating systems we’re supposed to be supporting.

As part of the Apps Tools group, we were set up to provide the tools to make it easy to build apps that worked on any platform, regardless of the differences or details of each platform. Isolating app developers from platforms was our job. The industry called this cross-platform development.

Historically, such an approach was at the core of Microsoft from the beginning, simply because computing had always been heterogeneous. The makers of computer hardware customized the operating system, which in turn meant that apps needed to be modified to run on each different computer system. This was not any sort of evil plot, as some believed, but simply something that was in place because the hard part of making a computer system was the hardware. Hardware engineers, naturally, chose to modify the software if it meant making the hardware easy. In Microsoft’s earliest days, PaulA and BillG made the BASIC language for many different computers. Microsoft early apps, like the Multiplan spreadsheet, ran on many different personal computer systems at the time, a variety of 8-bit microprocessors and operating systems. Developers like JonDe and DuaneC were experts in the underlying technologies used to get Microsoft apps running on systems from DEC, Tandy, Zenith, Data General, and a host of other names from a bygone era, as well as IBM and then Hewlett-Packard, Compaq, and Dell. PCode and the virtual machine that DougK talked so poetically about in my summer training were in part about making it easier to run software on multiple platforms.

It was natural, therefore, that with Microsoft looking to grow the graphical interface apps business while also itself building multiple operating systems, there was a need for cross-platform tools that were more sophisticated than the 8-bit character mode tools that were already in place. Microsoft needed cross-platform tools just to be able to develop its own applications for its own operating systems. Let that sink in. It was common practice in the industry at the time for every major independent software vendor to also develop their own cross-platform toolset, designed to optimize for their own app and their own view of the platform landscape. Microsoft was unique in creating its own need for cross-platform tools, with multiple operating systems and its own applications.

Cross-platform product development was the elusive brass ring of development that accompanied each generation when there was no clear platform winner. From mainframes to minis to the increasingly popular Unix variants to microcomputers, and now the rising graphical interface. Each new platform promised to be the one to end all platforms, and it might have been, until the cycle repeated. Cross-platform tools are one of those developer problems that everyone believes they have an answer to, certainly early in software lifecycle.

This did not stop even Microsoft from getting caught up in building cross-platform tools. As platforms and applications mature, cross-platform becomes increasingly difficult and the customer experience decreasingly good. Microsoft was still in the early days of cross-platform so it was looking workable. Given the early success with BASIC and 8-bit character mode, it was no surprise that BillG thought the next generation of such work was trivial, a term he loved to toss around. The difficulty—the lack of a trivial solution—was that more and more work was shifting to operating systems away from apps. In other words, as Microsoft (with IBM, and Apple) invested more into making the operating system feature-rich, it made building cross-platform applications more difficult. In fact, that was the strategy, even if it pertained to its own operating system products.

Still, the industry believed the key to making cross-platform trivial was a programming technique, one that wasn’t too new dating back to the 1970s Xerox Palo Alto Research Center (PARC), called object-oriented programming, or OOP (sounds like oops). OOP was everywhere. A trip to the Tower Books on NE 8th Street in Bellevue, something I routinely did on Friday nights because it featured a necessarily deep section of programming and technology books, yielded new books every week with OO in the title. OOP promised to make programming an order of magnitude easier (another common phrase, meaning 10 times better or more, but with no specific units or ability to measure).

OOP was also deep in my own bones. My lab in graduate school was the Object-oriented Systems Lab. We spent the better part of a year recreating the original OOP platform from Xerox PARC, Smalltalk-80, so we could build our own OOP projects using that as a foundation. It is where I came to believe garbage collection was an important part of OOP. I came to Microsoft already an OOP zealot, which in part was why I was hired I was later told.

Aside from abstract computer science concepts, a new innovation for OOP was a new programming language pioneered at AT&T Labs, which, despite the breakup 10 years earlier, was still functioning and a leader in many fields of research, still winning prizes and medals. C++ was the OOP version of the widely used and taught C programming language. That meant it held the promise of not only making programming an order of magnitude easier, but also through its OOP techniques making it possible to be cross-platform, all while maintaining compatibility with the industry standard C language (the language used across Microsoft at the time). OOP as expressed in C++ would make not just cross-platform programming easier but make all programming easier.

Imagine that? No, really. Imagine that, because that’s all that could be done at the time, or ever.

The buzz around OOP reached epic, or comical, proportions even making its way into mainstream business press. The cover of BusinessWeek magazine featured a baby in diapers at a keyboard and monitor introducing OOP to readers as “a way to make computers a lot easier to use”. It was no longer just a magical tool that would make cross-platform programming trivial or a technology that computer scientists believed would lead to more robust and maintainable code. OOP was even going to make resulting applications easier to use.

Object-oriented programming and C++ represented my introduction to the hype cycle of the technology industry. In experiencing this now, I was fortunate in two ways. First, I was still early in career, so I was more mystified than cynical. Second, I was surrounded by already seasoned managers focused on “shipping” who helped our group to navigate the St. Elmo’s fire of OOP.

The industry would undergo a tectonic shift over a multiyear journey to demonstrate the utility of OOP when it comes to mass market software, especially for GUI platforms. Today, most anyone can build GUI applications, but early on the complexity made that extremely difficult. While we could not make it possible for an infant in diapers to program, we could make it much easier for the typical professional or college student. The degree to which OOP or other developments contributed to making it easier will always be the subject of debate, as programming tools and languages always seem to be. There is no doubt, however, that OOP is deeply rooted in the evolution of the graphical user interface, going all the way back to Xerox and forward to today’s smartphones.

Making progress in my new job, however, had one big problem: There was no C++ for the PC. In fact, there was barely C++ at all as it was primarily a research project at AT&T. The only tools around took C++ code and transformed it into C to then be compiled by a C compiler. Normally, one thinks of programming as typing in one language and then converting that into the raw numeric code for the PC, straight from English-like to binary numbers. C++ was so new that using it was akin to translating to German by going from English to French to German. C++ was first translated into C that Windows tools could understand, then finally translated into binary.

Like every other Microsoft project we were already late and behind schedule though I didn’t realize it or even really internalize it. But how could I have? I had no idea what product we were supposed to be building. All I knew was we were supposed to be working on cross-platform GUI and that meant OOP and C++. We did not, however, even have the software development tools to use the C++ language. There was a team in Languages working on a compiler, but first they were busy releasing the latest version of C, which was late and buggy and did not include C++ support.

ScottRa cleverly decided that we needed to keep busy. I was too young and naïve to really understand how deliberate this strategy was as Scott was essentially stalling while the company figured out larger strategic issues, such as Windows versus OS/2 versus Macintosh, and while the Languages group finished up C and could move full time to C++ tools.

Were we soldiers, doing battle and training, or were we the TVA just digging ditches to keep busy? I had no idea. Nevertheless, ScottRa devised a simple master plan. We learned the ropes of getting C++ code to work by being pioneers within Apps and using a crazy library of C++ code from researchers in Switzerland, ET++, and a commercial product Glockenspiel C++. The latter was a port of the AT&T C++ tools to OS/2 designed to work with Microsoft’s industry-leading C compiler, C version 5.1, that was already in market. ET++ was something called an application framework, not unlike parts of Smalltalk-80 with which I was very familiar—a framework was a collection of prewritten objects or code that helped programmers to write applications quickly because they could reuse previously written code. ET++ too was cross-platform, but it was just a research project at a university. ET++ was presented at a paper that came out when I was in graduate school and compared itself to MacApp, an application framework for the Macintosh that I was also quite familiar with from my MacMendeleev days. It was a given that we would someday build our own application framework. ScottRa told me it was just too soon.

That meant, however, at least there was a project. We spent our days trying to get ET++ to work on OS/2, which basically no one else on earth was even thinking about. Days turned into weeks, and months.

I was glad to have a project to work on. Like so many new hires into big companies, though, I struggled to figure out how what I was doing fit into the big picture. Actually, I wasn’t quite sure of the big picture just yet.

On to 006. Zero Defects

Go back to 003. Klunder College

Subscribers, thank you so much for the kind words and most of all participation in the discussions. My heart warms each time someone shares their own story or memories from these times. In this section, I am transitioning out of Apps Development College to my full time role. Along the way I am learning the realities of PC software today—it is usually late, and usually buggy. I’m also starting to learn a bit about the two cultures at Microsoft, Apps and Systems. There will be a couple of short posts after this and then we’re off building products!

As the summer of 1989 turned to fall, the shipment of Windows 3.0 was looming. When not working on a Mac product or trying to get OS/2 stable for daily use, most of us in Apps were dealing with getting something to work on Windows and reporting bugs back to the Windows team.

Far away in Systems, Windows, what started as a side project was now a full team of people grinding away on a death march to get Windows 3.0 done. Typically, in those days, this period of heightened work hours and intense cycles of bug fixing marked the last months of any project. The cafeterias were not usually open for dinner ushering in a (mostly) Systems tradition of ship meals, featuring a buffet much fancier than the cafeteria offered. The idea of serving dinner as part of routine death marches became a decidedly Systems approach that was so formalized it became a budgeted line item (as I would later learn when I joined Windows). Windows 3 was still months from shipping, but the activity was going on around the clock.

Windows was in Systems, which was the big dog half of Microsoft. While the history of the company was in Languages where BASIC and other tools were made, the center, and at the time the economic engine of the company, was Systems where MS-DOS was made. MS-DOS was the brilliant product born out of a commitment to IBM to deliver a product that didn’t exist and wasn’t yet under development. It was subsequently acquired and modified to meet the deadline, with the twist that Microsoft was free to license the product to other computer companies.

In other words, while IBM was the first contract for MS-DOS it was not exclusive.

Out of that, the entire PC industry was created. And not for one second was that lost on the Systems people.

From those early first days, Microsoft felt like two different companies: Apps and Systems. A buzzword in modern business, these two cultures could not have been more different, at least that’s what I was led to believe by listening to stories at lunch. Even though the company was made up of only about 3,500 people, with half in Redmond, I had not yet met anyone in Systems. While I could have easily walked a few hundred feet over to one of the buildings they occupied, that wasn’t something that people did. Apps and Systems didn’t exactly intermingle.

The one thing we knew about Systems, despite the anonymity, was that as buggy and late as Apps products were, the Systems products, I was informed, were buggier and later. Windows 3.0 was coming down to the wire. There were no real secrets—many people had builds and were installing the product, and the weekly industry tabloids, InfoWorld and PC Week, were tracking the latest rumors, test releases, and gossip. The actual delivery date was not well known, not by the team or anyone else until very close to the announcement of that date.

From the time I arrived at Microsoft and installed that first build in ADC in the summer, the launch of Windows 3.0 was always real soon now, often abbreviated RSN in snarky email. That had no impact at all on the enthusiasm as the buzz that Windows 3.0 would be a breakthrough was pervasive through the hallways. The industry was equally anxious for what appeared to be a showdown across a plethora of operating systems including MS-DOS, Windows, OS/2, and Macintosh.  

In hindsight, it was easy to make fun of the fact that everything seemed late and hardly worked. The entire industry was like that. From the earliest days of PCs none of us knew anything else.

The expression vaporware was commonly used to refer to software that was well known and frequently discussed but not yet shipping. The phrase was used first as far back as 1983 by Esther Dyson in the industry thought-leading newsletter Release 1.0. In some sense, most everything was vapor. I remember sitting in my ADC office having just received a Goldman Sachs analyst report on Microsoft from the library. In the report was a table of all our company’s products under development and estimated ship dates. The dates were far in the future and all wrong by many months or even years.

In fairness, it was challenging to simply get a non-trivial product built, have it work on the wide variety of PC configurations that existed, and then ship it in dozens of languages. That’s because there was no internet, no diagnostics, or telemetry, and anything that went wrong simply crashed the whole computer, requiring a power cycle. And, most importantly, the field of software engineering was nascent to the point of not really having the institutional knowledge of building and testing software for mass distribution. Before the PC, there were many complex systems, but each one was custom and staffed by full-time people to keep it running. PCs were different. Everything was new. And that was before the complexity of coding for a graphical interface like Windows and Macintosh.

One of the biggest differences with PCs was that the PC operating system ran in such a way (called real mode compared to protected mode that would be introduced later in Windows and still later in Macintosh) that any bug in a program generally did one of two things, but probably both. First, for certain, whatever file was open and being edited probably became corrupt and data was lost. That was a heart-stopping given. Second, there was a good chance that the crashing program also caused the computer to crash, hang, or otherwise stop working. Thus, the cardinal rules of the early PC era were born: First, frequently save work and make backup copies, and second, if something goes wrong, reboot the machine.

I learned this firsthand too many times. In college when I operated computers in the lab, an entire shift could often be consumed by trying to help a classmate salvage the remains of a term paper off of a floppy after a crash. Those were the most horrific bugs because work was lost that people assumed they were saving. Such were early PCs (and Macs).

Because of this, it was extraordinarily super-human to even get programs working in the first place. By definition, a mistake in the code caused everything on the computer to stop working, including the tools being used to diagnose the bug. The best programmers, like Duane Campbell (DuaneC), ScottRa, and others, were able to figure out how to step through each instruction carefully and monitor whole blocks of memory for changes at the lower levels to figure out what was going on.

DuaneC was already a legendary programmer within the ranks, a tech lead as I would learn. He was a few years older but seemed more grown up simply because he was married and had a maturity level that most of us lacked. DuaneC had a slight Southern accent, having grown up in rural Tennessee, and a speaking tempo I was familiar with from the people I grew up with in Florida. He was a musician but also studied computer science at the University of Tennessee. He was one of the earliest members of the MS-DOS Applications team and a key contributor to Word. He was also one of the kindest and most thoughtful leaders I had ever worked with.

The most difficult bugs were those that crossed from the application into the operating system. That meant it took knowledge of not only your own code, but also code in MS-DOS and probably code from a video or print driver as well. Lunchtime discussions often dove deep into the details of bugs and the techniques used to find the mistake, and almost always the mistake was one of a small number of common flaws, such as forgetting to check for null pointers or using uninitialized variables.

The tools and techniques that were being developed across the engineers at Microsoft to build software at scale and to make reliable products proved to be a competitive advantage. That was an important fact. It was state of the art. The 1990s saw an incredible advance in building software at scale. And no company did that better than Microsoft. Microsoft’s ubiquity and scale did not allow for gloating or even acknowledging the progress, but it would have been deserved.

The world outside of Microsoft was different. Outside, the computing landscape was marked by a period of extreme heterogeneity. While IBM lorded over the PC, which dominated business, Compaq and Dell were becoming leaders in making PC clones and even racing ahead of IBM in areas like portables and using the new Intel chips. Apple Macintosh was not viewed as a viable alternative in business but captured the hearts and minds of students, educators, and creatives. While Microsoft was busy making MS-DOS and Windows 3.0, and was already shipping Windows 2 with Excel, it was also deep in a partnership with IBM to develop OS/2, a much more sophisticated and reliable (protected mode) operating system. From the outside, Microsoft looked confused or at least lacking a clear strategy. Caught in the middle were companies trying to bring software products to market. Which operating system would they come to rely on for their products? Some viewed the duality of Windows versus OS/2 as an elaborate scheme by Microsoft to distract potential future competitors. The age-old conspiracy theory, which lacked any foundation other than IBM’s poor execution, was that this was some sort of head-fake to distract developers with OS/2 while Microsoft could dominate Windows apps. The partnership with IBM was the highest priority, but it wasn’t working out well.

The ever-present industry trade magazines seemed not to miss a beat over the rift between Microsoft and IBM. The raging debate over the cost and benefits of moving to a 32-bit operating system, specifically OS/2, was front and center even though OS/2 for 16-bits had not taken off at all. This put Windows 3.0 at a perception disadvantage as it was a 16-bit operating system that could take advantage of 32-bit Intel processors. The industry disliked this lack of purity but loved the complexity of the debate. Something I learned early is just how much the PC era was marked by bringing complexity front-and-center to debates that had little to do with customers but served to keep analysts and pundits busy. Our job was to hide complexity, but it seemed others were constantly surfacing it. Though to be fair we did our share of talking complexity, not usually passing up a chance to demonstrate our nerd credentials.

More importantly for customers, there was the constant coverage of quality problems with software and hardware. If programs were not slow, they took too much memory, or hard drive space. At the same time, every week seemed to bring more news of faster processors hoping to finally make yesterday’s software fast enough to use. Except we were busy building more software, requiring even faster processors and more memory. We were under constant pressure to build software that ran on PCs customer had while also taking advantage of the latest processor and hardware. In hindsight, what saved us all was that at any given time the installed base of PCs (the number of existing PCs in use) was being dwarfed by the run rate of new PCs (PCs sold to new customers or to replace older slower PCs). The velocity of this dynamic was key to our ability to constantly ship software that outstripped the PCs people already owned.

The industry saying was something along the lines of “what Intel gives, Microsoft takes away” in reference to increasing hardware capabilities constantly outstripped by more demanding software.

The early and successful Microsoft strategy of developing applications that ran on multiple platforms, remained the cornerstone of the Apps strategy. Only now Apps was busy enough just developing for Microsoft’s own platforms consisting of the mature MS-DOS where Apps never gained a lead, the nascent Windows that few were buying (yet), the non-existent, mostly non-functional but strategically critical OS/2, and the monster money-maker Macintosh that was competing with all of those. As crazy as the strategy (or lack thereof) seemed to the press and Wall Street, it was even more taxing for us developers in Apps.

Cross-platform development was not only impractical but the answer to a question no single customer had on their own. Yet that did not stop the search for a magical solution, and thus my first real programming work. Microsoft, BillG in particular, always believed there was a software solution to any problem if enough “IQ” was applied (BillG used IQ as an expression of currency, such as “how much IQ is in that group” or “he brings a lot of IQ to the problem”). This optimism and faith in IQ was a gift to Microsoft, but also caused a lot of problems because not every problem required a high IQ solution and those with high IQ could not always apply it in a practical manner.

Finding such a magical solution was my first project and the first project of our new team.

On to 005. Keeping Busy with Cross-Platform OOP

Go back to 002. SteveSi

ADC, Apps Developer College, was more a curriculum than a college, run by Dan Newell (DanN) and Doug Klunder (DougK). It was called Klunder College because Doug created it. ADC was basically a couple of three-ring binders of assorted documentation and memos and a bunch of self-paced coding exercises that constituted a new and unique approach to on-boarding at Microsoft at a time when most everyone who programmed was self-taught. The idea of a programming orientation or bootcamp seemed unnecessary, perhaps even insulting. I would take away much more than I could really understand at such an early juncture in my career as I immersed myself in my first lessons in culture.

Most teaching was done during a meeting with Dan, and usually by stopping by or hovering at his office. Even though we had offices, there was a constant roaming of the hallways and stopping by unscheduled to see people. This, I would soon learn, was the Microsoft management and learning culture—self-sufficient, informal, and interrupt-driven (a specific computer term that became one of my first Microsoft-isms—“What’s the best way to meet them? … Oh, they are interrupt-driven.”) It was a big change from the structure of universities but also consistent with how most everyone there had learned PC programming in the early days.

DanN’s office was filled with vinyl records, a stacked stereo system, and a few early ’80s music posters. He was an experienced Microsoft SDE and was half the leadership of ADC. A few doors down was DougK. In contrast to Dan’s office, Doug’s office was completely spartan, as though he had only recently moved in. Doug looked like a member of the Doobie Brothers, with a long beard, flannel shirt, cords, and no shoes. He was exactly what my mother had warned me about.

Doug was a programming legend at Microsoft. After graduation from MIT he joined Microsoft as the first college hire and subsequently an informal leader in the quest to hire directly from college, especially in Apps. He was one of the earliest Apps SDEs and had written much of the code in an early spreadsheet for MS-DOS that Microsoft released as Multiplan but called Electronic Paper, or EP, while under development.

Dan told me that BillG decided the company’s future was on graphical user interface (GUI) like OS/2 and Macintosh so the company chose not to bring an updated MS-DOS (CUI, or character user interface) spreadsheet to market. Doug was so frustrated by this decision that he quit Microsoft and went off to work on a farm in California. Doug’s innovative work was critical to Mac Excel 1.0, which ultimately shipped for the original Macintosh. Later, he returned to help finish Mac Excel 1.0 and contribute broadly to Apps in the transition to GUI. Doug was the ideal person to indoctrinate us into the ways of Microsoft Apps.

My first day had been a success, or at least not a failure.

After a few weeks of ADC, I finally received an email from ScottRa. He suggested we meet the next day first thing. “How about 11 a.m.?”

Microsoft SDEs bordered on nocturnal in those days. This was consistent with how college programmers coped with the scarcity of computers. It was always best to work late at night when fewer people were trying to get to terminals and, if on a shared mainframe, slowing it down. Everyone was working nights at the office back then. There was no way to even do email from home and certainly not any coding. The old Xenix email system made it easy to see if a person was logged on, and rumor was that BillG was always checking in on key people to see if they were connected. These were all traits of the original hacker ethos that had worried my mother.

When asked if Microsoft had “flex time” (an ’80s buzzword) by prospective college hires, we always said, “Yes. You can choose to work whichever 80 hours of the week you want to work.” That was, essentially, true for the ’90s. Our views later matured as did the company, much to the chagrin of new old-timers like me. Mostly we were in our 20s and loved what we were doing.

Scott explained what was in store for me for the next few months. Before programming anything I needed to learn the unique dialect Microsoft used. While I knew the programming language, Microsoft had a unique style called Hungarian, named for Charles Simonyi (CharlesS), one of the rarified level 14 architects in the company and the only one in Apps. CharlesS was recruited by BillG from Xerox PARC where he had built the first GUI word processor. Hungarian was the secret handshake used between programmers at Microsoft and it was unlike anything I’d ever seen. In college programming or in books, one might use a name in code such as FormatLine. In Hungarian, we used names like FFormatLineFspec, which were chosen to make code more manageable for large teams.

I also needed to learn the tools used to build Excel and Word. There was a proprietary programming language called CSL, also named after CharlesS. This language, based on C, had a virtual machine, which made it easier to run on other operating systems (in theory) and also had a good debugger—attributes that were lacking in the relatively immature C product from Microsoft. I also learned RAID, the database tool that the product groups used to track bugs in products (get it, complete with backronym of Reporting and Incidents Database). And, most importantly, I learned SLM, pronounced slime, the source code tracking tool (like GitHub much later). Through this I used shipping code and coded up features and fixed bugs as exercises, never checking them into production. It sounded pretty cool. It was pretty cool.

I loved talking with Doug. He was not like anyone I had spent a lot of time with—he was truly the hippie/hacker Time described. As I got to know him, I learned of some of his relatively extreme perspectives. He was obsessed with privacy. He didn’t have a driver’s license, bank account, telephone, or anything, but still lived among us. I often saw him outside of work. We lived in the same neighborhood (Capitol Hill, soon the heart of grunge music) where he always paid cash at one of the restaurants in the neighborhood. This dedication to privacy proved even more ironic, and prescient, as he went on to build Microsoft Money, which he used to track his cash transactions. In his post-Microsoft career, Doug became an attorney and, admirably, went on to work for the ACLU on issues such as privacy. He was ahead of his time.

Importantly, for my own future, Doug instilled in me a sense of principled product development. Throughout my time at ADC Doug shared his account of the decisions around building Mac Excel instead of a new MS-DOS spreadsheet, including a famous Red Lion Inn offsite where the strategic decision was made to bet on the graphical interface. BillG insisted on prioritizing GUI over CUI even with a potentially killer MS-DOS spreadsheet close to complete, causing DougK to ultimately quit out of principle. Doug’s principled lessons followed me through my career.

Doug was an incredible programmer, the first of many amazing ones I met. He had a full map of an entire body of product code in his head and a deep understanding of the data structures and code paths—more than encyclopedic but organic as though his brain had merged with the code. In hindsight, I came to understand that great programmers have the same relationship to code and products as great writers do to words and complete works, or filmmakers do to camera shots and complete films. Every line of code, every data structure, was not only deliberate but deeply related to the other choices one makes.

One issue we spent an enormous amount of time discussing was memory management, which was an acute problem in PCs those days—how to fit more information in less space. This was not simply about data but also the amount of code in an application—how to do more with less. Doug recounted how he had developed minimal recalc for Excel (originally for the unreleased spreadsheet product), which was a way of only recalculating the cells in a spreadsheet that needed to be calculated when something changed. Previously every change in a spreadsheet recalculated the entire sheet, which was slow and memory intensive. It is difficult to overstate the brilliance in Doug’s approaches. It would be equally fair to say that Doug wrote code only Doug could understand, very much how great products were built then.

Many of the conventions or techniques used in Apps were pioneered by Doug and taught or, more correctly, transfused to us in ADC. Even though software products were often late (very late) and quality was spotty (very spotty), that was only in hindsight. In general, Microsoft’s Apps, particularly MS-DOS Word and Excel, were generally among the most robust and highest quality. DougK and DanN instilled several key lessons about being an Apps software design engineer:

* Scheduling and estimating work. Individuals needed to be really good at scheduling their own work and coming up with estimates that were not only precise to the day but accurate as well.

* Bulletproof code. Developers were responsible for building code beyond their features, including the code that ran in “debug mode” that was constantly checking the integrity of the data structures and ensuring that assumptions made by programmers were validated. During any code review in ADC, the code was sent back if it was not fully defined by what were called debug ASSERTs, or code that was run to verify the values of variables and integrity of data structures while running a special build of the product for this purpose.

* Self-documenting code. Schools taught that good code had comments or annotations that were not code but English that explained the code. Doug hated comments and insisted that code should be the ultimate comment itself. This was a bit ironic because he was known for developing some insanely efficient code that was also difficult to read and would have benefitted from comments. His view was that comments were always out of date and far less precise than the code itself. I really had to unlearn commenting, a practice I had embraced.

* Performance in speed and minimal memory. CPUs were slow and memory was extremely scarce, so there was a big focus on writing efficient code. This was rooted in BillG and was an important part of Microsoft’s early developer culture and key contributor to success. Code written this way was hardcore.

During ADC, I built a memory allocator, code that handled requests from a program to provide memory to store data and later free memory. Early programs, especially written in C or CSL, were notorious for mismanaging memory, which caused program crashes and in turn crashed the entire computer along with it.

Doug had developed a set of ideas for building a bulletproof memory allocator, one that tracked allocations and reallocations and made sure memory was properly initialized before it was used in the code. These were super common bugs in PC software.

It was a huge learning experience. But I had also been working on modern, automatic memory allocation called garbage collection (GC) in graduate school. After a few days of hacking away on my memory allocator project for Doug, I worked up the guts to approach him and ask why Microsoft did not use GC.

It didn’t go so well. Doug literally laughed at me. Still, after I persisted, he suggested I go meet Jon DeVaan (JonDe) on the Excel team who could go through every bug in Excel (it was up to version 2.x and ran on Windows) and explain how many came from bad memory management code. Doug knew that his memory allocator, also my programming exercise, was a significant barrier to creating memory allocation bugs in the first place. He wanted me to see for myself.

JonDe didn’t laugh at me like Doug had, rather he listened then indulged me by going through 30 minutes of RAID searches looking at memory management bugs to see if GC fixed them. GC prevented perhaps eight of 7,500 in Excel. That made for a convincing argument that GC was not remotely worth the tradeoff in memory and performance. GC would eventually become standard practice on the web and on Apple’s iPhone, but I was a decade too optimistic.

JonDe was among the best Microsoft had ever produced, in addition to being one of the best engineering managers to have ever worked at the company. We worked together for the remainder of my time at Microsoft, each with unique strengths, making each other better at what we did.

I spent an inordinate amount of time installing Microsoft products and using them. I developed my own method for using a network boot disk and getting a “clean” PC up and running. This skill seemed to be both a necessity and something each person reinvented on his or her own. PCs still barely worked.

One product I spent a lot of time on that was still under development, Windows 3.0, a year away from finishing but was already the buzz of the developers running it. At the time, the mainstream SDE machine was running OS/2 because it was able to use more memory and handle more programs gracefully, but it also had a lot of limitations, such as a lack of apps and the inability to print. There was always much cafeteria discussion about how lame OS/2 was, wondering what was going on over in Systems with our partnership with IBM.

Windows 2.x was already in market and had some early pioneers supporting it, including Ray Ozzie at Lotus, who had developed the innovative Notes product. The biggest supporter of Windows 2.x was Excel, which was also developing version 3 of Excel to be on both Windows and Mac (and OS/2) at the same time, using an innovative cross-platform layer of software.

Back then, buyers did not get a PC with Windows. PCs came with MS-DOS. Using Excel meant buying Excel, and it came with Windows. According to branding and packaging, Windows was an operating environment, or more like an app on top of MS-DOS. This became the subject of antitrust consternation years later. As innovative and successful as Excel was on the Mac, Excel on Windows was not competitive with the MS-DOS Lotus 1-2-3. Microsoft’s older CP/M and later MS-DOS spreadsheet Multiplan was a distant number two.

Windows 3 was a bit of a skunkworks project and was a bet on a new architecture called protected mode, which enabled multiple programs to operate at the same time and share a larger amount of memory. In many ways this was also what OS/2 was supposed to do, but OS/2 had much grander visions as well as a difficult engineering partner in IBM (or IBM might say it was Microsoft that was the difficult partner). Windows 3 was beginning to look more like an operating system and less like an add-on to MS-DOS. It was interesting to install and play around with, which all of us did. Actively under development were versions of Word and Excel and several other products. We spent the summer trying everything.

DanN shared with me what he was most excited about—one of the key “secrets” of Windows 3, which was how the product enabled protected mode but could also remain compatible with old MS-DOS programs. David Weise (DavidW) and Murray Sargent (MurrayS) had invented some novel uses of the Intel chipset that even Intel did not anticipate, which enabled these efforts. One programming trick called PrestoChangeoSelector was a key “hack” they developed and later became an absurd symbol of “secret” application programmable interfaces (APIs) in Windows (absurd, because it was supposedly secret, when in fact it was right there to see). Dan told this story with great Microsoft pride, as the development of Windows 3 and these techniques represented much of what Microsoft did so well in those days. Hack.

I admired Dan. What Doug brought to ADC in insights for coding, Dan brought in big picture about how products were built and team dynamics. Dan knew everyone at the company and was definitely a cool kid. Because of Dan I got to meet quite a few of the senior people across both Apps and Systems. Systems was pretty okay to Apps people and vice versa, but there was clearly both an organizational and cultural divide between the two—a theme that I would experience for many years to come and also be the subject of many “battles”.

A few months in, Scott came by and said he was anxious for me to join the team. My time in ADC was abbreviated so I could get cracking on our project. Unbeknownst to me, I was joining a newly formed “tiger team” created to build an entirely new product to streamline building applications.

Object-oriented, GUI, and Microsoft’s next killer product (killer was Microsoft jargon), plus Scott told me our project was “super important to BillG.”

On to 004. Everything is Buggy

If you missed the first post, start with 001. Becoming a Microsoftie (Chapter I). A Prologue has been added offering just a bit about my own history with computing. There is also a Roadmap/Table of Contents. If you need an overview and guide to subscriptions with discount codes, see Introducing "Hardcore Software".

Back to 001. Becoming a Microsoftie [Chapter I]

When I first arrived in Redmond, I lived about three blocks from campus, in company-provided temporary housing at an apartment complex called Bellevue Meadows, a block from the Residence Inn I had almost burned down during my interview. It was still light out at 9 p.m. on my first night (welcome to the Northwest), so I walked over to campus to check it out.

Microsoft’s three-year-old campus was made up of the original X-wing buildings, 1 through 6, and the recently completed double X-wing 8 and and 9. There was no building 7. Nobody knew exactly why, though there were a bunch of theories tossed around over the years. Sending a new person to meet up at building 7 was an ongoing prank. The real buildings surrounded a fountain and the small-but-infamous Lake Bill (which, looking back, is much smaller than I recalled from that first night). There was a basketball court near the lake, which always seemed to be in use. The buildings, connected by tree-lined sidewalks, were known for their design, which was meant to maximize the number of private offices with windows.

In a nod to Microsoft’s culture of self-reliance, the next day, my first day, after a two-hour orientation session (that felt like forever), I and about 20 other college hires were left to fend for ourselves. While I had been told how to set up direct deposit (paychecks were still hand delivered for many) and learned some details about my healthcare plan, I literally had no idea where to go. Fortunately, a more studious fellow new hire noticed, buried in the paperwork, that there was a map and an old-style printout with name (Steve Sinofsky), telephone extension (x67768), manager (Scott Randell, listed as SCOTTRA), and an email ID and password (yes, printed). The floor plan and numbering system made MIT’s infinite corridor look understandable.

As I flipped through the paperwork, I noticed my assigned email name was STEVESI on the printout, which immediately irked me as I was steven in all my previous systems (all lower case because of Unix). Obviously, I was not going to complain.

As I came to understand it, SteveSi was officially, and forever, my new name. Email names were how people wrote and spoke about others. Where a previous generation might have used only a last name out of casual respect or mister in person, Microsoft used email from BillG to SteveB on down. Aside from the free drinks, private offices, and khakis with button-downs, email names remained one of the iconic cultural identifiers of those days (and still used among alumni.) Given names no longer mattered at Microsoft. I was SteveSi. Cris Wittress was CrisWit—I finally got what she meant.

Before I started, Steven Schwartz had landed the name StevenS, a fact for which I was always jealous. After he left I even tried to secure the name, but there was a no-recycle policy. A coworker named Bill Gallagher was given BillGa, and for years he got crazy mail intended for (the real) BillG. As the company grew, it began to wrestle with the complexities of people getting married (or divorced) and how to deal with email name changes—much trickier than they’d imagine. Ultimately, in the late 1990s with the move to Microsoft’s email product, we finally moved to friendly names like steven.sinofsky@microsoft.com.

There was a list of email aliases (an early Unix-ism) to get help, like benefits, sickday, vacation, supply (office supplies), recept1 (recept2, recept3, etc. for the receptionists), stock (stock option sales), espp (employee stock purchase plan), payroll (for help with direct deposit), and, best of all, pcrepair, which could help with computer hardware. Perhaps that was second best, as I soon discovered library, which mailed the Microsoft librarians any topic to research or a request to send copies of articles or locate any book needed for work. There was an actual library filling most of one arm of an X in building 4, where I spent a lot of time as well. Everything was an email away.

Microsoft made about 35 different products back then, and I had personal experience with almost none of them. Importantly, by the mid-1980s, Microsoft moved beyond being a single-product company. It had substantial businesses in each of the major categories of the day: languages, operating systems, and applications. No single product represented more than half the company revenue. This early diversity was critical to Microsoft’s growth. In many ways, early software companies emulated record or book publishing by having many licensed titles for sale, and while early Microsoft followed this model it was now building most software in house.

The Systems group was the big group and was made up of the grown-ups. It felt to me the most like my summer aerospace job because there were people who were married (gasp!), and some even had children. This was the group that made MS-DOS, which was the single biggest moneymaker. They were also making OS/2, which was a massive joint project with IBM. There was a much smaller side project called Windows that was increasingly interesting. Unique to the Systems group was a much larger number of people who had joined Microsoft with years of prior work experience. There were people from IBM, DEC, ATT, HP, and a host of other computer companies from a previous era. Dave Cutler (DaveC), a legend with over 25 years of experience, had recently joined from DEC along with many of those colleagues. This made sense since building an operating system was something done at other big companies.

Languages was the history of the company and the oldest group. This was the group that made BASIC, as well as programming languages and tools from C to Pascal, Fortran, and, importantly, Assembler. The Languages products were for MS-DOS, Xenix (the commercial version of Unix, the ancestor of today’s Linux), and an expansion to OS/2 (an ill-fated joint development between Microsoft and IBM).

I thought many of the people I met in Languages seemed old. Some owned houses and had new cars. Some had been at Microsoft more than five years already.

Apps was the colloquial term for Applications, which is how the computer industry viewed programs used by end-users, versus the Operating System, which was required by the machine, or Languages used by developers. The Apps group was less tenured as it was both a newer business for Microsoft and seemed to have more college hires. Apps was almost a sleeper business even back then. Most of the products it made were for the Macintosh, like Word, Excel, and File, all of which were on the first or second version. Apps for MS-DOS were almost as numerous, but all were a distant number two in the market relative to software giants Lotus, WordPerfect, Ashton-Tate, and Software Publishing that I had used in my summer job during college.

I walked over to building 5 to find the private, interior office in which I’d begin my career. It had no exterior window but had one to the hallway. As I searched for my office, I passed the kitchen and saw the giant glass-door refrigerators filled with cans of every variety of Coke and Pepsi products like a convenience store.

It would be decades before I paid for a beverage.

Just across from the kitchen was the mail and copy room. This room had everything one could imagine needing for work. It was like a CompUSA and Office Depot all in one. Along with a big laser printer (and a copy machine), there were 5.25-inch and 3.5-inch floppy disks by the case, notebooks of every size writing paper (not computers which hardly existed in portable form at this time), printer paper, pens, tape (transparent and masking), thumb tacks, and more. There were boxes of colored pencils (legend had it that BillG used those to annotate code with different colors, but I later learned that was a myth). There were rulers for scanning across lines of code in landscape. Best of all were the staplers with the Microsoft logo on them. This was like a gift shop, and anyone visiting left with a box of floppies and one of those staplers.

After a few wrong turns, I finally saw the engraved door placard (think Mad Men) that read STEVE SINOFSKY. Not Steven. I was peeved. While I did not meet him for a few years, Steve Ballmer (SteveB) had something to do with this, I’m certain.

Later that morning, I met a fellow college hire named Antoine Leblond, a French-Canadian who was in a far worse position than me, as the powers had reduced him to TonyL. That only lasted until his then-girlfriend visited and, as an even more ardent Québécois, Lucie Robitaille somehow managed to get it changed to a cool alias: Antoine.

Offices back then were furnished in what could be described as Native Northwest. Think a solid wood oak 60-by-30-inch deep desk with a 24-inch typing return and a swivel chair with matching oak arms. There was a matching 60-inch high solid oak bookcase. A whiteboard and cork board were attached to the white walls. A 12-button analog phone in corporate brown was on the return, featuring my personal phone number, 206-936-7768 or x67768. The furniture reminded me of the make it as indestructible as possible stuff that filled the freshman University Halls at Cornell. Even if I was motivated to rearrange the layout of my nine-by-twelve-foot space, I could not because everything was so heavy. The setup was also horribly non-ergonomic by today’s standards. Still, by any measure of an entry-level office, it was amazing.

My bookshelf was pre-populated with, I later learned, standard-issue books for every new software design engineer hire. There was an Intel 286 and 386 reference along with a Motorola 68000 reference—everyone in software engineering understood machine architecture and instruction sets. A phone-book-size MS-DOS encyclopedia weighed down the shelf. There was also a dictionary and thesaurus, and a copy of the same Microsoft Press desk calendar featuring important milestones in computing and an MS-DOS technical reference card in the back that CrisWit had sent as a recruiting gift.

Importantly, there were two seminal works on programming, Fred Brooks’s The Mythical Man-Month and Programming Pearls by Jon Bentley. The former, I learned, was the most epic of all Microsoft struggles, which was trying to release products on time—by the summer of 1989 Windows was on the second version, having shipped 1.0 almost two years after public announcement. The latter book represented the hardcore ethos of Microsoft software engineering, which was tight code—what code could be written to solve the problem with the most clarity and fewest lines, least amount of memory, and fewest CPU cycles.

There was also a copy of The Hacker’s Dictionary by Guy L. Steele, a famous computer scientist partly responsible for the programming language Scheme used and developed at MIT. The book was a 1980s version of what was often called computerese though Microsoft had its own unique language. One other book seemed rather strange to me, Stewart Brand’s The Whole Earth Catalog, which seemed useful if I was intent upon producing my own energy or building a yurt, but definitely represented the tail end of the hippie culture of computing from which we all originated.

There was a Compaq PC and a terminal in the office. The Compaq was an Intel 386 chip running at 33 MHz with an extended memory card and hard drive. The terminal was hardwired to Xenix servers via a different network and where the email system was hosted. It was Xenix email, which itself was just a port of Unix mail. I was right at home shelling out to “vi” to edit mail as I had been doing since college. (vi as in visual editor abbreviated.) There was also an HP-16C Computer Scientist calculator, for handling all the hexadecimal and binary conversions I would need to do, but I already owned one.

I signed on and changed my password to one I used for the next 10 years or so until password policies came into vogue. I fired off emails to some old lab mates who were the only other people I knew using email. I didn’t hear back right away, which was weird. That was when I learned outbound mail was batched and sent/received twice a day. I was told Gordon Letwin (GordonL), the legendary MS-DOS and OS/2 engineer, was not in favor of being connected to ARPANET or BITNET due to security concerns (he was certainly ahead of his time) so this was the compromise. Emphasizing this, our first business cards had only phone and fax numbers and TELEX numbers (!). By special request, a UUNET address could be added. UUNET was one of the first commercial internet provider of email addresses. That summer, mine was still uunet!uw-beaver!microsoft!stevesi. Don’t ask. Microsoft used email for everything inside the company, but externally email was not yet a thing.

Turning on the PC, I was immediately greeted with a hung machine (back then we called them machines, not devices) unable to make it through the boot sequence. I received my first lesson in corpnet, or the corporate network. The network was reliable, but the software on the PCs was not. Hangs were frequent and the only fix was a power cycle. I was only familiar with Novell Netware and had not yet experienced a product in the same space that Microsoft had just released, LanManager, a.k.a. LanMan. I wasn’t alone. Almost no one had bought the product because it mostly didn’t work.

This brought my first experience with emailing helpdesk. By email, they asked me if I was an SDE. I wasn’t sure, and then I realized my title was software design engineer. The next mail said they were on the way.

A nice man with a pushcart filled with tools and gear to keep PCs running and connected showed up. He pulled a 5.25-inch floppy out of a plastic disk holder and began the process of a network boot, which was a fancy way of using a floppy disk to boot a computer and connect to the network. After a minute or so of grinding floppy noise, I saw the magic “C:>” prompt.

The tech began some magic incantations that were new to me, like NET USE to connect to a shared network drive. Then he began to install OS/2 1.1 and then applications, but there weren’t many. I asked where the printer was and he laughed. I learned OS/2 didn’t really print yet, and to do so I best to use MS-DOS and those apps, which he then set up (also using some new magic like mapping LPT1 to the nearby printer in the copy room).

Once my computer was set up, I still wasn’t sure what to do with my day, but it was lunchtime. I was never really good at lunch or spontaneously meeting new people, so I began to get stressed. I finally resigned myself to passing on lunch and futzing in my office. Then I heard a knock on my door.

“Hi, my name is Andy Craze . . . AndrewCr.”

We were both new, though Andy had started the week before, and we were both joining Apps (the team would soon move to Development Tools in my first of many re-orgs). As recent grads do, we exchanged where we were from, college, and major information. Andy was from Cleveland. Went to Stanford. Studied computer science. He also informed me he was a huge Grateful Dead fan. He was outgoing and suggested we get lunch.

What I didn’t know, until Andy explained it, was that we weren’t technically working at our actual jobs yet, or even sitting with our teams. Instead, we were in Apps Developer College (ADC). ADC was where new Apps SDEs learned how to be Apps SDEs. We would be there for an indeterminate amount of time while we learned the ropes—meaning learned the tools and techniques of the Apps division. If those few sentences sounded like a bunch of jargon, that’s essentially what every conversation sounded like.

Unlike today’s start-ups in Silicon Valley, lunch was not free but marginally subsidized by Microsoft and operated by an institutional food company. We went to the pizza station and I ordered by the slice.

I sustained myself on pizza for a decade.

On to 003. Klunder College

Subscribers head over to substack.com by clicking on the title of this email and join in the comments and discussions. If you received this from a friend, please consider subscribing.

Welcome. This is the first serialized section (yay!) The book is broken into 15 chapters and an epilogue. Each chapter has a number of sections, which are the posts you’ll receive in email. Occasionally I will add some context or an update at the top of a post like this. The Roadmap will maintain links to posts and will be an easy way to track the whole work. There will be additional posts and ask-me-anything threads (a Substack feature) which will also be mailed out and listed in the roadmap. The first posts are about what it was like starting as a new hire and a bit of an introduction to me.

PCs and software barely work, but the ascent of the IBM PC powered by Intel processors and Windows is underway. It is the start of the modern PC era as PC sales (from all manufacturers for the year) exceeded 20 million units worldwide, which is about half the worldwide sales of all personal computers to date including those from Apple, Tandy, Atari, and more. Looming, however, is platform competitor NeXT, the new computer company started by Steve Jobs. The dramatic extent to which that company will alter the technology landscape is decades from revealing itself. While Apple’s Macintosh is a competitor, it is also the foundation for Microsoft’s Applications business. The group I was hired into was squarely in the middle of both the new and old Steve Jobs platforms.

The whiteboard in my graduate school lab read, “Steven, Bill Gates called. Call him back.”

It was super weird to see that written because Microsoft wasn’t on our collective academic radar and most people didn’t know who Bill Gates was. Someone was clearly playing a joke on me. My college friend Brent grew up in the Seattle area and I had mentioned to him that I was interviewing at Microsoft, so it was probably him.

Later that day, I got home to find my PhoneMate microcassette answering machine flashing. There were two messages recorded. The first one was left earlier that morning as I started walking to the Lederle Graduate Research Center at UMass-Amherst where I was a second-year PhD student in computer science. A somewhat squeaky and distracted voice said, “Steven, um, this is Bill Gates calling. Can you call me back at . . . um . . . 206-882-8080?” The second message had been recorded later in the day. “Steven, yeah, this is Bill Gates calling again. I guess I called you at your lab like your message said, but you weren’t there either. When you get a chance call me back.” My outgoing message at home gave the number of the lab since that was the only other place, basically, that I spent time.

Brent’s ploy seemed rather elaborate. He kept it going for a couple of days as I kept getting voicemail messages claiming to be Gates. I did nothing.

As an undergrad I had written a program called MacMendeleev (after the father of the periodic table). I had been dying to write a Mac program after the incredible Super Bowl launch advertisement. MacMendeleev was the result of landing in an encouraging chemistry lab (thanks, Professor Clardy). As much as computer science classes made me finally feel like I was in the right place in life (thanks, Professor Teitelbaum), my chemistry classes were the exact opposite (B+ fall of freshman year was the highest grade I’d receive in chemistry in four years). The Mac was not a business computer, especially according to the advertisements by IBM, and they weren’t used in my classes. There wasn’t dBase II yet, as I had used earlier on my Osborne, and I wasn’t going to use Microsoft BASIC to write something from scratch. The Mac was, however, focused on education. The one thing I loved in chemistry was the periodic table. I dreamed up the idea of an interactive periodic table that could chart or graph the elements according to different properties to see what exhibited periodicity. I got some help from my lab mate, Tom Ball (a future Microsoftie), to help me with the graphics.

Surprisingly, MacMendeleev achieved a small amount of success. We signed up with the ever-present photocopy store Kinko’s that maintained an in-store kiosk that made copies of library programs. It was a software vending machine. The program was used in a few classes, and we made enough money on it to fund a cruise on Cayuga Lake.

The program also scored me an invitation to the 1988 Association of Computing Machinery regional gathering on Computers in Education. The conference loaned me a Mac to use, instead of the luggable PC I started using that I had acquired from my summers at Martin Marietta. The PC ran MS-DOS (Microsoft Disk Operating System), the software required for a PC to run and provide capabilities for other companies to write programs. It was the defining product for Microsoft in the 1980s and became the business engine that powered the company prior to Windows and Office.

I had never been to a conference and was not sure why I was there or what was going on, but I found myself sitting at a table talking about the periodic table, doing my first demos and booth duty. Apparently, I impressed the organizers enough to win an award. My prize was a just-released Color Macintosh. It was a huge score.

A representative for Microsoft approached me after my win, offering me some software, and asked me what I wanted…BASIC? I was heads down building Smalltalk on Unix, using TeX for papers, and using all GNU tools, but we agreed on a copy of Microsoft Word. I was excited but thought it was weird because everyone used WordPerfect on PCs and MacWrite on Macintosh, and I used LaTeX.

My first year of college I worked the night shift at a public computer lab filled with all sorts of new computers. There were PCs people could use (mostly grad students) for word processing and spreadsheets using WordPerfect and Lotus 1-2-3, an odd Apple Lisa the predecessor to Macintosh, several highly advanced computer graphics workstations used by physics students, in addition to the mainframe terminals, punch card readers, and refrigerator-size line printers I maintained. By early 1984, the first public Macintosh computers arrived, and I spent my Friday night shift helping people recover documents after the notoriously flaky MacWrite crashed and ate them.

Later, when I was applying for jobs (with the resume of a student who never really had a job), on a whim, I applied to Microsoft using the address on the Microsoft Word box I’d received. It was 16011 NE 36th Way, Redmond, WA 98052. I also sent my resume to Apple Computer. Like everyone I ever knew, I never heard back. They were like that back then (and still are, I am told). I think about a year later I got a postcard with a yellow Post Office sticker forwarded from Amherst to my current address letting me know my resume was on file.

I was fairly certain I was going to work in government service, as it was a popular trajectory for engineering graduates, especially those like me with some Russian language skills. There were multiple trips taken to undisclosed locations in the metropolitan DC area talking to the high-tech parts of three-letter agencies.

But then, two days after mailing it, a Microsoft recruiter named Cris Wittress called about having me come out to interview. She overnighted a plane ticket and a hotel booking. I was off.

The taxi ride to the hotel had a cutting edge feel to it. I was used to seeing important technical companies on Boston’s Route 128, like DEC, Data General, Apollo, and Banyan, but in Seattle, the names were all different: Apple, MicroRim, Egghead, Tektronix, and more (and oddly a McDonnell Douglas Aerospace building right next to Microsoft).

I stayed in the new Residence Inn, which was only a few minutes from the Microsoft campus, as it was called. It was a dreary February. I didn’t have a car and couldn’t figure out where anything was, but there was a Houlihan’s next-door so I had potato skins and fried cheese, as if I was still in high school. I got back to the room and decided to try out the fake log in the fireplace. Apparently, there was a chimney door or something, as I quickly set off the smoke alarm and caused a minor incident.

First thing in the morning, I put on my blue Brooks Brothers suit and headed over to building 1. I signed in in the lobby and was promptly greeted by Cris Wittress, who introduced herself as “Cris Wit” as though it were a nickname. The first sign of cool: She had an office. Come to think of it, everyone had an office—with a door. Fancy.

Cris briskly walked me through the day, describing the people I was going to meet and explaining that they were going to ask me technical questions and that was my interview. In one-hour slots, back-to-back, I met with a phenomenal loop of people who asked me coding questions, grilled me on architecture, and challenged my core assumptions. There was a fancy lunch and a fancy dinner that were typical of job interviews in the go-go 1980’s. Not so typical were the offers of beer at lunch and sake at dinner (at Benihana!) Most everyone on my interview loop was a recent graduate of Waterloo or Toronto. Along with the elite schools in the US these two schools were well represented in the Microsoft ranks.

I flew home the next morning. Cris called right away to tell me I had a job offer and sent me a rush version followed by a formal letter. The offer arrived overnight via Mailgram, an expensive, old-fashioned telegram (except it could be a full page). Mailgrams were used by big business before the internet, when the fax machine dominated offices (but students did not have one).

It happened fast. The offer was to work in the Applications Tools group. It was for $37,500 and had 1,500 non-qualified stock options, plus moving expenses. I called my uncle, who worked in investment banking on Wall Street, to ask what a stock option was. He told me and said mine were probably going to be worthless, but someday maybe they’d be worth $10,000.

Still undecided but leaning toward government work, one evening, late, I got a call at home.

“Hello, Steven . . . finally great to get a hold of you. My name is David Pritchard and I work in college recruiting at Microsoft. Bill Gates has been trying to get a hold of you, but it has been difficult. Can we set up a time tomorrow for you two to talk?”

David was one of Cris’s managers and leader of the college recruiting program (the success of that program is substantially owed to his early efforts).

Oops, I guess that really was Bill Gates before and not a prank.

When Bill and I finally spoke, the conversation was awkward, since neither of us were exactly good at chit-chat stuff.

“Hi, Steve, this is Bill Gates.”

“Hello. Thank you for calling, and so sorry for the confusion. I thought a friend of mine . . . ”

“So, David gave me this list of like ten people and I’m supposed to call all of them and convince them to work at Microsoft. You should come work at Microsoft. Do you have any questions?” (I always thought this was the best part of the call—him telling me he was just cranking through a list. Transparency.)

“I’m definitely excited and thinking about it. I don’t really have any questions.”

“Well, why haven’t you accepted yet? You have a good offer.”

“I’m considering other things. I have been really interested in government service.”

“Government? That’s for when you’re old and stupid.”

(No, really, he said that.)

“At Microsoft we have amazing things going on in multimedia. Have you seen all the things we are doing with CD-ROMs and video? We are going to make a whole encyclopedia on a CD-ROM, 650 megabytes with videos, maps, quizzes, and more.”

“I haven’t. I use a Macintosh and workstations. I used MS-DOS at my summer job and Windows 1.0, but it was pretty slow.”

“Well, Microsoft makes more money on Macintoshes than Apple does because of our apps—our word prosser [sic], Word, is super good. OS/2 runs in protect mode, which the Mac does not do. Do you have any more questions?”

“Not really.”

“I’m glad we got to talk. The offer is super good. Bye.”

After some failed negotiations on my part for more salary, I accepted and joined the Applications Tools group with Scott Randall as my manager. My start date was set for July 10, 1989.

The Seattle Times wrote an article in 1989 called “Inside Microsoft – A ‘velvet sweatshop’ or a high-tech heaven?” Cris mailed it to me, along with a flurry of fancy Airborne Express overnight envelopes I would receive over the coming weeks containing items meant to woo me including the Annual Report, a Microsoft Press Desk Calendar (with an ASCII table in the back), issues of The Seattle Weekly (to remind me of the cool music scene), and glossy data sheets on Microsoft products. The Times story chronicled the long hours people worked, including evenings and weekends. It talked about former employees referring to themselves as “recovering” Microsoft workers, but it also painted the picture of a creative, challenging, prankster-geek culture. The contrast and the controversy didn’t bother me.

What could be so bad about hard work that came with a private office, free Coke or Pepsi, and Lipton Soup?

Whatever was going on there, it was working well.

Microsoft finished fiscal 1989 as I was crossing the country to start my job. Despite a global recession and a market crash leaving company stock close to its IPO pricing three years earlier, it closed the books with more than $800 million in revenue (1989 dollars) and a market capitalization of about $3 billion. The company was already doing business in 50 or so countries with dozens of sales offices around the world—a testimony to the growth mindset of Bill Gates. The company had approximately 3,000 global employees. I was the latest of about 1,200 hired in research and development, mostly in Redmond, Washington. The Apps division was a still in the low hundreds of engineering hires, most from college, and most of those experienced on Macintosh.

When I joined Microsoft, I knew little about the company and even less about the corporate world in general. I was a kid fresh out of school, impatient and gung-ho to be a part of my new world, but equally inexperienced and a bit overconfident about what I was in for.

In the computer world Microsoft was well known but it wasn’t IBM or RadioShack. But most people I knew, including my family, were extremely fuzzy on what I was going to do and where I was going to do it. My grandfather was the only person in my family to have ever been to Seattle, and that was by stow-away train rides during the depression. I spent most family gatherings explaining what software was and that Seattle was not just a forest.

On to 002. SteveSi

In 1982, Time magazine named the personal computer Machine of the Year, marking the first time a non-human was awarded Man of the Year. It was a fascinating read, but like many nerdy kids across the country at the time, I’d already become captivated by computers.

My best friend Dave Crotty and our other best friend, Neal Fordham (collectively, the three of us were known as the boys), spent the previous year making mixtapes of ’80s punk and new wave on Dave’s father’s Bang & Olufsen component system.

When Dave’s brother Kevin got an Atari 800 computer, my curiosity piqued. I was mesmerized by this new machine—not by the video games I could play on it but by the presence of BASIC, the first programming language experienced by most everyone in the early days of personal computing. BASIC was thanks in no small part to Bill Gates and Paul Allen and their start-up originally known as Micro-Soft.

I gave up Space Invaders for rows of numbered lines. The timing turned out to be great.

Our family business was a retail store in Orlando, Florida. My Saturdays were spent calculating sales tax, doing inventory, and making change while chatting with customers.

Dave’s Atari gave me an opportunity to create my first program:

10 PRINT "Amount of sale?”20 INPUT sale30 LET tax = sale*.0440 PRINT "Merchandise: ", sale50 PRINT "Tax: ", tax60 PRINT "Total: ", sale+tax70 GOTO 10

As the family business evolved, my father, David, realized that turning it into a wholesaler was a great opportunity for the family. He decided to buy a computer to run it. I have no idea where the motivation for this came from and certainly knew the expense was significant ($1,800 then or about $5,000 in 2020 dollars). While our family had been early adopters (to some degree) of many modern household items—we had a fancy 35mm camera, a microwave, a Betamax, and even a big-screen TV—a computer, however, was puzzling. It was also an enormous privilege. Rather than a “toy” computer, of which the Apple ][, Atari, and the new Commodore 64K (64K!) were viewed at the time by those who claimed to know, my father invested in a business computer. He went to a computer store, staffed by people in suits and ties, and bought one of the earliest Osborne I computers.

The Osborne was a remarkable machine at the time and in the history of the personal computer. A nearly 30-pound “portable” (it didn’t even have a battery as portable meant you could relocate it) described as “the size of a sewing machine,” it had a 5-inch CRT screen that wasn’t large enough for a full 80 characters across, so using the CTRL key and arrows that panned the screen would allow someone to see the rest of it. It came with two 90K 5.25-inch floppy drives and 64K of memory. It ran the CP/M operating system (Control Program/Monitor), which at the time was vying to become the de facto standard.

It came with a bundle of “free” business software, including the WordStar word processor, the SuperCalc spreadsheet, a copy of the remarkable VisiCalc on the Apple ][, and two (!) different BASIC languages, MBASIC, which I later learned was Microsoft BASIC, and a faster variant, CBASIC. Notably, a “database” called dBase II was promised but did not arrive until later (“real soon,” the dealer told us).

Magazines were the early fountain of knowledge about the new computer because computers were not connected to anything else or any other computers. The monthly Portable Companion, the first issue, free with the computer, was filled with tips and tricks for using the Osborne and the bundled software. I dutifully filled out reader response cards and soon had a library of code samples I could type in and printer configuration codes. I read Dr. Dobb’s and BYTE at B. Dalton Bookseller in the mall instead of playing games.

I set up the computer in the tiny extra room that served as the TV room for my sister and me, much to her chagrin. The noise created by the combination of typing on the full travel keyboard and the constant grinding and clacking of the floppy disk drives, not to mention the loud beep at power-on and whirring fan, took a toll on my younger sister, Jill. Through our lightly constructed 1970s Florida ranch house, I heard her repeatedly whine, “Stop clicking . . . stop beeping.”

I was undeterred.

My father and I spoke twice about the computer. The first time was when we bought the computer for the business and I was left to figure out how to “put it to work,” whatever that meant in 1981. Second, after a few months, when I was not making enough progress, he basically said he was firing me and he was going to hire a professional, whatever that meant. But that second conversation lit a fire under me.

I spent a month or two using CBASIC to build an inventory program for the wholesaler. I had no idea how a database worked, what a database table was, or anything like that. There were enough example programs for managing “lists” in CBASIC for me to figure out how to modify them.

Probably just in time for my father’s loss of patience with me, I was rescued by the delivery of disks and manual for dBase II. After a few hours of using it and going through the typewritten photocopied documentation that came with it, a whole new world opened up for me. I immediately began building an entire system for the business.

A tribute to the power of dBase II more than to any skill I had, it took only a few weeks to get accounts, inventory, payables, and invoicing up and running. My father was relieved. I began the job of manually inputting the names and addresses of hundreds of customers and thousands of products.

To store all the data that did not fit on a 90K floppy, I spent weeks evaluating a 10-megabyte hard drive to add to the second Osborne bought for the business (one remained at home for me to program and the other ran the business). The 10-megabyte drive was the size of our Betamax and sounded like a small aircraft, but it dramatically changed how the business could be run. Imagine something like 100 floppies running all at once. It was magic. And it was fast!

Along with dBase II, the “300 baud modem” that promised to unlock the world of connecting to other computers over telephone lines was also delayed. When it finally arrived, I added a new sound to the clicking and clacking, the audible modem handshake that later came to symbolize “online.”

At first, there wasn’t much to dial-up except expensive per-minute professional services that were out of my price range and required a credit card I did not have. After a lucky meeting at the local CP/M User Group (CPMUG, as it was called) where I was the youngest by at least 10 years and the only person there not (yet) working at Martin Marietta or Kennedy Space Center, I learned about FIDONet.

I was finally online. And then I was online all the time (using the second home phone line I received for my Bar Mitzvah).

That connected me to user groups, forums, and others writing and exchanging programs. I felt like I was on a new learning curve as every night led to another discovery. Sometimes I learned the arcane aspects of CP/M, such as how to edit the OS code to disable the File Delete command (to make using the computer safer for my father) or to customize WordStar for our printer so it would print “double wide” characters for fancy headings. Other times, I learned some sophisticated dBase II constructs like keeping multiple tables connected and in sync for reporting. It was also in an online forum that I learned about the IBM PC and how it was going to be the winner between it, CP/M, TRS-80, and Apple Computer, the other ever-present computer systems.

So much was changing in such a short amount of time. That year fewer than two million PCs built by dozens of companies were sold, each computer running different and incompatible software, as if early automobiles needed different roads for each car maker. A year earlier, IBM introduced the IBM PC and was welcomed to the PC Revolution by five-year-old Apple Computer in a full-page advertisement in the Wall Street Journal.

It was early in the PC Revolution.

Cornell University’s computer science program, one of the first in the country, started in 1965, the year I was born. As 1982 wound down, I was admitted to Cornell.

Prompted by that Time article, my mother, Marsha, told me that computers were a fine hobby, but she reminded me that I wanted to be a doctor. I received a good talking to once she read the descriptions of “hacker” culture—flannel shirts, no shoes, and working late at night in the solitary computer room of the nation’s colleges. It all sounded too close to late-night beeping and clicking. She wanted assurance that I was attending Cornell to study something more in line with what was expected, what I wanted. She was concerned that I might become a “hacker.”

Too late.

On to 001. Becoming a Microsoftie (Chapter I)

Welcome to Chapter XIV. This is the first of two chapters and about a dozen remaining posts that cover the context, development, and release of Windows 8. Many reading this will bring their own vivid recollections and perspectives to this “memorable” product cycle. As with the previous 13 chapters and 96 posts about 9 major multi-year projects, my goal remains to share the story as I experienced it. I suspect with this product there will be even more debate in comments and on twitter about the experiences with Windows 8. I look forward to that. This chapter is the work and context leading up to the plan. Even the planning process was exciting.

Back to 096. Ultraseven (Launching Windows 7)

In the summer of 2012, I was sitting across from BillG at the tiny table in the anteroom of his private office on the water in Kirkland. The sun was beaming into my eyes. In front of me was one of the first boxes of Microsoft Surface RT, the first end-to-end personal computer, general-purpose operating system, and set of applications and services designed, engineered, and built by Microsoft. In that box sat the culmination of work that had begun in 2009—three years of sweat and angst. After opening it and demonstrating, I looked at him and said with the deepest sincerity that this was the greatest effort and most amazing accomplishment Microsoft had ever pulled off.

Later that same week, I had a chance to visit with Microsoft’s co-founder, Paul Allen (PaulA), at his offices at the Vulcan Technology headquarters across from what was then Safeco field. I showed him Surface RT. I previously showed him Windows 8 running on desktop using an external touch monitor. At that 2011 meeting he gave me a copy of his book Idea Man: A Memoir by the Cofounder of Microsoft and signed it. Paul was always the more hardware savvy co-founder, having championed the first mouse and Z80 softcard, and had been pushing me the whole release of Windows 8 on how difficult it would be to get performance using an ARM chipset and on the challenges of hitting a low-cost price point. Years earlier, Vulcan built a remarkably fun PC called FlipStart, which was a full PC the size of a paperback novel. Surface RT with its estimated price of $499, $599 with a keyboard cover, and a fast and fluid experience, resulted in the meeting ending on a high note. I cherished those meetings with Paul. I also shared with Paul, proudly, my view of just how much we should all value the amazing work of the team.

What I showed them both was the biggest of all bets. While not “stick a fork in it” done, by mid-2012 Microsoft seemed to have missed the mobile revolution that it was among the first to enter 15 years ago. In many ways Surface RT set out to make a new kind of bet for Microsoft—a fresh look at the assumptions that by all accounts were directly responsible for the success of the company. Rethinking each of those pillars—compatibility, partnerships, first-party hardware, client-computing, Windows user-interface, and even Intel—would make this bet far bigger and more uncomfortable than even betting the company on the graphical interface in the early 1980s. Why? Because now Microsoft had everything to lose, even though it also had much to gain.

With Windows 7, we knew we had a traditional release of Windows that could easily thrive through the full 10-year support lifecycle as we had seen with Windows XP. Windows 7 would offer a way to sustain the platform as it continued to decline in relevance to developers and consumers, while extracting value from business customers with little incentive to change.

Microsoft needed a new platform and a new business model for PC makers, developers, and consumers. The only rub? Any solution we might propose wasn’t something we could A/B test or release pieces at a time experimentally. Windows was the standard and wildly successful. It wasn’t something to experiment on.

While the company was 100 percent (or more) focused on Windows 7, we had started (drumroll for the codename please) Windows 8 planning five months earlier. We had the next step, a framing memo from me first. Then we had a planning memo from JulieLar, ready to go as soon as we all caught our collective breath after the release—no real time to celebrate more, and certainly no downtime.

Technology disruption is often thought of at a high level along a single dimension, but it is far more complex. Consider Kodak’s encounter with digital photography, Blockbuster’s battle with DVD-by-mail, or the news business’s struggle with the web. Great memes, sure, but one layer down each is a story of a company facing challenges in every attribute of their business, and that is what is interesting and so challenging.

Digital photos were more convenient for consumers, that was true. But also, the whole of Kodak was based on a virtuous cycle of innovation developed by chemical and mechanical engineers, products sold through a tightly controlled channel, and an experience relying on a 100-year-old tradition of memorialized births, graduations, weddings, and more. At each step of technology change to digital images, another major pillar of Kodak was transformed, sliced, and diced in a way Kodak could not respond. The magical machinery of Kodak was stuck because not one part of its system was strong enough to provide a foundation. Kodak didn’t need to also enter the digital market. The only market that would come to exist was digital. The only thing that made it even more difficult was that it would take a decade or more to materialize as a problem, and that during that time, many said, “Don’t worry. Kodak has time.”

While figuring out what to do next for Windows, we saw Blackberry facing a “Kodak moment.” Blackberry was not just a smartphone, but a stack of innovations around radios, a software operating system optimized for a network designed for small amounts of data consuming little power, a business model tuned to ceding control to carriers, and a keyboard loved by so many. In 2009, Blackberry still commanded almost 45 percent of the smartphone market, even though the iPhone had been out since 2007. That led many to find a false comfort in the near term and to conclude Blackberry would continue to dominate. Apple’s iPhone delivered a product that touched every pillar of Blackberry, not only Blackberry the product but Blackberry the company. Sure, Apple also had radio engineers, but they also had computer scientists. Sure, Apple also worked with AT&T, but Apple was in control of the device. And Apple was, at its heart, an operating system company. Blackberry had some similar elements up and down the entire product stack, but it wasn’t competitive. At its heart, Blackberry was a radio company. Blackberry seemed to have momentum, but market share was declining by almost 1 percentage point per month.

The smartphone, iPhone and Android in particular, was disrupting Windows. Though, not everyone thought that to be the case. Some said that phones did not support “real work” or “quality games.” The biggest risk to a company facing disruption is to attempt to dissect disruptive forces and manage each one—like add touch or apps to a Blackberry with a keyboard. The different assumptions and approaches new companies take only strengthen over time, even if eventually they take on characteristics of what they supplant. The iPhone might never be as good as the PC at running popular PC games, but that also probably won’t matter.

I’d lived through graphical operating systems winning over character mode, PC servers taking over workloads once thought only mainframes could handle, and now I found myself facing the reality that browsers could do the work of Windows, relegating Windows to a place to launch a browser and not even Microsoft’s.

Every aspect of the Windows business faced structural challenges brought on by smartphones. Compounding the challenge, Apple was competing from above with luxurious and premium products vertically integrated from hardware to software. Google, with Android and Chrome, was competing from below with free software to a new generation of device makers. The PC and the struggling Windows phone were caught in the middle, powerless to muster premium PCs and unable to compete with a free open-source operating system.

The browser had already shifted all new enterprise software development away from the hard-fought victory of client-server computing. Anyone who previously thought of building a new “rich client” application with Visual Basic or some other tool was now years into the transition to “thin client” browser software. The Windows operating system was in no way competitive with smartphone operating systems. The way to develop and sell apps had been reinvented by Apple. The Win32 platform was a legacy platform by 2009, the only debate was how long that had been the case. A legacy platform does not mean zero activity, but it does mean declining and second or third-priority efforts.

The partnership between the Windows operating system and hardware builders had fundamental assumptions questioned by Android. OEMs supporting Android not only received the source code but were free to modify it and customize it to suit their business needs. That was exactly what Microsoft fought so hard against in the DOJ trial. The touch-based human interaction model developed by Apple and the large and elegant touchpad on Mac were far more approachable and usable than what was increasingly a clunky mouse and keyboard or poor trackpad on Windows. The expectations for a computer were reset—a computer should always be on, always connected, never break or even reboot, free from viruses and malware, have access to one-click apps, while easy to carry around without a second thought. That supercomputer in your pocket is connected to built-in operating system services providing storage, backup, privacy, security, and more. Like Kodak, many said to slow down, that change would not happen so quickly. Many said we could “add this” or “change that.” But it was not that simple, nor was it going to be that easy. The market was moving quickly.

The march to the next billion shifted, in the blink of an eye, to smartphones and soon non-Windows tablets, entirely skipping the PC. The entrenched PC customers were as excited as ever to upgrade to Windows 7 by buying a new PC or upgrading their existing PC. Everything new in Windows 7 was viewed through the lens of the past. How did we used to do that and did Windows 7 make it easier? Those skipping the PC didn’t concern themselves with improvements in a new version of Windows because they didn’t know about the old version. PC enthusiasts were still asking for features to handle managing files and keeping multiple PCs in sync while phone or browser users were seamlessly connected to a cloud and gave no thought at all to where files were stored. Buying a second iPhone or replacing a broken one proved astonishingly simple, because of the integration with services.

Microsoft’s answer to iPhone and Android 1.0 was still being developed. Windows Phone 7, originally codenamed Photon, would be released a year after Windows 7. The mobile team was heads down trying to get that release done, which had been in the works since Windows Mobile 6.0 shipped in early 2007. By the time Windows Phone 7 shipped, the Windows 8 team would have completed the first of three milestones. The next full chapter will detail the challenges this lack of synchronization created. We had Windows Phone 7 on a mission to get to market and compete and in doing so was pre-booking the next release; Windows 8 attempted to plan a major release that in theory would lend support to the mission of modernizing the codebase which was desperately needed by Windows Phone 7 competing with the modern Linux kernel and OS X.

Meanwhile, there were few new customers being brought to the cash-producing business of the Windows PC. There we were with the metaphorical Sword of Damocles hanging above us. The best days of the PC were behind us. It wasn’t just obvious technically—the value propositions of mobile devices were in no way compatible with the Win32 and PC architectures. The only question was when things would truly turn for the worst.

The risks were infinitely high. We could do something radically different, potentially choosing wrong and heading right into failure even accelerating what was inevitable. Or we could slow walk as long as possible, releasing incremental features for as long as possible hoping to find some future solution to our quagmire. Doing both is a classic upper management answer that with near certainty results in a combination of a bloated and confused near term that keeps trying to pull features from the new, and a brand new product that develops a major case of second-system syndrome. The latter is a classic defined in the standard developer book Mythical Man-Month, and what we experienced with numerous Microsoft projects from Cairo to Longhorn when the next generation attempts to solve all known problems at once.

It is why so many default to preserving the cash cow as the most logical strategy, maintaining the success already achieved. Usually this comes with raising prices along the way for existing customers, who are by and large captive. In the short term, things continue to look great, and a crisis will be averted while the crisis is left to a future team. In fact, in the short term our most ardent fans would continue to carry on as though everything is normal. They are part of the same bubble as us.

Either way, the world outside of the Windows PC shifted to mobile. We were at a fork in the road and had to pick a direction.

The thing about disruption when it is happening is that you alternate between over-confidence and paranoia. Financially, the Windows PC was secure. Emotionally, the Windows PC was fragile. From a product perspective, not only was there little left to do on the current path but doing anything would annoy both the disinterested customers and ardent fans more than it would encourage them or any new buyers. Over-confidence leads one to incremental plans, assuming the existing business is so strong as to not worry. Paranoia makes it difficult to identify the precise nature of disruption and to calibrate a response.

For all the insights that Innovator’s Dilemma captured, the one thing it did not seem to predict was that even after disruptions companies can continue to make vast sums of money for years to come from those disrupted products. Technologists tend to think disruption causes products to sort of go away, but as any private equity investor will tell you, that is not the case. That’s why a misplaced confidence in incrementalism almost always wins out over a bold, risky bet, at least for a while.

We were determined to find a way to do better than to slowly lose relevancy as we’d seen happen to IBM.

Planning Windows 8

We kicked off a planning process just as had been done for all the other releases described in this work—from Office 2000 all through Windows 7. By now this team had fifteen years of product planning and results that had transformed a set of bundled applications into a suite of interconnected products and then to a platform of products, servers, and services, and then reinvented the user experience setting these tools up for at least another decade. We then aimed this same process at the challenges of the Windows business, and by all accounts set that product up for another decade.

About three months before Windows 7 released to manufacturing, I sent out the first step in planning Windows 8, the obvious name. “Building on Windows 7” outlined the state of the business and product, suggested where we would invest for the next project, detailed competitive threats, and defined what success would look like.

As with all the other framing memos I wrote, this one began upbeat. How could it not? The release of Windows 7 was a super positive experience for the team, the company, and the broad ecosystem. The memo celebrated all we accomplished as a team and with Jon DeVaan’s leadership significantly improving our engineering capabilities and productivity. Promise and deliver.

Then the reality. The recession had slowed the growth of PC sales and analysts were taking forecasts down. The damage netbooks had done to pricing leverage was significant, resurrecting the Linux desktop and lengthening Windows XP in market. Netbooks also masked the secular weakness in PCs that was also seeing as lengthening of the PC refresh cycle in large companies. PCs were being tasked to last longer without loading a new version of Windows or Office. Emerging markets and software piracy were proving highly resistant to most every effort. The sabbatical I took living in China in 2004 taught me firsthand just how impossible it was going to be to thwart piracy of desktop Windows and Office, our primary sources of revenue. Windows Live was, as we say, making progress, but Google was making much more progress much faster, and our marquee products, Hotmail and Messenger, were losing share and fast. Releasing SkyDrive (now OneDrive) with excellent integration of the new Office Web Applications (Word, Excel, PowerPoint running in the browser with compatibility with desktop Office) was a significant bright spot, but it came with very high operational costs and immense pushback from Office that feared cannibalization. There were even changes in how PCs were being sold that were proving highly problematic. OEMs were increasingly relying on nagware or trial products, bloating the PC user interface, and putting a ton of pressure on the overall experience of Windows. The retail channel, struggling from the recession, was anxious because they had not yet mastered selling smart phones, the hot category, which increasingly looked like a carrier-specific play. This in turn caused retailers to become part of the equation of pre-loaded software, thus further eroding the experience.

Competitively, all I asked us to focus on was Apple and Google. Most would see Apple as a competitor through OS X, but as discussed OS X was now powering iPhone. The framing memo was not a plan nor was it even a plan for a plan, rather it serves to bound the release and help encourage the team to focus on specific technologies, competitors, and challenges. There was much for the team to collectively learn. At the time, I summarized Apple competition as follows:

Apple.  Apple OS X is a very strong product coupled with amazing hardware.  The transition Apple has made from OS 9 to a modern OS architecture on Intel hardware is on par with the transition we made to both the NT code base and to 64-bits.  From an OS technology perspective we see the strength of OS X among universities and administrators who find the Mac (Mach-based) kernel and associated shell, tools and techniques “comforting”.  From a user experience perspective, we cannot be defensive about the reality that Mac hardware + OS X + iLife continues to be the standard by which a PC + Windows 7 + Windows Live will be judged in terms of technology, and then [sic, how] the purchase experience, post-sales experience, and ecosystem have grown to be considerable strengths.  While we have only some details, the hygiene work being done on Snow Leopard is likely to generate significant positive views as the OS becomes “leaner and more streamlined” and likely claims about being more modern with respect to graphics, 64-bits, and user-interface.  As we describe below, the sharing of code and architecture, particularly for important strategic elements of the OS, between the iPhone OS and Leopard is technically interesting and certainly responsible for some elements of the platform success.  Apple is not without blemishes, but in planning Windows 8 we must focus on their strengths and assume they will continue to execute well on those.  Being deliberate and informed about competing with Snow Leopard and, relative to iPhone, making sure we build on the assets of Windows for our Windows Phones should be strongly considered.

Rather than describe Android directly, I chose to consider Android as another variant of Linux. At the time, the only Android phone was the convertible Blackberry-like device, the HTC Dream. Android 2.0 with full support for multitouch would not release until Windows 7 launched to market about three months later. Note the caution about Google control of Android expressed even then—it was obvious this would be a tension point down the road. In this context the competition with Linux also included desktop Linux:

Linux.  Like so many competitors we have faced as a technology company, just as we thought “this one won’t reach critical mass” we saw two events provide a breath of life into “Linux on the desktop”.  First, the rise of Ubuntu, both the technology/packaging and the “movement”, has created a rallying cry for OEMs and for the Linux community.  Second, the low-cost PCs that initially came with Linux (due to the footprint “requirements”) created a new incentive for OEMs/ODMs to find a way to make it work.  While we were effective in establishing a value proposition for Windows XP on these PCs, the seed that was planted will continue to be revisited by PC makers and designers.  They appreciate the potential for business model innovation, componentization, tailoring, and also the opportunities to differentiate using the open source aspects of the OS.  It is worth noting the reality that Linux on the server continues to dominate in many important workloads and the server plans are going to inform the planning of the base OS work such that we are extremely focused on defining specific scenarios where we make significant competitive progress with Windows 8 against Linux on the server.  Within the context of Linux it is especially important to call out Google Android which will likely be funded by Google for some time and represents an OS choice for mobile phones and phone architectures encroaching on the PC “from below.”  Android can provide OEMs with the opportunities similar to Ubuntu, however Google is walking a careful line in providing Android where they can possibly lower costs for OEMs, or even subsidize the bill of materials for a device, counterbalanced by OEM wariness that Google will take too much control of additional revenue streams.

Perhaps most importantly were the two “non-traditional” competitors: “Browsers” and “Phones/Alternative Architectures.” The rise of Google Chrome was proving highly problematic, not just because of the loss of share, but because of Google’s determination to add anything and everything from a PC to a cross-platform browser runtime, which is still going on to this day.

The view of the phone is much more interesting considering how the world evolved. Speculating about Android would prove accurate in just a few short months. I was deeply concerned about the PC ecosystem and the potentially rapid convergence of PC and phone hardware in the direction of phones, as well as Apple’s unified OS strategy. This was in stark contrast to where Microsoft began its mobile journey a dozen silicon-years earlier and where it was today.

Phones and alternate architectures.  The iPhone is referred to by many as a new form of portable computer—“it has a real OS” many have said in reviews.  The Google G1 phone running Android is likely to be made available in more PC or “handheld” form factors beyond the single-handed in-your-pocket screen.  The desire for the ultimate device that has the power and capabilities of a PC along with the convenience of always on wireless connectivity is beyond alluring.  It is what we all want as consumers.  To deliver on such a vision many might say that Windows can never power such devices—perhaps that is a statement about “business model” or a statement about technology.  Sometimes it is just competitors declaring “[Big] Windows will never be on a phone”.  The reality is there was a time in the history of Windows phones (CE, PocketPC, etc.) where the synergy between “little” Windows and “big” Windows was technically robust in reasonable ways.  For a variety of reasons we diverged.  Today we have hardware designers and phone company customers facing a choice between the OS that supports phone networks, voice, and other “phone” scenarios super well, but does not have the rich ecosystem support of Windows 7 and runs on a small set of hardware chassis, and Windows 7 running on a mainstream hardware platform with broad ecosystem support and openness.  These platforms differ in bill of material costs, power consumption, and so on.  Much like the “browser is all I need” statement there is a significant amount of extrapolation that both excludes Windows and assumes the Windows platform cannot compete.  Our chip partners for Windows are working hard on bringing the x86 architecture “down” and we need to be there with Windows software.  And at the same time we will strongly consider how to run Windows on alternate hardware platforms and learn what that would entail—we will work to bring “big” Windows to mobile chipsets, but we have significant groundwork to do before we know the practicality of such an investment.  Our Windows 8 planning will most certainly take into account the role of sharing new code across Windows and Windows Phones, starting with the latest Internet Explorer as we are already working on.

There were several technology bets in the framing memo, putting stakes in the ground for how we would think about significant efforts on the deeper technical challenges of the release including a big effort to evolve the PC. While I don’t want to fast-forward, these abstract definitions are what will lead to the work on ARM processors (see emphasis above), a new application model, and ultimately first-party hardware.

The technology bets on evolving the PC included:

* Mobile Devices

* Converged OS between Windows PCs and phones

* Mainstream PCs and the market turn to laptops

* High-end PC form factors such as meeting room PCs

* Shared computing PCs such as we were seeing with remote desktop and cloud computing

Taken together with the work on cloud, the memo defined the “Modern Windows Experience” as including the following (the original even included a fancy Office Art depiction). The use of “modern” will become a touchstone of the release and how we describe Windows 8:

* Base operating system: the OS kernel, device management, connectivity, and storage

* Graphics, Presentation, and Interaction: the visual aspects of Windows including the APIs used by applications and the end-user experience

* Browsing: the technologies required for browsing the web, but also how those will be reused across the platform to build rich applications

* Windows “Form Factor” Experience: tuning the experience for different types and sizes of computers from handheld through laptops and desktops to servers and alternate form factors such as tablets and wall computers

* Windows Live: the broad set of cloud-based services that complete the Windows experience including identity, communications and messaging, storage, and sharing

As with past releases the framing memo went out to the whole Windows team. The bulk of the team was super focused on shipping Windows 7 and mostly appreciated the informational aspect of the memo. The real work for program management began with JulieLar’s “Windows 8 Planning Memo” which she sent to the entire team just after Windows 7 RTM for most worldwide markets. The purpose of the framing memo was to establish the “bounding box” for Windows 8 and bring together the best of top-down, bottom-up, and middle-out planning. The framing memo was the top-down step. The planning memo develops potential themes for the release and explores those.

Julie outlined the following planning themes which would then be the structure used to facilitate brainstorming, prototyping, and then ultimately the product vision:

Blending the Best of the Web and the Rich Client. Recognizing the declining role of Win32 development and the increasing dominance of web development and associated tooling, this area asked to develop solutions to building an engaging and useful platform for developers. What kinds of apps do they want and how would they be distributed? How could the capabilities of Windows enhance what we see as limited web applications?

Defining a Modern PC Experience. Julie wrote, “The basic elements of today’s Windows user experience—the Desktop, Taskbar, Start menu, and Explorer—were introduced in Windows 95, and their success has made Windows the world’s most familiar computing environment. But today’s modern world is in many ways different from the mid-1990s world in which Windows 95 was designed.” This area asked nothing less than to bring the Windows user experience up to a level that would support existing scenarios and provide a better solution for the next billion customers who see the smartphone as their first and potentially primary computing experience.

Extending the Reach Of Windows. The Windows model of licensing and OEMs served us extraordinarily well, but with the rise of smartphones there were new revenue opportunities and sales models for Windows that can be supportive of reaching the next billion customers. Key among these was the role of mobile operators (“telcos”) in the sales process.

Connecting to Windows From Anywhere. Typically, the PC of 2010 operated in a world where everything is on the PC except what is viewed through a web-browser. PCs could be greatly improved by making use of cloud services available with Windows Live to make all your files, settings, communication, and collaboration easy from any PC or device. What role could the cloud play? Synchronization across devices was something the company has tried many times before though we had limited success. How could it work this time?

Helping IT to Deliver Work Anywhere Infrastructure. Most of Microsoft’s revenue and much of the upside opportunity came from doing a fantastic job for enterprise IT. This theme asked questions about deployment, security, encryption, and even the mundane such as how to easily replace a lost, stolen, or broken PC.

Showcasing Quality the First 30 Days and Over Time. This area asked what have historically been the most intractable of questions about Windows. “The burden of ensuring that a new PC is running as well as it should is placed on the customer who purchased it.  As a result, the first days of usage, rather than being a period of exploration and fun, were often prove to be labor intensive and exasperating.” Julie added, “Making matters worse, Windows itself is not running at its best during the first days of ownership.  …Windows performs all of its initial self-tuning and post-out-of-box-experience tasks during this critical time.”  When compared to what customers were starting to see with smartphones, Windows looked downright archaic.

Synthesizing these together into the vision was the next step. While most of the planning team were brainstorming and prototyping, we had some significant engineering work going, the success of which would prove crucial in enabling our ability to achieve a breakthrough Windows 8, such as working out the feasibility of Windows on ARM.

A bigger worry, did we set out to do too much? We knew that the team would naturally gravitate to ideas that made the PC better in incremental ways. We also knew some people would push hard on extremely bold ideas. The risk for any large organization is obvious…trying to do too much. The less obvious risk…ending up with a plan that is a too much of the old and a little bit, but not enough, of the new. Inertia is one of the most powerful forces in a large company.

I was worried. We only wanted to spend a few months “just” planning, still an enormous undertaking. Windows 7 shipped in August, with this planning memo and associated work taking most of the Fall. It was looking like we would start the project in the Spring of 2010, which meant an aggressive RTM of Windows 8 in the summer of 2012. Still, that would be exactly three years between releases, something never accomplished before. Promise and deliver.

On to 098. A Sea of Worry at the Consumer Electronics Show

In the era of “boxed” software release to manufacturing was a super special moment. The software is done, and the bits permanently pressed onto a DVD disc. That disc, the golden master, is then shipped off physically to duplicators around the world and then combined with another artifact of the era, a box or in the case of Windows 7 a plastic anti-theft DVD contraption. While Windows 95, the excitement of computing and the newness of internet set a high-water mark for launch events, the completion and launch of Windows 7 was a major worldwide business event. The industry was looking for optimism as we emerged from the Global Financial Crisis and the ensuing slump in PC sales. Windows 7 was just the ticket and the launch would prove to be part of a massive uptick in PC sales or as some hoped a return to ongoing up and to the right curves. But could that really be the case?

Back to 095. Welcome to Windows 7, Everyone

The months after the PDC were extremely intense. We had set out to promise and deliver, but the success of the PDC had managed to inflate expectations. These were not false expectations—the use of the product was widespread and broadly satisfactory. That success is what raised expectations. PC makers, Wall Street, OEMs, and enterprise customers knew the product to deliver and were not just impatient.

We made a significant number of changes from M3 to beta. With our improved engineering system changes were made in a controlled though collaborative manner. Each change was discussed by many people and then the code change reviewed—no holes punched in the wall. With each passing day it was more difficult to make changes while we aimed for stability of the beta. The most important thing about shipping a beta is not that it is perfect but that it ships in a known state. If something isn’t right that’s okay, as long as it’s known. In the case of Windows 7, we knew work and bugs remained but were highly confident that millions of people would try out the beta and have a great experience.

That methodical crawl to beta went on for weeks, each day making fewer changes and calmly making it to sign-off. Then it was time to ship the beta.

On January 8, 2009, at the Consumer Electronics Show in Las Vegas, SteveB announced the availability of Windows 7 Beta. The venue and the announcement from the CEO made this a significant worldwide event. It was covered on CNN, BBC, and more. That was exciting and even felt a bit like old times for a moment.

I watched from back in the green room because we were getting ready to turn on the web site for download and had no idea what to expect. While the internet was old news, downloading a gigabyte DVD image was hardly routine, especially from home and not something the internet was yet equipped to handle reliably.

To have some sense of control, we set a limit of 2.5 million downloads. Back then, before everyone had gigabit internet at home, a massive gigabyte download was something that would stress out the internet. As the keynote was going on we watched downloads begin. They quickly reached our limit while the keynote continued. A few calls to Redmond and we removed the throttle and began to rewrite our press releases with ever-increasing numbers. We extended the beta downloads through the end of January and had many more millions of installs than downloads as the download made it to all sorts of alternate and backup sites. We also learned a lesson in distributed computing that day.

For the beta we issued unique product registration keys which became the scarce resource. We soon removed the limits on activating those keys as well. While the download site was structured to choose 32- or 64-bit along with locale to then generate a key, many figured out the URL that went directly to the 2.5GB download and passed that along. We just didn’t want to be overwhelmed with Watson and SQM data so capped the release at 2.5 million. That was silly but at least we received an indication of the excitement. There was a lot!

Every day we tracked bugs with Watson and observed usage with SQM. Hardware vendors were providing updated device drivers that were anxiously downloaded by millions of testers, many seeing new drivers arrive automatically by Windows Update. More new PCs would arrive to be qualified. More legacy hardware would be retested. More of the over 100,000 apps in the wild would be checked for compatibility. More enterprise customers would tell us that they were anxious to deploy Windows 7.

Many reviewers chose to review the Beta as though it was final or at least something regular people might care about. It would be easy to gloss over this but for me it was an important part of promise and deliver. It had been a very long time, perhaps never, when a first beta for Windows was considered broadly usable and also had customers asking if it was okay to deploy even more broadly. Promise and deliver.

David Pogue, hardly a fan of Windows, practically filled an entire page of The New York Times with his review “Hate Vista? You May Like Microsoft’s Fix” where he concluded “For decades, Microsoft's primary strategy has been to put out something mediocre, and then refine, refine, refine, no matter how long and no matter what it costs, until it succeeds. That's what's exciting about the prospect of Windows 7. It's Windows Vista - with a whole heck of a lot of refinement.” Microsoft was back to making sure it got products right.

In The Wall Street Journal, Walt Mossberg said in another front page of the business section review “Even in beta form, with some features incomplete or imperfect, Windows 7 is, in my view, much better than Vista, whose sluggishness, annoying nag screens, and incompatibilities have caused many users to shun it. It's also a serious competitor, in features and ease of use, for Apple's current Leopard operating system.” He also posted a video review as part of some of his more recent work creating video reviews.

All we needed to do was finish.

By July 13, 2009, build 7600 was pronounced final and signed off on by GrantG and DMuir, the test leaders for WEX and COSD.

Windows 7 was ready for manufacturing.

July 9, 2009 was also my 20th anniversary at Microsoft and the team help me to celebrate by dressing like me—jeans, v-neck sweater, t-shirt. At least I was predictable.

Shortly thereafter at a sales kickoff in Atlanta, the annual MGX, we surprised the global field sales force and created a media moment when SteveB, KevinT (COO), and I held up a “golden master” DVD (a gold DVD), symbolically signing it as we announced that Redmond had signed off on the Windows 7 RTM build. It was a release that 10,000 people worldwide had contributed to and would likely end up on over 1 billion PCs. It was complete with another photo of me looking uncomfortable celebrating with SteveB on stage at the sales meeting. The sales meeting was always a country-mouse/city-mouse moment for me.

Just as soon as that excitement was over, Microsoft announced what turned out to be the worst earnings in corporate history with a 17% drop in quarterly revenue in July 2009 the end of the fiscal year. The tough part was we knew this was coming while we were on stage, which made our celebration much less about the past and more about hope for the future. While many would blame the economy or Vista and some would even cite the recently announced Google Chrome OS (the predecessor to the Chromebook), the truth was much more secular in nature. PC makers were struggling on the bottom line as the 40 million netbooks as exciting as they were lacked profit. The astronomical rise in netbook unit sales discussed in the previous chapter led many to assume a bullish future. In fact, netbooks masked a secular decline in PC sales. We would know more as the year progressed as new PCs were sold with Windows 7 during holiday season 2009.

After the celebration, the team collectively exhaled. It was August and time for vacations, but we didn’t have a lot of time to waste. Come September, we had to get the team fully engaged to plan what was coming next or it would be a massive effort to regain momentum.

Our team of administrative assistants outdid themselves with a wonderful ship party held on the activity fields in Redmond. In contrast to other Windows events, I would say this one was less eventful and even comparatively subdued, but still enormously fun for the team. We had custom cakes and cupcakes, tons of food, family-friendly games, craft beers contained to a two-drink limit within an enclosed area, and even Seattle hometown favorite The Presidents (of the United States) as the special musical guest. They took their popular song “Cleveland Rocks” and wrote the lyrics as “Microsoft Rocks.” I still have a bootleg recording of that.

The competitive issues we were facing weren’t going away. The organization was about to change and clarify responsibility for dealing with those.

Launching Windows 7

We had a fantastic foundation to build upon and all we needed to do was deliver an odd-even result—meaning a good release after the Vista release—and each of our core constituencies would breathe a sigh of relief. Looking outward, however, it was obvious the world was a very different place than when we started Windows 7. It was not clear any of those constituencies or even our own team were prepared.

There was still a product to officially launch, but not before some realignment at the top of the organization.

Bill Veghte (BillV), who had started at Microsoft right out of college and had overseen Windows 7 marketing through to launch planning, decided after two decades with the company that he wanted an opportunity to run a business end-to-end and announced his intention to depart Microsoft. After a transition he would join Meg Whitman at Hewlett Packard. With that, SteveB wanted to put all of Windows under one leader and asked me to do that. He really wanted to elevate the job title which I pushed back on because of the way Microsoft was structured (and remains so) we did not really have what most consider true ownership of a business. Nevertheless, that was the origin of the job title of divisional president.

One of my first tasks was to hire a marketing leader to take over from BillV, one who would best represent the collaborative culture we aimed to create. I wanted to bring finance and marketing together under one leader because the Windows business uses billions of dollars in pricing actions to fund marketing through OEMs. Tami Reller (TReller) had been the finance leader for the Windows business, reporting to the corporate CFO. When she joined Microsoft 10 years earlier following the Great Plains acquisition where she had been leading marketing. I got to know her then as the acquisition fell under my then manager, Jeff Raikes (JeffR). She was the perfect combination of marketing and finance leadership for a business where those went hand in hand and brought a great deal to our management team.

Microsoft wanted (needed) a big launch for Windows 7 and so did the industry. As had become a tradition for me, I wanted to spend the launch in Asia while my peers led the US event. My connection to my Microsoft family in Japan, China, and Korea ran deep and the business for Microsoft in those countries was huge. I couldn’t be in all places at once, so I chose to attend the launch in Japan. No one loves a retail launch more than Japan.

I arrived two days before the October 22, 2009 launch. I never worked harder at a launch event. From first thing in the morning (easy because of the time change) until well past midnight (well supported now with Modafinil) because of excitement at retail stores, we did press visits, interviews, broadcasts, met with customers, and more. We’d shuttle from event to event in a Japanese microvan—all of us in our blue suits and ties with a stack of name cards.

The above are two YouTube videos from Japanese Windows fans who recorded Akihabara Electric City the night of the launch as well as the Ultraseven appearance.

For years, even way back when I worked for BillG, I had been going to Yodobashi Camera in Akihabara (and Shinjuku) to see what Japanese consumers were buying and to buy assorted USB and power cables that are exactly the length I need. The size of the Yodobashi flagship is unimaginable. The evening before the event we got an incredibly cool behind-the-scenes tour of the store, getting a look at the entire operation at night as they prepared the signage that would blanket the store for our event there the next day, such as the big decals that covered the walls of the 5-story escalator. As someone who grew up in the shadow of Disney World, the underground tour of Yodobashi was much like the underground of Disney, and about the same number of people visit each year I was told.

The team put on an outdoor event at the front of the store the evening of the launch with all sorts of famous-in-Japan anime/cosplay actors and tech celebrities. And when the first copy was sold that evening, we did a press event right there at the front of the store. All along the main street of the Akihabara Electric Town, Chuo Dori, there were events in front of the many stores selling PCs and software.

Microsoft Japan, MSKK, had come up with a crazy promotional partnership with Burger King. The chain created a seven-layer Whopper to celebrate Windows 7. It was five inches tall (13cm) with seven patties totaling 1¾ pounds (791g) of beef. It was unfathomable, even for a no-carb, protein person like me. The first 30 customers got to buy the burger for ¥777, or about $9 at the time. The launch team and I snuck over to the Burger King around the corner from Yodobashi and ordered the monster burger. None of us could eat it elegantly or even try to finish it, but we got some hilarious team photos of the attempt and general celebration.

At a hotel ballroom, we held the main launch event for the press, featuring all the new PCs from Japan PC makers. The event featured an Ultraman theme. Why? I knew about the movies but was not a huge follower. What I learned was that Ultraseven was the third installment of Ultraman from the late 1960s. It was still wildly popular in some circles in Japan. The launch had a cast of people doing choreographed battle scenes in Ultraseven and Ultraman outfits. It was something to see. I filed this away for another Lost In Translation memory.

MSKK hosted a both a casual user group meeting and a formal business launch as well. At the user group meeting we did demos and gave away a bags of Windows 7 logo gear among a series of demo stations at a cool Akihabara exhibition space down the street from Burger King. I wore a super cool Windows 7 windbreaker which I still have.

The business launch was a formal ceremony highlighting the broad support of both hardware and software for the launch. Joining Microsoft was the head of Dell Computer Japan. Together with a group of MSKK employees and partners we participated in the traditional celebration kagami-biraki or cracking open a rice barrel with big wooden mallets.

I’ve had the privilege of experiencing many product launches in Asia, but this time, for Windows 7, it was next level. MSKK is a gem of Microsoft. When I am lucky enough to be in Tokyo, even years and years later, walking around Akihabara I have the warmest and most vivid memories of the launch and my friends from MSKK. And sometimes my stomach hurts a bit thinking about the Burger King, which recently closed just before the pandemic. The news coverage of the event in Tokyo which was amplified across the important Asian markets was wonderful.

Our confidence was high heading into reviews, which broke with availability of the product and new PCs in retail stores—we had plenty of positive reviewer experiences and no deep concerns. That’s what came from being not just in beta but running as the primary OS on reviewers’ and enthusiasts’ PCs for months. We risked a reviewer becoming somewhat bored or even cynical with the release simply because there was little new from the beta and no product drama to speak of. Hundreds of positive stories broke across print and TV. Local reporters did a lot of product reviews and buyers’ guides at that time. Waggener Edstrom worked tirelessly in the United States to feed them information and support.

Walt Mossberg’s review evoked a positive tone that started in January with the beta release. For his RTM review he said, “Bottom line: Windows 7 is a very good, versatile operating system that should help Microsoft bury the memory of Vista and make PC users happy.” The headline read, “A Windows to Help You Forget: Microsoft's New Operating System Is Good Enough to Erase Bad Memory of Vista.” There was little more we could ask for in a review.

Ed Baig of USA Today and one of the most widely read reviewers made it clear how positive he was on the product when he said “What you'll notice is that Windows 7 is snappier than its predecessor, more polished, and simpler to navigate. Screens are less cluttered. It has better search. Windows 7 rarely nags.…It sure seems more reliable so far.”

Windows 7 was the first major release of Windows not to double the requirements for memory and disk space. While the box maintained the same requirements (also a first) in practice the reduction in memory usage and focus on Task Manager paid off handsomely. As much as we were proud of the business success, the engineering success of Windows 7 was among the most significant in company history and the reviews reflected this improvement in core software engineering competency. JonDe brought his engineering excellence to all of Windows.

Major PC makers used the time from sign-off on the build to the October launch event to prepare the first Windows 7–ready PCs and get them into stores for holiday sales, including Black Friday in the United States.

Industry analyst firm Gartner declared the “recovery of the PC market on a global level,” with preliminary numbers showing a 22.1 percent increase over the previous year. Their quarterly analysis was effusive relative to their own reports just months earlier that were doom and gloom. More than 85 million PCs were sold in the fourth quarter of 2009, up more than 10 million units from 2008. This even though we were in the midst of a global recession. One year earlier, the top line was that PC sales had crashed. By the end of the first quarter, Gartner would upward revise their forecasts for 2010 to almost 370 million units, growing nearly 20%. The primary reason was that mobile computing, including netbooks, was on fire. Gartner concluded “It was the strongest quarter-on-quarter growth rate the worldwide PC market has experienced in the last seven years.”

It would be incorrect to assume cause and effect relative to Windows 7. There existed pent-up demand for new PCs to replace aging ones. Windows Vista had caused many, both at home and at work, to hold off buying new PCs, and the recession further slowed those decisions. Windows 7 brought many people back into the market. The shift to mobility was helping PC units, but the low cost of netbooks hurt the profits of the major PC makers.

The competitive forces were real. Apple was doing very well in the US (and Japan) and finished the year selling 24% more units year over year. The strength in consumer sales was the headline supported by the so-called consumerization of IT, where consumers were buying their own preferred PCs to do work rather than rely on stodgy corporate PCs that were slower, heavier, and burdened with IT software.

It felt, at least to me, that I’d been holding my breath for more than three years.

I walked through Meiji Garden and Shrine early the morning of my flight home, a travel day tradition and one of my favorite places on earth. The world’s economy was still in shambles from the Global Financial Crisis. The PC sales everyone was excited by were obviously juiced by the start of an economic recovery and by netbooks. These were not going to last. When it came to netbooks, the major OEMs were anxious to exit the market and return to their view of normal. The problem was, as it became clear, netbooks were additive to a shrinking market. Consumers wanted portability. They were willing to try netbooks, but the product could not meet expectations.

When NPR reviewed Windows 7 in a very positive review, even the introduction espoused the end of the operating system, saying:

We are in the modern world now and, while Windows continues to be the default OS, everyone is talking about Mac OS X, Linux and the second coming of, wait, no, just the much-anticipated arrival of Google's Chrome OS.

The future is the Web, not the OS, and everyone knows it.

As the Narita Airport customs officer stamped my passport and I walked through the turnstile, I could finally exhale. I think my stomach still hurt from the attempt at the seven-layer Whopper. Everyone else was heading back from the New York launch events and, other than the coverage I read, I don’t remember if we even took the time to share stories.

I had the same feeling I had when Office 2007 finished. As happy and proud as I was, it felt like the end of an era. With the huge shift happening in PC sales, PC makers, the internet and cloud, mobile phones, there was no denying we were in another era. When I looked at Windows 7, I did not have a view of “look what more we could do” as much as “we’ve done all we can do.”

What I do remember more than anything was talking to members of the team in the hallways, at meetings, remote offices, or over email throughout the course of the release. No matter what was going on and how difficult things got, I will always cherish all the people who shared their feelings about doing some of the best work of their careers—thoughts I still hear even as I write this. It was incredibly rewarding to hear. That wasn’t about me, but about the system and the plans put in place by the team of leaders we assembled. The Windows team was a new team. It was so ready to take on new challenges.

With RTM everyone on the team received their ceremonial copy of Windows 7. It is nice to have something to put on a shelf reminding each of us of the project and what we accomplished. For many, the next stop is the Microsoft Store to get upgrade copies for friends and family—another Microsoft holiday tradition.

The growth in mobility and demand for quality played right into Apple’s strengths, though not at first glance. The market continued to pressure Apple on low prices and did not see the weakness we did when it came to netbooks. On the heels of the Windows 7 launch, Apple released several new Get a Mac commercials. Among them was the segment “Promises” which reiterated all the times at new releases of Windows when Microsoft claimed the new release would not have all the problems of the old release. This one wasn’t accurate, but that didn’t matter.

In fact, Steve Jobs and Apple had a product in mind even more disruptive to the PC than the iPhone or MacBook Air…while we were just starting the next Windows release.

On to 097. A Plan for a Changing World [Ch. XIV]

While it is incredibly fun to do a first demo of a big product as described in the previous section, there is something that tops that and even tops the actual release to manufacturing. That is providing the release, actual running code, to a product’s biggest fans. It was time to welcome everyone to Windows 7 and put the code that the team had been working on since the summer of 2007 out for the world (of techies) to experience.

Back to 094. First Public Windows 7 Demo

Seattle summers are notoriously difficult on product development. After a long spell of clouds and rains, the beauty and long days of Pacific Northwest summers arrive, neither are particularly conducive to coding.

Summer wasn’t why I ended up here, but it certainly had an impact on me. On my first visit in 1989 during a dismal February, I saw the outdoor Marymoor Velodrome down the street from Microsoft and thought, this is going to be great. On TV it didn’t look as difficult to ride as I eventually learned it was. I sort of rode it exactly one time and that was the day my bicycle arrived from Massachusetts.

But alas, product development demands don’t end even with 15 hours of daylight.

It was going to get busy for the Windows 7 team. Our planned schedule called for the third development milestone to be complete by the end of summer 2008.

We were making progress, but the schedule was slipping. The code was getting better every week, but the overall game of schedule chicken that often plagued a large project was an historical concern. This was our first time as a new team going through this part of a product cycle. While we had a good deal of positive progress building a team culture, Windows was notorious for groups betting against each other’s schedules and being less than forthright with their own.

When HeikkiK was running the Office 95 ship room, he declared that everyone should be working to finish first, not simply to finish second to last. We needed to get to the end of the milestone as a team working together without looking for one group to blame, since it is never one group. JonDe and I had this same concern.

Everyone spent the summer installing daily builds on every PC we could. At one point, I must have had eight different PCs between home and office and was installing on all of them nearly every day. Every night I was installing a new build at home while doing email and other routine tasks. Even though my home “service level agreement” called for no beta software, an exception was made for Windows 7.

I was working at two performance extremes. I went to Fry’s Electronics and built my own “gamer” PC from the best components. I spent big bucks on a newfangled solid-state desktop drive (not common at the time), a crazy graphics card, fast memory, and the most ridiculous Intel chip available. I installed Windows 7. I was blown away by the speed (as well as the noise and wind emanating from the mini-tower). Starting Word or Excel seemed instantaneous. Boot took low single-digit seconds. It reminded me of the first time I used a hard drive on my father’s Osborne computer and how much faster it was compared to floppy disks. I used this PC when I sat at my desk at work, which wasn’t often as I was always walking around the halls.

At the other end of the spectrum were Netbooks. To the degree I could, I had taken a fancy to the Lenovo Netbook, the IdeaPad S10, and carried it with me everywhere especially at my favorite breakfast place (Planet Java) or lunch place (Kidd Valley) where I did a lot of Windows 7 blogging. Every Netbook was close to identical on the inside, but the Lenovo had a good screen and a rugged exterior. I modified mine, replacing the spinning hard drive with a then non-economic solid-state drive to better emulate future laptops like the MacBook Air. It was my primary PC for writing blogs posts, email, spreadsheets, and browsing, and the like, which was most of what I was doing. When we finally got to the Professional Developers Conference, this was the PC I held up with a bright yellow “I’m a PC” sticker on it, stickers marketing created in a jiu-jitsu move embracing the blowback from the Apple TV commercials.

I was constantly on the lookout for memory consumption and the number of running processes, the signs of bloat in Vista—fewer processes and less memory were better. Each process was a critical part of Windows. The number of processes had soared with Vista, and each had overhead in complexity and performance (in contrast to Linux, Windows processes were much more substantial and important to track.) Windows 7 was making impressive strides in reducing memory usage and process complexity. It served to make me feel connected to the engineering of Windows 7 and reminded me of counting bytes and seconds back in the day. I snapped screen shots of the Windows Task Manager and would bug JonDe and AlesH every couple of days.

Each day booting into a new build and seeing the progress was a great day. Each day revealed a crisis or challenge, but as a team everything continued to move forward.

Even though I was mostly an observer, the effort to improve performance was some of the best work of the release. It set a tone for making progress, but also for the ability of teams to work together. The conventional wisdom was that Windows Vista was inevitable and unavoidable as capabilities were added and the product grew which could not have been prevented. Windows 7 disproved that theory.

By midsummer, we had to slip the schedule based on our progress through M2 and M3. Originally our goal was to finish M3 and have a full beta in time for the previously scheduled Professional Developers Conference, PDC, in Los Angeles. We weren’t where we needed to be, so we took about an eight-week slip. The build at the PDC would officially be pre-beta, terminology we just made up. This would be our last slip. JonDe and I were privately relieved at the degree of the slip, but frankly the team was excited to be clearly on track, relatively, for the first time in many years. Depending on your experience or the context, eight weeks can seem huge or literally nothing. It was nothing.

SteveB sent a memo to all of Microsoft outlining some of the work to date for the whole of the fiscal year. The company had made a lot of progress on many fronts. The topic that had occupied a great deal of discussion, and was a good portion of his memo, was Google and competing with it on the consumer front and the potential relationship with Yahoo. SteveB also described the emerging cloud strategy, and the fact that more would be shared on that topic at our upcoming PDC.

Fiscal year 2008 was quite a year for Microsoft. Revenue broke $60 billion and operating profit grew 21 percent to $22.5 billion. The numbers were incredible. Still, the concerns about the PC and catching up on consumer services dominated Wall Street’s view. This memo was one of the early communications in a strategic shift to the cloud platform and you can feel the push-pull between cloud and the traditional model in the technology descriptions. It’s important to say that it was still super early in the journey to the cloud for enterprise computing and the topic was not top of mind for customers, especially as the financial crisis began to take hold. In fact, the feeling that the cloud was architecturally inferior to private data centers was by far the most common customer belief. Their future enterprise computing model was a data center running servers using virtualization. In 2008, the idea that there would be something of a new cloud operating system was mostly a view held inside the halls of Google.

In the memo, SteveB announced that KevinJo was leaving to be CEO of Juniper Networks, and that JonDe and I, along with Bill Veghte (BillV) leading marketing, would report directly to Steve, a reporting structure that remained in place through the release without issue. This was a standard and expeditious way to handle a managerial change at this stage of a big product. Incidentally, Satya Nadella (SatyaN) had recently moved to manage Search and ads in March 2007 and would also report to SteveB in a similar move.

In the lead-up to the PDC we began blogging publicly about Windows 7. With the focus on tech enthusiasts, IT professionals, and the trade press, I created a blog called Engineering Windows 7, or e7. An extension of how we thought about blogging for Office 2007, the blogs were the primary first-party communication channel for the product. We authored long and detailed posts, thousands of words, about the implementation choices we were making and how we measured progress. We offered tons of data to describe real-world Windows use (often my favorites posts). I authored posts but also introduced posts that other team members wrote, each expressing the design point of view and rationale. Many generated a great deal of dialogue and discussion and became news stories themselves. There wasn’t really a Hacker News yet for Windows coverage, but the comments sections of many stories read just like Hacker News would have read. Tech enthusiasts loved to dispute the data provided then just as today.

While to some press the blogging came across as a carefully crafted corporate message, nothing was further from the truth. We were simply blogging. The posts did not go through any corporate machinery or apparatus. They were as authentic as they could be. And the tradition worked so well that after the PDC it became a significant part of the communication of Windows going forward.

There were two relevant industry announcements that at any other time would have caused a great deal of distraction. The PC world was entirely focused on the PC, to the exclusion of the world of mobile phones, and, to some degree, browsers were still distinct as a challenge to Windows because they still ran on Windows and had yet to incorporate much beyond rendering text and graphics. Yet both phones and browsers would have announcements that would radically alter the competitive landscape for Windows 7.

In June 2008 at Apple’s WWDC (the World Wide Developer Conference, Apple’s version of the PDC), Apple announced the much-anticipated and predicted iPhone SDK and App Store which was teased earlier in the year. Initially, it had 500 apps, small relative to PC apps, but that number would grow at an astronomical rate. More importantly, it solved many key problems that had plagued PCs. In the announcement, which was a short note from Steve Jobs posted to Apple’s news site, he said “We’re trying to do two diametrically opposed things at once—provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks, etc.” This controversial change riled tech enthusiasts but also ushered in a new definition of computer, one that was safer and more reliable than anything a PC (or Mac) could offer. The emphasis below is mine.

Third Party Applications on the iPhone

Let me just say it: We want native third party applications on the iPhone, and we plan to have an SDK in developers’ hands in February [2008]. We are excited about creating a vibrant third party developer community around the iPhone and enabling hundreds of new applications for our users. With our revolutionary multi-touch interface, powerful hardware and advanced software architecture, we believe we have created the best mobile platform ever for developers.

It will take until February to release an SDK because we’re trying to do two diametrically opposed things at once – provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks, etc. This is no easy task. Some claim that viruses and malware are not a problem on mobile phones – this is simply not true. There have been serious viruses on other mobile phones already, including some that silently spread from phone to phone over the cell network. As our phones become more powerful, these malicious programs will become more dangerous. And since the iPhone is the most advanced phone ever, it will be a highly visible target.

Some companies are already taking action. Nokia, for example, is not allowing any applications to be loaded onto some of their newest phones unless they have a digital signature that can be traced back to a known developer. While this makes such a phone less than “totally open,” we believe it is a step in the right direction. We are working on an advanced system which will offer developers broad access to natively program the iPhone’s amazing software platform while at the same time protecting users from malicious programs.

We think a few months of patience now will be rewarded by many years of great third party applications running on safe and reliable iPhones.

Steve

P.S.: The SDK will also allow developers to create applications for iPod touch. [Oct 17, 2007]

The App Store also provided distribution and awareness to developers, a way to make money, and a way for Apple to vet apps that might be harmful to consumers. At the time the focus was on the fact that “30 percent goes to Apple.” When we saw the store, though, we knew the change would be monumental. To find software for a PC, the best someone could have hoped for was a website such as download.com. There existed varying levels of trialware, freeware, spyware, and malware. Apple had solved the software distribution problem, made sure software was reasonably safe and high quality, and given ISVs a huge new avenue for creativity and money. All on the most exciting computer around, the iPhone. That was the bad news. The good news was that the world still viewed PCs and phones as totally different things.

The world other than Steve Jobs and Apple, as discussed in the previous section. History would later reveal through email discovery the internal conflict that surrounded opening the iPhone to developers so broadly. The success would also go far beyond even what Steve Jobs anticipated.

All that I could think was, Time. I need more time

That was not all I thought. I also greatly admired what Apple was accomplishing. Like many who joined the Apps division in the 1980s, Macintosh was a crucial part of my early Microsoft work and the years before that. The old Mac ToolBox APIs are forever imprinted in my memories. Other than the die-hard fans, few generally acknowledged the consistent refinement and foresight in Apple’s software design. Several of us on the team were “original” Mac third-party developers from the mid-1980s and had always admired not only the results but the patience of their process. The continuous iteration and complete execution of what they did was admirable. Apple’s business in Macs was definitely not something we worried about, but their product execution was worrisome. I looked over their R&D spend and compared it to Windows and Office. In 2008, Apple for the first time eclipsed $1 billion in R&D for the year, a big uptick from the prior year, perhaps an indication of iPhone and iCloud ramp. The full Windows 7 team was spending about the same. There’s a huge difference in R&D when it comes to having a full ecosystem but at the same time R&D for hardware is much more expensive. The main point is not only were they building breakthrough products, they were doing so remarkably efficiently compared to Microsoft.

The Mac might have been a better product, but Windows won, and the winning product becomes the better product in the market. It was not until the iPhone and SDK came to be that the true appreciation of all they had done with so relatively little was so broadly understood.

A more shocking announcement that hit closer to home came six weeks later. Google announced the Chrome browser with a blog post and a classically Googley online comic that accidentally dropped too soon. Chrome, ironically named due of the absence of user interface chrome, would prove to be monumentally disruptive to the browser world. Google had dramatically improved performance and security in browsing compared to IE 7 from Vista (or IE 6 that so many were running still) and current leader Firefox. They had committed to open source and brought an entirely new level of energy to the browser battle. In his blog post, Sundar Pichai (yes, then product manager for Chrome) wrote in a nod to antitrust that the “web gets better with more options and innovation. Google Chrome is another option, and we hope it contributes to making the web even better.” In some ways, we were straight back to 1996 again. This would be a huge problem for the newly reconstituted Internet Explorer team, both immediately and going forward. Within a short time, there was a massive share shift to Chrome. Much like Gmail, Google released a product, seemingly out of nowhere, into what was viewed as a stable space. And they took it over. It would be years before privacy, tracking, and all the “evil” stuff Google’s browser would come to be, but at the time, a new competitive landscape was defined for IE. If our job was difficult before, it suddenly was even more so.

The PDC took place on October 27th at the Los Angeles Convention Center. Azure, the new name for Red Dog, was announced on the day one keynote. That proved to be both prescient and somewhat ahead of the curve for most attendees. Windows 7 was the second-day keynote and carried the bulk of the news for the show. In some ways the fact that most of the attendees did not seem to find Azure immediately useful made our jobs easier. Most attendees were still debating the proper way to pronounce Azure. The developer relations leader found the debate the night before particularly irksome as he was a Persian who had his own ideas of how to pronounce a word he claimed as native in origin. I was completely entertained by this late-night sideshow. Nevertheless, the fact that the attendees were somewhat puzzled by Azure compared to what they saw as vastly more interesting sessions on .NET, Avalon, virtualization, or the Windows 7 desktop. The disconnect was a harbinger of the disruption challenges the entrenched Microsoft would face.

While the audience for the PDC was professional developers there to learn the latest in APIs, tools, and techniques from Microsoft, the front rows of the main hall were the all-too-familiar members of the press. Looking out from the stage, I could see all the stalwarts of Microsoft beat reporters and technology press who had been frustrated by the lack of information of Windows 7. We were doing a keynote for developers who spent a few thousand dollars to be at the show, but in reality we were putting on a show that needed to be understood by the mainstream media and conveyed through the expertise of the industry press.

Steve Jobs had upped the stakes with his spectacular keynotes, increasing pressure across the industry to put on a good show. The normal Microsoft keynotes, the kind pioneered by BillG, were long and detailed with complex architecture slides and many graphics. These were somewhat enhanced as we moved to enterprise computing with obligatory and infamous “partner videos” featuring senior IT professionals in front of architectural diagrams or racks of equipment extolling the virtues of Microsoft’s strategy. The audience expected this type of keynote and expected us to write code on stage. By those measures, they keynote might disappoint.

While we tried to streamline the keynote, marketing insisted on having at least one customer testimonial. This is a pretty cool demo of work by Autodesk showing off the use of touch in Windows 7. (Source: Microsoft)

Having said that, as we planned for my first keynote leading Windows, I knew that the biggest mistake I could have made would have been to try to emulate what I was not. Most importantly, I also had to find a way to apologize for Vista without throwing the product or team under the bus. I had to find a way to be excited about Windows 7, realizing we had holiday PCs with Vista still to sell. Above all, our announcement was for a pre-beta, not even an official beta, though it was ultimately a distinction without a difference.

For my part, I went with who I was—like Sammy Davis Jr. used to say, “I’ve gotta be me.” The slides I showed were sparse and my words carefully chosen. While not one for grand entrances, I did choose “I Can See Clearly Now” by Johnny Nash as walk-on music. I was the only thing standing between the thousands of press and attendees, and seeing Windows 7 code. We knew people were there to see a demo, not a build-up or a long story. Just get to the clicks. I used just two minutes and not even 400 words then introduced JulieLar to step on stage and start clicking. I stepped down from the podium and remained upstage opposite Julie.

As soon as she brought up the screen on the monitor, people started taking pictures, some with their new iPhones, but most with Windows Mobile, and since they were live-blogging the event, we knew they were noting the build number that was visible at the bottom of the screen, confirming that our debate about what version of Windows we were working on would be part of the conversation. Within about a minute Julie got her first round of spontaneous applause and hoots. The demo was fantastic and every time she said “…works the way you want to,” we could feel the excitement. She demonstrated all features with both a mouse and by using touch on a monitor, including showing an on-screen keyboard with predictive text and more. The bulk of the demonstration emphasized “putting you in control” of Windows.

Once she was finished, I stepped onto the center of the stage and got to say, on behalf of the entire team, something two years in the making.

“Welcome to Windows 7, everyone.”

It was the perfect demo to introduce the product.

At some point in the keynote I needed address what everyone was waiting for which was what did Microsoft really think about Vista. While the press would no doubt take note, the credibility of what was said would rely on winning over the tech enthusiasts. More than any audience, the tech enthusiasts in the room were most disappointed in Vista and felt let down by the product. From March 2006 when I came to Windows, I promised to never be critical of what preceded me and I intended for that to be the case. It would have been so easy and so cathartic for the room to profusely apologize for Vista. It would have been equally wrong to pretend that we had not made some sort of mistake. I chose a path of subtlety and to acknowledge “feedback” in all its forms, including a few television commercials.  With a slide titled “Transition from Windows Vista” I framed the work we had done since Vista released as providing context for the day’s keynote:

As we set out to build this release of Windows, we really did have to recognize the context with which we were releasing Windows 7 and developing it. And that’s in transitioning from Windows Vista. We certainly got a lot of feedback about Windows Vista at RTM. (Laughter.) We got feedback from reviews, from the press, a few bloggers here and there. Oh, and some commercials. (Laughter.)

As part of the session, we wanted to highlight some of the features that were specifically relevant to the developer and enthusiast crowd. I took a moment to show seven features (the number 7 was used a lot) that were chosen specifically to generate applause for the crowd including: 1. BitLocker disk encryption (previously in Vista Ultimate), 2. Mounting VHD (a virtualization feature), 3. High DPI (support for really big monitors and normal sized text), 4. Magnify (an assistive technology for low vision that is also useful for product demonstrations), 5. Remote Desktop across dual monitors (the first live dual monitor demo we ever did), 6. Taskbar Customization (anything with customization is a pleaser), 7. Action Center Customization UAC/Notifications (the improvements over Vista for enthusiasts).

There was a clear call-to-action for developers including moving to 64-bits, using Windows touch, and more, but mostly to download and install Windows 7 pre-beta. People were doing that as soon as the lights faded.

We wanted the keynote to be easy and approachable, not usually the norm at the PDC. That also meant we would leave out a good deal of the team’s work and new features present in the beta build. To that end we created a massive “Product Guide” for the trade press. We would also follow that up with a workshop for them to attend where they would have a chance to ask questions directly of the product leaders. The full product guide ran 119 pages! The team promised and delivered, and you can see this from the prominence of the “Engineering Focus Areas” in the guide which were taken straight from the product vision and mock press release.

While we would not normally expect long-form reviews and deep dives in a pre-beta, Windows 7 was generating so much interest that the tech press was filing tons of stories as were individual bloggers who drilled into every aspect of change from Vista. YouTube was filled with demos created in short order. Windows 7 was the top of Techmeme, and not for messing up.

An example of the coverage was ActiveWin, a Windows-focused outlet, that wrote over 13,500 words plus screen shots on the pre-release. Andre Da Costa wrote the piece, releasing it on October 31 as the conference ended. They dove into seemingly every detail, even including their summary of the key goals of the release:

Key Goals:

* Under-promise and over deliver

* Reduce Compatibility problems and bring investments in Vista forward

* Reduce disk foot print and memory foot print

* Improve performance

* Secure, predictable

* Make the Windows and PC Experience easier

* Exceptional hardware and software support

* Bring future releases to market faster

* Personalized experience that defines you

* Superior mobility through reliable performance, power management

ActiveWin concluded better than anything we could have written ourselves. Promise and deliver.:

It’s safe to say I am overwhelmed, overjoyed and most of all excited about Windows 7. This is the release of Windows everybody has been waiting for, it’s what Vista was meant to be and beyond that. Windows 7 puts the user first; it’s about going back to the fundamentals of what an operating system must do. Managing and maintaining your PC is exceptionally seamless in Windows 7 and users will appreciate the tremendous improvements and advancements this update will offer on both existing and new hardware form factors in the future. Windows Vista set the foundation for a lot of what is happening in Windows 7 today. Windows 7 makes security Essential, but not aggressive like Windows Vista. The improved UAC will no doubt give consumers confidence in this feature, just the fact that you can tweak it to a certain degree is a welcome change. Businesses will appreciate the improvements to how the OS is managed and deployed while mobile users can get better experiences between their work and home environments. Home Networking has finally reached a level of ease of use that will make even the novice to make those PCs in the home talk to each other. There is still a lot of work to be done as this early glimpse shows. But Microsoft is on the right path with Windows 7, focusing on ease of use, compatibility, better ways of interacting with the PC and managing the personal data. This is an upgrade I am looking forward to and you should too.

Posts on Windows 7 experiences across all sorts of different hardware appeared. Engadget, everyone’s favorite tech blog, tried Windows 7 on an ASUS EeePC writing “just as Microsoft demonstrated, the relatively lightweight Microsoft OS required just 485MB of RAM when Windows 7 was fully loaded, sans applications of course. Hot.” The article’s title was even great for all the work the team put into this specific metric, “Lightweight Windows 7 pre-Beta on Eee PC 1000H looks very promising.” I can personally confirm that memory usage number.  

As a manager of a giant product and team there are, honestly, few truly rewarding moments that are also deeply personal. Nearly all the time there’s worry about how the team is doing and if they are finding the joy they deserve. October 28, 2008 was one of those exceedingly rare moments for me.

On to RTM…

On to 096. Ultraseven (Launching Windows 7)

In an era of huge software projects with a zillion new features in every release, there’s little more exciting than the first public demos. Such demos are also incredibly stressful to pull off. In addition to all the work to just get the code to demo-ready condition, there’s a lead-up to public disclosure, briefing reporters, and aligning partners. The first demo of Windows 7 was all those things and more, because we’d (or just I) had been so quiet for so long. This is the story of unveiling at least one small part of Windows 7 along with my own personal screw up along the way.

Back to 093: Netbook Mania

The second of three development milestones for Windows 7 was originally scheduled to end on March 26, 2008 which was eight months after the project start, Vision Day. We ended up finishing on May 9, which was a slip of 44 days. For any massive software project, this was fantastic. For Windows, it was doubly so.

It was even better than that. The new organization was starting to take hold. The product was emerging. The team was executing. We were building what we committed to build, and it was working. The “daily builds” were happening and by and large the team was running Windows 7 every day.

After two years in this role leading Windows, I finally felt like it would be OK to emerge and talk about what comes next. It is difficult to put into words the constant gnawing, sick-to-my-stomach feeling up until now wondering if we would deliver. We had definitely promised but for nearly 20 years I had seen leaders across the company say “the team is feeling good” or “we’re making good progress” or “the milestone is complete” only to see the project unravel or simply recognize it was never actually raveled.

For months I had been under immense pressure from OEM partners, our OEM account managers, enterprise account managers, investor relations, Intel, retailers, not to mention SteveB, and many more to just articulate a ship date or some plan. Hardly a week went by without receiving a forwarded email detailing the costs of not disclosing what we were up to.

Yet I was perhaps irrationally concerned that I would put something out there only to have to recant or adjust what was said. Many told me I was being overly cautious. Many said that it is better to open up communication and worry about having to correct it later. I just couldn’t shake the concerns. I felt Microsoft had one chance to make up for the issues with Vista.

Many perceived the Windows team was trying to become more like Apple and close off all discussion of a product until the moment it was announced. This was not the case at all. Windows is a different product, as described previously, and to bring it to market requires a huge ecosystem of support and that invests time and money. There’s no way to surprise the market with Windows because an entire industry needs to know about it, prepare, and execute to bring new PCs, peripherals, and applications to market.

For months, Roanne Sones (RSones) and Bernardo Caldas (BCaldas) on the Ecosystem team had been in deep technical discussions with partners about what would come next but had not yet committed to a timeframe. Any hints of a specific schedule (or business terms such as SKUs or pricing) would immediately make it back to the business side of the house and then to SteveB’s inbox. Even topics such as if there would be a 32-bit release (versus moving the ecosystem to 64-bit only) would have had broad implications for PC makers (and Intel). We had to walk a fine line between being excellent partners and creating an external news cycle that impacted partners as much as us. We knew that release dates were the most likely to be leaked, and the most damaging. Finishing a product with a giant, hovering countdown clock had dogged many past Windows releases. Yet, the partners needed time to prepare, and we were closer to finishing than starting. Windows 7 would soon be fully disclosed with the OEMs.

When asked in any forum, we said our goal was to release Windows 7 “within three years of Vista.” We were intentionally vague as to whether that meant release to manufacturing, available for enterprise download, first PCs in the United States, or some other market. Effectively, this gave us a buffer of about three months. And yes, that was sneaky, but it was the one concession I made to disclosure. I really hated that all people cared about was a date when a product was so much more than that. I understood, but still.

Then, in April 2008, BillG gave a speech, and inadvertently in one small part some believed he implied that Windows would finish in the following year. The press, who were there to hear about international finance at the Inter-American Development Bank meeting, ran with it and suggested Windows 7 would be ready much sooner than the previously planned three years from Vista. In fact, a year from April 2008 was sooner than our published schedule. That was not going to happen. Explaining that inaccuracy without stating the ship date was impossible.

It wasn’t just that Bill said the next Windows would arrive “sometime in the next year or so.” He also expressed his enthusiasm in what was certainly meant to be a throwaway line but came across to a tech industry desperate for any news when he said “I’m superenthused [sic] about what it [Windows 7] will do in lots of ways.”

We were close enough to completing the milestone that it was time to plan on officially talking to the press, who would be happy to talk off the record while also helping us to reduce the amount they would need to absorb all at once when it was time for stories to be written. In parallel the Ecosystem team began working with OEMs and ODMs on the detailed schedule and on software drops.

Our first stop, as it had been with every product I worked on since Office 95, was Walt Mossberg at The Wall Street Journal. Our meetings had become somewhat of a routine, perhaps for both of us, though by no means easy or predictable—I usually prepared an overly large amount of data to demonstrate how people were using our products out in the wild and hoped to both inform him while pushing for some positive recognition. Sometimes, yes, I went a bit overboard on the data. Walt was staunchly independent and would never say if I was persuasive, but he was always thoughtful in his questions and comments.

By this time, Katherine Boehret was joining Walt when he visited. She started with The Wall Street Journal out of college. By 2011 she had her own column called This Digital Solution, and also worked with Walt and Kara Swisher on the All Things D Conference (ATD). Katherine and Walt together were a formidable audience. They were both deep into products with their own unique perspective and would put up with absolutely no spin or marketing. They were advocates for their readers and strident in their desire to see PCs live up to their ease-of-use potential and played no favorites.

This meeting, about a month after BillG’s speech, had a dual purpose. We wanted to at least try to diffuse some of what they had no doubt perceived (rightfully) as a mess with Vista without throwing Vista under the bus, while also setting the stage for Windows 7. If all went well, we might even secure time at All Things D that year for a quick Windows 7 demo at the end of an already scheduled BillG and SteveB joint interview.

It was stressful. It was Walt. And Windows 7 was not fully formed for reviewers yet. Joining for the meeting or parts of it would be Julie Larson-Green (JulieLar) for Windows, Dean Hachamovitch (DHach) representing Internet Explorer, and Chris Jones (ChrisJo) discussing Live Services.

Meeting in a conference room in building 99 with a half dozen demo laptops on the table, I started with our usual printouts of data, showing them an overview of Windows Vista in market. Walt’s earlier review of Vista called it “maddeningly slow even on new, well-configured computers.” Katherine’s writings had been a bit less harsh, but not by much. I had to at least try to change their minds, but neither Walt nor Katherine was impressed. I took the time to talk about the landscape of PCs being sold and what was going on with laptops and Netbooks. In reviewing the original Asus Eee PC, Mossberg concluded it was a “valiant effort, but it still has too many compromises to pry most travelers away from their larger laptops.” That led to a hot topic for all reviewers, but especially Walt who had praised the MacBook Air: When Windows would see a MacBook Air competitor? Walt, JulieLar, and I had discussed the MacBook Air at the Apple launch event months earlier.

My lack of an answer on behalf of PC makers was not satisfactory for them, or me. As described previously, the PC makers were much more focused on inexpensive devices like Netbooks and not eager to take on Apple or the premium PC market.

Browsers were much discussed in the late 2000s, though not the one from Microsoft. We didn’t know it at the time but in hindsight it would be fair to assume they had been or were soon to be briefed on the forthcoming Google Chrome browser that shipped in late 2008. Still, Walt and Katherine wanted to know about Internet Explorer and privacy, a hot industry topic among a few, but especially them. We were woefully behind Firefox on core browsing capability, but we had a fantastic story to share about privacy features that DHach and team had developed, including blocking “tracking cookies.” We showed them how mainstream sites, like The New York Times, were doing a poor job communicating to users how much information was being shared and with whom, but with only vague permission or even disclosure. We did not go as far as offering ad-blocking which many tech enthusiasts would have appreciated, but we did plan on releasing and showed a “Do Not Track” feature.

During development, a series of meetings with lobbyists from the advertising industry discussing the Internet Explorer privacy features had led to veiled threats about anticompetitive behavior by Microsoft against ad-supported Google. Such hints or even threats were common from anyone connected to the Washington or government communities. This was unrelated to the Consent Decree, though there were still a couple of years left on that agreement and the oversight meetings that I routinely attended. As a result, Internet Explorer 8’s privacy features that were well received in this briefing would ultimately be scaled back due to an enormously frustrating push from the senior ranks of Microsoft’s legal department to capitulate to the lobbying groups to avoid drawing attention of regulators and to spare our own nascent advertising business from having to comply with privacy requirements. Do Not Track was essentially shelved even before we started. Today, the capability is a core part of Apple’s platform and the Microsoft Edge browser.

Our primary goal for the meeting was to showcase Windows 7. For the first time, we offered up a full disclosure of our overall goals and schedule. We trusted Walt and Katherine as we had built a great working relationship with them over the years, but, more importantly, because of their unmatched professional integrity.

After the requisite, but polite, reminder of the holes we had dug with Vista, we moved on to show some of the working features of Windows 7. After discussing Vista, Internet Explorer, and Live Services we moved to Windows 7 and the demonstration. JulieLar led a deep dive into our theme of “putting the end-user back in control.”

We discussed improvements to the dreaded UAC experience. User Account Control was introduced with Vista as a mechanism to lock down a typical consumer PC and prevent software from being installed by accident. Unfortunately, the swift reaction to such a “nanny feature” was universal loathing. It became a symbol for the dislike of Vista. As it would turn out, this feature was only the first of what would become the typical smartphone experience in years to come but being first at getting between tech enthusiasts and their downloaded software also incurred their wrath. It was also the subject of one of the more biting “Get a Mac” television commercials from Apple. Shortly after Vista launch, the internet was filled with instructions to disable UAC, which we definitely did not appreciate. Julie demonstrated the improved, though still secure, experience, which was much smoother and well-designed and added options for enterprise admins and tech enthusiasts to control the feature.

Julie’s demo succeeded in bringing together many concepts in the basic experience of launching programs and switching between running programs, and the array of distracting notifications and alerts. We were calling the collection of improvements to the Windows taskbar the new Superbar. With confidence, we compared the Superbar to the OS X dock, knowing we had solved problems that the dock had not.

We showed them the collaboration with PC OEMs on what would be new with Windows 7 PCs. The Ecosystem team had a long list of improvements to device drivers, supported hardware, and features to make the out of box experience for new PCs better for consumers.

And we had a surprise for them.

A big bet in Windows 7 was to implement a touch interface across the product, with features in the desktop experience and APIs for developers, as well as device and hardware management. We had been working closely with OEMs to define standards and configurations that would bring touch to Windows 7 PCs. OEMs were excited due to an entirely new engagement from MikeAng and team to enable quality touch in new PCs. They believed this would help differentiate from the Mac. We had an even bigger vision. We wanted this for all PCs eventually.

Months or more from broad pre-release and totally hush-hush, JulieLar demonstrated how we had moved applications from the original Surface table computer to PCs connected to desktop monitor touch panels. The Surface table PC, the original Surface, was a product developed in the Hardware division. It was not unlike an ’80s arcade table, featuring a modified version of Windows combined with custom hardware enabling a new form of multi-touch interaction. The table had found niche uses in Las Vegas, as information kiosks, and had been demonstrated by BillG at the previous year’s ATD Conference. As it related to Windows 7, there were touch APIs and the foundation of hardware support. Our main demonstration was mapping software that zoomed in and out using multitouch (like on the new iPhone) along with a virtual touch keyboard, which combined would offer up many opportunities for developers. On Windows, touch went beyond just using fingers but also included the digitizer needed for pen computing. It was the only feature BillG consistently pushed for in the release.

While touch was a part of Windows 7 from the start, there were two reasons we chose to emphasize it as an early Windows 7 feature in this meeting. Showing touch early was counter-intuitive because it was totally new and could have easily remained secret, for an actual surprise.

First, we wanted to garner broad OEM support for touch which was a long-lead feature for them. No OEMs were selling touch screens which meant sourcing and developing a product was a significant investment and effort. Momentum from the conference demonstration would represent a key public commitment by Microsoft.

Second, there had long been ongoing rumors that Apple would add touch to Macintosh and with the success of iPhone this seemed more likely. Whether such rumors turned out to be true or not, the opportunity to both garner ecosystem support and get ahead of Apple while also showing off a BillG pet feature while he appeared at the conference seemed positive all around. To BillG and other pen advocates, it seemed “obvious” Macintosh would gain touch and handwriting support. Microsoft’s Tablet PC was in market for years already and had not seen a competitive entry, so the logic went.

Neither Walt nor Katherine ever gave a thumbs-up reaction at a first showing, always reserving judgment until they used and wrote about a product themselves. Walt agreed to consider a demo of the touch features of Windows 7 at the ATD Conference a month later. They wanted to show more but we chose to keep the demo focused on what the ecosystem partners would value.

We had a lot of work to do, but we were nervous-excited.

With the ATD Conference pending, we were faced with a ticking clock, which meant we needed to disclose more details about Windows 7. The touch demo was too fragile and too elaborate to take on the road. We did not want to disclose details of the product without evidence, or, more importantly, a call to action for either developers or OEMs.

Adrianna Burrows (ABurrows after joining Microsoft) was the senior vice president assigned to the Windows account at the Waggener Edstrom communications agency. Adrianna drove the agency strategy for Office and was assigned to Windows when I moved. She was an astute communication and marketing pro, had a keen ability to create the right story at the right time, and was an elite distance runner and French speaker by upbringing. While she was at the agency, she was a key part of our senior leadership team. She was also the most competitive person I had ever known and would never accept second place.

People in communications rarely say not to talk when given an opportunity, at least that was the case in the 2000s. Reporters are going to write even without first-party commentary, and eventually whatever they write becomes more plausible than anything a company might later report. I had been quiet for too long. We were on the cusp of having a narrative created for us—one that would read something like: Windows 7 is going to be a “minor” service pack rushed out the door to fix the woes of Vista, built on a smaller kernel, MinWin, as the key technology. While that might introduce some compatibility concerns, it would enable finishing the release in early 2009.

Adrianna proposed a long form interview with a highly regarded Microsoft beat reporter, Ina Fried of the influential CNET. Ina was a thoughtful journalist with a wide-ranging understanding of the dynamics of the industry. She was widely read and by the right people. Adrianna was able to arrange to have a full transcript of an interview published along with Ina’s story to reduce the risk of being edited. I thought that was a solid idea at that moment.

Adrianna created the perfect opportunity for us even though I didn’t know what to say. More accurately, saying nothing was my comfort zone. While I never speak unprepared, I just did not work out answers that sounded credible for the questions I was obviously going to get asked.

I got on the phone with Ina, Adrianna right there with me in my office with the call on speaker. For an hour I did my best Muhammad Ali rope-a-dope. I acted as though I had been forced to make the call. I gave a lot of non-answers. I’m sure Ina was confused since we had initiated the interview. Adrianna was tensing up the whole time—I could see her eyes widen with each non-answer. The more I spoke, the deeper the hole I dug. My answers got shorter and my deflection increased—all I could think of was that I didn’t want to talk yet because I was so unsure of what we would get done and when. I could not figure out why I was talking and what the call to action was for readers.

I was trapped. I felt like we talked for the sake of talking and lost sight of the lead up to the first demo as the purpose.

Ina’s story ran the day after the call, right before Memorial Day, as we were heading out to the ATD in Carlsbad for our first public demonstrations of Windows 7. It was 3,000 words of me saying nothing.

The headline said it all: “In an exclusive interview, Steven Sinofsky offers up a few details on the new operating system and the rationale for why he is not saying more publicly.”

Adrianna wanted to punch me. I had blown an opportunity. I felt bad, but the damage was far worse for the team, who were confused because the interview ended up pushing the needle back to opaque from translucent. I made a mistake and handled it wrong.

I learned the hard way that I should have either not done the call or done it well.

Fortunately, All Things D gave us a chance to undo the damage. Bill Gates and Steve Ballmer were to appear on stage together for one last time. The goal for Microsoft was to show an orderly turnover as Bill announced the end of the two-year transition from Chief Software Architect to non-executive Board Chair and would no longer work day-to-day at Microsoft. After questioning, they would turn the stage over to a “surprise” demo of Windows 7 from JulieLar.

Julie and a veritable force of a dozen people had been at work hardening the Windows 7 demonstration for ATD. All had been setting up the demo since the night before.

On stage, BillG and SteveB discussed the transition answered and questions about what would happen in a post-BillG Microsoft. Steve describes the early financial controls and conservative hiring approach Bill put in place that became the hallmark of Microsoft. There is a touching and relaxed retelling of the way Bill recruited Steve to join the company, including Steve’s recollection of “a computer on every desk and in every home.”

Later, in a pointed question, Walt asked Steve, “Is Vista a failure? Was it a mistake?”

“Vista is not a failure and it’s not a mistake,” SteveB said. “Are there things that we will continue to modify and improve going forward, sure. With 20/20 hindsight, would we do some things differently?” He told Walt and Kara undoubtedly, yes, but then added that Vista had sold a lot of copies. (The video below starts at this clip.)

Walt asked if Vista had damaged the Windows brand. Bill jumped in with, “Well, there’s no product we’ve ever shipped, including Windows 95, that was 100 percent of what I wanted in the product…. We have a culture that’s very much about, ‘We need to do better.’ Vista gave us a lot of room for improvement.” The audience, and especially Walt, laughed.

Then Windows 7 was up.

JulieLar walked on stage and did a slick, six-plus-minute demo. It was the product that we had always envisioned, executed from an off-the-shelf laptop as well as from a desktop with a currently in-market touch monitor running Windows 7 software. It was live and that was terrifying for all of us. Notably, the code was barely working—clicking or tapping in the wrong place could have been a disaster. Still, it was a smooth demo.

Walt and Kara were constantly reaching over Julie’s shoulders and touching the screen to see what would happen. We had agreed to the scope of the demo and that we would not venture off and show or talk about other features.

Julie drew using a touch version of the venerable MS Paint and whisked through photo management, including “features anyone with an iPhone would be familiar with, such as two-finger zoom and slideshows.”

At one point, Walt noticed that the taskbar (the Superbar we showed off at our HQ meeting previously) looked a bit different and asked about it. Julie replied, “You know we’re not supposed to talk about that today.”

The mapping application from Surface Table was also shown but on Windows 7, including the live data for the Carlsbad, California, hotel we were in. The demo wrapped up with the playing of a multitouch piano application, which by coincidence was like one making the rounds on jailbroken iPhones. There was still no app store yet, but the technically savvy crowd figured out how to use the released developer tools to build apps and sneak them on to an iPhone.

Our demo was a success. Phew. Windows 7 was out there, at least in words, pictures, and videos.

The next step was getting pre-release code into the hands of developers.

On to 095. Welcome to Windows 7, Everyone

The Windows team was plugging away on Windows 7. The outside world was still mired in the Vista doldrums. Then in the summer of 2007 there was a wakeup call in the announcement and shipment of a new type of computer from upstart Asus, called a Netbook, a tiny laptop running Linux and a new chip from Intel. Would that combination prove to be a competitive threat or a huge opportunity for a PC world fresh off the launch of the iPhone?

Back to 092. Platform Disruption…While Building Windows 7

When a project like Longhorn drags on, the business is going to miss important trends. The biggest trend in computing in 2005-06 was expanding the PC to the rest of the world, something Microsoft and others called “the next billion” as the existing computing model reached approximately one billion of the world’s 6.5 billion people.

To outfit the next billion, many believed a new type of computer was needed. They were right. Many places where we would have liked to bring computers to the next billion lacked reliable electricity, air conditioning or heating, constant high-speed internet connectivity, and often had dusty environments as in Africa and much of Asia where I happened to have some of experience.

At the MIT Media Lab, Nicholas Negroponte, the lab’s founder, spearheaded a project called One Laptop Per Child, OLPC, that launched at the Davos forum in 2005. The rest of the world would come to know this as the “$100 laptop” at a time when most laptops cost about $1000 or more.

The price of $100 seemed absurd given that was less than an Intel processor and only marginally more than Windows, and that was before the rest of the hardware. Therefore, the initial designs of the OLPC would ship without commercial software from Microsoft or hardware from Intel. Instead, partners from anyone but Wintel lined up to help figure out how to build the OLPC. Almost immediately, Microsoft and Intel were blocked out of the next billion.

The resulting device, a product of some extremely fancy, perhaps fanciful, industrial design was a key part of drawing attention to what became known as the OLPC XO-1. The device featured several technical features that were aimed at solving computing needs for children in remote areas while also addressing the goal of ultra-low cost. The software was open source with a great deal of influence from historic MIT projects aimed at learning computing and programming. The effort even created a non-profit where people could go to a web site and donate the price of a device to have one distributed. The OLPC XO-1 was so cool looking that many people wanted one for their own use, right here in the US. The rollout and communications were exactly what you’d expect from the Media Lab—exciting and broadly picked up.

Microsoft through the Microsoft Research team and Craig Mundie (CraigMu) leading advanced technology spent a great deal of effort attempting to insert Windows into this effort. The company made progress but at the expense of causing some well-known members of the OLPC project to resign once it became clear that proprietary software was involved. Microsoft for its part would embark on the creation of a version of Windows that was ultra-low cost and stripped of many features as well, called Windows Starter Edition.

If there’s a theme in this work, both from Microsoft and MIT, it is that the core idea was that to bring computing to the next billion, products would need to cost less out of necessity and therefore they would need to do less and be less powerful. Often in the process of doing this the products would also go through transformation to make them easier to use, because apparently that is something required too. This is a fundamental mistake made time and again when addressing what the financial and economic world call emerging markets. Individuals in emerging markets do not want cheap, under-powered, or worse products. They certainly do not need products that are dumbed down. In technology, there is really no reason for that as products do get less expensive over time. Yet in the immediate term companies get stuck with their existing price structures and economics. And people in emerging markets are not less smart, they simply do not have access to the money for expensive products. I saw this dozens of times visiting the internet cafes in the most rural and economically disadvantaged parts of the world where students had no problems at all using a PC connected to the internet.

Microsoft would really get stuck in China where the limiting factor wasn’t hardware. People were buying huge numbers of PC components and simply assembling their own desktops that were on par with anything available from Dell or HP. They weren’t running Linux or Open Office, they were just pirating Windows and Office. The Windows team (I was still in Office) created a whole group to strip down Windows XP and add a shell to make it “easier” for emerging markets, again a dumbed down product. These changes to software were as much as way to make products favorable to the new markets as they were to make the product unfavorable to existing customers. Eventually, Microsoft came up with a plan to offer Windows plus Office to emerging markets, and China, governments for a very low price, so long as the computers were purchased by the government. At $3 per license this sounds like an incredible deal, but in all honesty was not that different from prices in many developed markets.

Still, the idea that the next billion required much lower priced computers, and somehow the rest of the world did not, would not go away. The need to serve this market drove the next wave of innovation from Microsoft and Intel, much more so than serving existing markets.

As Intel was mostly left out of the OLPC project, at the Intel Developer Forum in Fall 2007 they announced a new line of microprocessors with at least some emphasis on making lower cost computers for an expanded market. Intel demonstrated this processor in what is called a reference design, a PC made by Intel as a way to influence their customers to build similar PCs. The Classmate PC was a pretty cool looking laptop somewhat influenced by the Apple iBook, which brought the rounded edges, colors, and translucency of the iMac to a laptop form factor. Some would say the iBook itself owed its design lineage to the Apple eMate, based on the Newton, and sold to education markets in the 1990s. As a reference design, the PC shown could support a variety of screen sizes, storage capacities, and more, so long as it ran a new Intel low-power chip.

Also showing off the new chip in the 2007 Intel Developer Forum was the Asus Eee PC—that’s a lot of e’s, which stood for “Easy to learn, Easy to work, Easy to play” according to the box. The Eee PC was the first Netbook. It was also one of the smallest computers on the market. While there were many previous attempts at super small computers, such as the Sony PictureBook and Toshiba Libretto, there were years earlier and premium priced. This form factor and price were unique at the time. The first Eee PC 701 had the most minimal hardware specifications in any PC around and ran customized Linux and OpenOffice. It also had several games and entertainment apps.

The laptop was physically tiny as was the keyboard at 8.9 x 6.5 x 1.4 inches and under 2 pounds. It had a 7-inch display running at 800x480 pixels. For storage the Eee PC had only 4 GB of solid-state disk (like an iPod) and just 512MB of RAM. The price was $399 when it finally made it to the US, though the initial reports were it would cost $189-$299. It is worth noting that the same Intel chip was also available at retail stores in a laptop with a 14” screen, 80GB drive, a DVD drive, and 2GB RAM for about the same price. This reality would not distract from the cool factor or that it fit in any messenger-style bag.

The software load was kind of a mess, at least I thought so. The hardware, however, caught the attention of tech enthusiasts who were quick to turn the Eee PC into a tuner platform, looking to modify and replace components. Soon, modders were replacing the storage or adding more memory. There were web sites popping up devoted to modding the Eee PC.

The device sold quite well through the holiday of 2007 and that got our attention. So did the fact that modders were doing their own work to strip down Windows XP (from 2001) and squeeze it on to a 4GB system. One such modder was Asus itself which came to us wanting to officially modify Windows XP. There were three problems. First, they wanted Windows XP to cost the same as their Linux, which was $0. Second, they wanted to remove a bunch of XP just to make room on disk. What they wanted to remove was simply anything that took up space. It was kind of a free-for-all that reminded me of what enterprise customers did to Windows 3.x and Office 4.x back in the 1990s to squeeze on to 20MB hard drives.

The third problem was significant. Windows XP was done. We were over it. It was already seven years-old and we released Vista months ago. Vista was our bet. There was definitely no way Vista could be squeezed down, first of all. Second, Vista just went through the Vista Capable mess where the basic version of Vista became tainted in market and these chipsets were good enough only for Vista Basic.

If we began selling XP again for Asus, then we would have to offer it for every Netbook. And if we offered it for Netbooks then what would stop OEMs and ultimately customers demanding it for every PC. Suddenly it was looking like a roll back of Vista, especially if we participated. We didn’t really have a choice. Either we would lose the sockets to Linux, the modders would continue to pirate XP and hundreds of thousands of computers would be running a Frankenstein build of XP which already had tons of security problems, or we could suck it up and let the OEMs sell XP.

It turns out Intel was in a bit of the same situation. They were starting to worry that OEMs would want to make many more laptops out of the low power chips and that would take away sales of their more powerful and profitable laptop chips. Intel defined the Netbook category, and thus availability and pricing of low power chips, to require certain maximum screen sizes and configurations. This constrained what would technically be defined as a Netbook. Microsoft used these same definitions, chief among them the tiny screen size, to offer Windows XP. This had a side-effect of extending the Windows XP lifecycle even more. When we finally celebrated the end of Windows XP it was years longer than originally planned entirely due to Netbooks, though the industry would remember this as a story of the failure of Vista in general.

In the Spring of 2008 after what could be dubbed the Asus Eee PC holiday season, Intel announced the name of the chipset to power Netbooks, ATOM®. With that both Intel and Microsoft were all in on Netbooks, and so were all the OEMs. The collective positioning of Netbooks was as a companion to a primary computer, though that was just marketing. Intel called them MID, for mobile internet device, a third category of device that was neither a mobile phone nor a laptop but a highly portable companion computer. A lot of customers genuinely bought Netbooks as their new laptop.

The industry was filled with concerns over margins from these devices. Intel chipsets that cost around $100 for a laptop were half that for a Netbook. At under $400 there was little room for either margin or innovation. The New York Times wrote of these concerns in 2008, “[D]espite their wariness of these slim machines, Dell and Acer, two of the biggest PC manufacturers, are not about to let the upstarts have this market to themselves." No OEM was going to be left out of what could potentially be a big shift.

Maintaining low prices, especially around $399, posed some problems, mostly the need to cut back on other components and capacities. Intel dropped many of the required aspects of PCs, such as extensible memory, large disk drives, and DVD drives, in an effort to develop the platform that ASUS and others would follow. The PCs would be like a phone—bare bones with all the components essentially built in with little official extensibility. They would have 10-inch or less screens, presumably because of the category but in practice because small screens were super cheap, and, importantly, Intel did not want to see PCs that might compete with profitable, mainstream 13-inch laptops.

The typical specifications of a Netbook were an ATOM processor, 1 or 2GB memory, Wi-Fi, USB ports, SD card reader, a web camera, and 2GB to 4GB of solid-state storage, as opposed to a spinning disk drive. The screen would be an inexpensive LCD running at 1024x600 resolution, with graphics bumping up against the low-end Vista Capable designation. Windows laptops had not yet incorporated solid state storage at all, which made Netbooks rather novel for techies.

For those keeping track, every single one of those specifications was less than the minimum system specifications for the lowest-end Vista PC. Every. Single. One.

That was the rub. These were low-end PCs in every sense. Some of the specs were borderline awful, most notably the screen resolution of 1024x600 was at the limits of what Windows XP would correctly display. Many interactions with Windows would be tricky with so few pixels and much of the Internet and Windows applications would really struggle. By struggle, it was not uncommon to get into a situation where the button that needed to be clicked was off screen and simply unavailable having run out of display area. At times the display just didn’t show enough rows, or the text was too small to read or edit.

HP, Lenovo, Asus, and others released a flurry of devices all with nearly identify specifications. Even though the devices were identical at the processor and chipset and even power adapter, they differed in keyboards, display, and quality of storage used. These small differences were the full-employment act for tech enthusiast web sites that tracked every development in this hot new category.

Personally, I was really into my Netbook. I was already wedded to the 11” form factor having made a switch to use only super portable PCs anyway. The Netbook was tiny, but the low-end nature of the hardware became an ever-present reminder of the need to make Windows 7 work on much less hardware than Vista did. I ran on a Netbook full time for most of the Windows 7 development cycle. The photo in the previous section of me holding up a Lenovo IdeaPad S10 with “I’m a PC” sticker was my very own Lenovo which I even modded myself to 4GB of RAM and a faster solid-state drive. I managed to blog a few hundred thousand words on the tiny keyboard as well. Where it really came in handy was how I constantly used benchmarks and slow operations to annoy the engineering managers. I loved it, but I was a willing subject.

Behind the scenes thought something else was going on. The reality was that the root of the Netbook was not just OLPC and the next billion PC users, rather it was both Intel and Microsoft or Wintel’s inability to transition to a mobile world. The iPhone that released just before the availability of the Eee PC was built with an ARM chip, which technically is a system-on-a-chip, or SoC. ARM chips were what powered the new generation of devices from portable music players to mobile phones to the new iPhone. A SoC packages much of the whole board of a Netbook into a single chip that specifically includes at least the microprocessor and graphics, small and energy-efficient package. The Intel ATOM line was not quite a SoC, though over time it would evolve to be one, at least in name. What made it possible to run Linux and Windows was the combination of compatibility with Intel instructions and the support for PC-style peripherals such as graphics and storage. Microsoft’s version of Windows for the ARM SoC was Windows Mobile, built on the aged Windows code base.

Intel’s entry, or lack thereof, into mobile computing and building a system-on-a-chip components to power mobile phones contributed to the origin story for ATOM. Intel had substantially invested in an attempt to bring the Intel x86 architecture (or IA, as they called it) to mobile phones. Famously, though, Intel ended up not collaborating with Apple on the iPhone, as CEO Paul Otellini felt Apple’s required price was too low and by some accounts desire for control too high. While the initial foray for ATOM was aimed at OLPC, many would claim that Netbooks were simply an effort to make something out of the failed investment for mobile. Since they were fully compatible at the instruction set level with other chipsets, an idea was to build a new laptop—essentially to rescue their failed entry into mobile chipsets. Since these chips drew less battery power, were smaller in size, and less expensive, Intel decided to suggest OEMs create small and inexpensive PCs with them.

In essence, the Netbook arose out of a desire to make use of a low-end chip that originally was meant to compete with ARM and to be used for mobile. While it was compatible with Windows, it was by most accounts inadequate for modern Windows, especially when it came to graphics. The small screen size, while convenient as a demarcation for the Intel chip product line and Windows XP license, was also a necessity because the graphics chipset could not drive a much larger screen.

Nevertheless, Netbooks were flying off the shelves. They were the talk of the industry. Over the next six to 12 months, the sales of these low-end PCs skyrocketed to 40 million units a year—more than 15 percent of all PCs, which was exactly what OEMs loved, especially ASUS that made a big bet. Unfortunately for all involved, the profits were slim across the ecosystem, and worse, the exuberance was truly cannibalizing laptop sales, though not ASUS, which had the new, hot product and a much smaller laptop business. When I visited southeast Asia or Africa, for example, internet cafés had a half dozen netbooks where a single PC once would have been—quantity of endpoints over quality of experience.

Over the course of 2008 leading up to mid-2009, Netbooks remained great sellers. Even if a Netbook was sold with Linux, the demand for Windows was such that pirated Windows XP that was hacked to fit on the available storage became the standard. That seemed to benefit Microsoft in the long run, I suppose. These PCs were seemingly falling from the sky in massive numbers and while the business side was worried about the pricing of Windows and piracy, the product side was happy with something new, finally. There were review websites entirely devoted to the Netbook craze, chronicling the latest developments. In a sense, what was not to love about low-priced computers if people were reasonably happy?

There was little Microsoft could (or should?) do to thwart the momentum, especially because we did not want to lose to Linux. We would have loved nothing more than the likes of HP or Dell to work on Sony VAIO-style PCs that competed with Apple, but that was not to be for a few more years. The PC ecosystem was once again proving that a race to the bottom on pricing and experience was what drove it.

Over time Netbooks expanded in system specifications, OEMs constantly bumping up against the constraints both Intel and Microsoft put in place on what was a legit Netbook. Some added slightly larger screens, making them even slower because extra stress on the under-powered graphics chips. Some added full-size spinning disk drives. Some were able to be upgraded to 4GB of memory. The problem was that under the hood these were still ATOM chips. They were not good PCs. Were they convenient, lightweight, and portable? Yes, but they were slow and had poor graphics. YouTube videos skipped frames and were jittery. Web sites that used Adobe Flash were mostly unusable. Games were too slow. Using Office was marginal at best. Even battery life was limited to three or four hours.

Netbooks, however, played an indisputably positive role in developing Windows 7. They institutionalized a low-end specification that was in-market and broadly deployed. We had to make Windows 7 work reasonably well on them.

Peak Netbook could perhaps have been best described by questions about when Apple would make a Netbook, which Intel would have loved. Such an introduction would have legitimized the category. The mainstream business press just assumed Apple would enter the category because it needed growth, and it was missing out on the hottest new category selling tens of millions of units.

Steve Jobs’s answer to Netbooks, in a uniquely Apple way, was the MacBook Air, which was announced in late January 2008 just after the Eee PC holiday season. Apple’s answer to a $400 Netbook was a $1,799 premium Mac. Classic Apple. The “world’s thinnest notebook,” said Steve Jobs, and Walt Mossberg said it was “impossible to convey in words just how pleasing and surprising this computer feels in the hand.”

It simply wasn’t in Apple’s thinking to release a sub-optimal product. Even the low-priced point products from Apple are fully capable with little compromise. Netbooks violated that core tenet of Apple and so there was no legitimate reason to expect anything other than for Apple to completely ignore this new category the way the industry defined it.

In April 2009, Tim Cook even took to their earnings call to trash talk Netbooks:

When I look at netbooks, I see cramped keyboards, terrible software, junky hardware, very small screens. It’s just not a good consumer experience and not something we would put the Mac brand on. It’s a segment we would not choose to play in. If we find a way to deliver an innovative product that really makes a contribution, we’ll do that. We have some interesting ideas.

At least through 2009, the MacBook Air remained Apple’s answer to small, portable, and even low-priced computing.

There were, however, enough criticisms of the initial MacBook Air to allow PC makers to look the other way or actively market against it by pointing out the lack of ports and extensibility. Instead, the race to the bottom with Netbooks continued. OEMs and Intel would stick with this approach for several years, while Apple refined its new approach to making laptops, eventually even bringing the price down on the MacBook Air. The result was rather crushing. PC elites quickly started running Windows on MacBook Air hardware simply because the hardware was so good, and Apple even provided instructions for how to do that. I can’t even count the number of meetings with OEMs, email threads around Microsoft, and queries from the press I received, asking, “When will there be Windows PCs like the MacBook Air?”

The ecosystem stuck its collective head in the sand all while we rode Netbooks up and then, in a short time, straight back down. In hindsight, the Netbook runup hid the secular decline in PCs that had begun with the recession following the Global Financial Crisis. It would take years to recognize that, and a massive effort for the ecosystem, and Microsoft, to respond to the ever-improving MacBook Air.

Understanding and somehow addressing the relentless force driving the PC ecosystem to produce what most tech enthusiasts see as lesser quality devices (especially relative to Apple) remained one of our key challenges. Too many saw the rise of Netbooks as the answer to products from Apple while not being able or willing to respond directly. There was a fundamental difference between the volume platform appealing to the “masses” and the premium platform appealing to a smaller and more “well-off” segment of the market. That mental model held until the iPhone and MacBook Air. We had reached a tipping point.

With the iPhone, App Store, and MacBook Air Apple was not simply on a roll but the biggest roll of all time from 2006 through 2008.

At the same time, we were deep into building Windows 7 and starting to feel good about the progress. It was time to get out and share our optimism.

On to 094. First Public Windows 7 Demo

Welcome to Chapter XIII! In this chapter we build Windows 7 and bring it to market. We start with all the forces that were shaping up to “disrupt” Microsoft (in the now classic sense) including the launch of the iPhone, cloud computing, consumer internet services, and even the perception of bloat (in Windows this time.) Each of these on their own would be significant, but they were happening all at once, while we were rehabilitating the team, hoping to ship on time for once. To add to the chaos of the moment, these forces appeared during the largest runup of PC sales, breaking 300 million units, followed by the biggest risk to PC sales growth driven by the Global Financial Crisis. A lot was going on competitively, setting the context in which Windows 7 would be built and launched. I thought about competition a great deal, so there is a great deal in this section.

Back to 091. Cleaning Up Longhorn and Vista

The days of competing head-to-head with our own past releases or with vaguely similar products were over. Windows faced outright substitutes, and they seemed to be working.

The Windows 7 team was progressing through engineering milestones M1, M2, and M3 with the energy and momentum increasing along the way, all while computing underwent radical changes at the hardware, platform, and user-experience layers. Everything appeared to be changing at once, just as we were getting our mojo back.

Microsoft’s products and strategy were being disrupted. We just hadn’t, or perhaps couldn’t, come to grips with the reality.

These disruptive forces appeared over the course of developing Windows 7, each one taking a toll on Microsoft’s platform value proposition. Each contributing to a small but growing chorus of changing times that started with the iPhone.

The iPhone was announced in January 2007, six months before Windows 7 Vision Day. The phone didn’t yet have an app store, an app SDK, didn’t run a full desktop browser, lacked push email for Exchange like a Blackberry, and even omitted basic copy and paste. Nobody at the time thought this phone was relevant in a competitive sense to personal computers. Heck, it even required a personal computer for some tasks.

Nobody except Steve Jobs.

We didn’t know the extent the competitive dynamic would shift a year later, creating a true and unforeseen competitive situation, an existential threat, for all of Microsoft.

I attended the iPhone launch event (rushing to it as it was the same week as CES that year) and walked away with a lot to think about for sure. It was easily one of the most spectacular launch events in the history of computing in my lifetime (after Windows 95 and the 1984 Mac launch and its toaster-size computer with a bitmap display that talked). Steve Jobs said one thing that proved to be incredibly important, with long-term implications overlooked by many [emphasis added, my transcription]:

We have been very lucky to have brought a few revolutionary user interfaces to the market in our time. First was the mouse. The second was the click wheel. And now, we’re going to bring multitouch to the market. And each of these revolutionary user interfaces has made possible a revolutionary product—the Mac, the iPod, and now the iPhone. A revolutionary user interface.

We’re going to build on top of that with software. Now, software on mobile phones is like baby software. It’s not so powerful, and today we are going to show you a software breakthrough. Software that’s at least five years ahead of what is on any other phone. Now, how do we do this? Well, we start with a strong foundation.

iPhone runs OS X. [applause]

Now, why, why would we want to run such a sophisticated operating system on a mobile device? Well, because it’s got everything we need. It’s got multitasking. It’s got the best networking. It already knows how to power manage. We’ve been doing this on mobile computers for years. It’s got awesome security. And the right apps.

It’s got everything from Cocoa and graphics and it’s got core animation built in and it’s got audio and video that OS X is famous for. It’s got all the stuff we want. And it’s built right into iPhone. And that has let us create desktop-class applications and networking, right.

Not the crippled stuff that you find on most phones.

This is real, desktop-class applications.

Most reviews mentioned it, but it did not take up nearly as much airtime as the touch screen. In fact, the absence of support for Adobe Flash in the iPhone browser seemed to even undermine this important fact for most. This important fact was the technology underlying the iPhone—the use of the full operating system was a massively strategic, risky, and difficult choice. Using OS X enabled Apple to gradually enable many Mac features over iterative development cycles, knowing that the code already worked. Apple could do this because it had bigger ideas for how it would break compatibility with the Mac and a bold new model for supporting developers to build third-party software. From the very start, the iPhone was destined to be a complete PC, only rebuilt bit by bit with a modern architecture and API. Not only did the iPhone bet on ever-improving mobile bandwidth as many criticized at the time, but it assumed mobile processors and storage would at least reach parity with the personal computer. In other words, from the very start the iPhone had a truck engine. (This reference will make sense in Chapter XIV.)

Windows had been taking the opposite approach which was to base the mobile platform on a nearly decades-old version of Windows, stripped down even, with thoughts though not goals of perhaps of catching up to the current desktop Windows by adding new code over time. The incredible challenges this decision introduced will become readily apparent, but only with the release of a new Windows phone operating system to compete with the iPhone. The diverging paths of Windows for mobile and laptop/desktop had been cast years earlier.

That summer, I lined up at the AT&T store at Pacific Place in downtown Seattle and picked up my black 4GB iPhone. Who needed 8GB on a phone? Some PCs were shipping with 4GB of storage and all of Windows XP. At the time of the launch announcement, I was quite skeptical of the touch keyboard and said so in an internal mail thread, pointing out if touch screens would work then Windows Phone had already tried and mostly failed. I had been a hardcore Blackberry (and later Palm Trēo) user since before general availability in the late 1990s. I was as much a CrackBerry addict as anyone. Some of the many Windows phones had a stylus like a Palm (or Apple Newton), but I never warmed to those and thought handwriting with a stylus was as dumb as Steve Jobs said at the launch. Within a few hours of having the phone (and a browser!), my worldview changed, especially about touch and especially about the evolution of operating systems. Even lacking copy and paste and relying on the slow AT&T 2G mobile network, you had to really try hard to not be impressed.

I remember emailing the co-founder of Blackberry and asking when there would be a full browser and in a long back and forth thread, he tried to convince me of the implications on battery life, lack of capacity on the phone network, and even the lack of utility. While months earlier I might have been sympathetic, I was now staunchly on the other side of this debate.

Inside the company, the iPhone went largely unnoticed outside of small pockets of people, and of course the phone team. Not because it was not a breakthrough product, but because it did not fully connect to our corporate mail service, Microsoft Exchange, as it was configured and permissioned by Microsoft’s IT group. Only those of us running on the testing servers, dogfood, were able to use an iPhone for email, and even then it had no support for our much-loved rights-managed email and Microsoft directory. There was a significant debate over whether maintaining this capability was good for self-hosting and competitive knowledge or bad for supporting competition. It was also about this time that support for using Blackberry was disabled. I put up a huge battle over this only to delay the inevitable. Making it difficult to fully host on competitive products was short-sighted but impossible to stop, even as a senior executive. This was done to “eat our own dogfood” even if the result meant truly innovative and competitive products would only receive cursory use.

While SteveB’s comments around the iPhone launch have become something of an historically bad take as he somewhat mocked the high price, it is crucially important to understand that he as much reflected as simply shared the collective viewpoint of the entire PC industry, and most of the mobile industry. Collectively, nearly every party underestimated the ability for Apple, with no experience in the mobile industry, to deliver a hit product while also resetting the norms of the mobile carrier business model—the same carriers that Steve Jobs described as “orifices” during an interview two years before the world knew about the phone.

The two fundamental assumptions of the PC industry that guided it to nearly 300 million units a year were low prices with consumer choice and a horizontal layering of hardware and software. This business model and technology architecture together enabled the PC. For all the struggles between OEMs, Intel, Microsoft and more, the success was indisputable, especially relative to the Apple model of premium price, limited choice, and a vertically integrated, single supplier.

Before the iPhone, the mobile phone seemed to be coming around to the PC model, with the Windows phone appearing to make progress against Nokia and Blackberry with many PC OEMs using a Windows phone software license to offer low price and choice to customers. Jobs would take this good news and make it appear bad by showing how Windows Phone was fragmented across phone makers, not a single OS. That drove the Windows Phone team crazy, particularly when Jobs presented the market share as a pie chart in 2008 basically rendering Windows Phone as “Other.” The iPhone would literally trounce the traditional OEM model. Choosing between a bunch of crappy devices is no choice at all, even if they all run a single platform. Jobs had long been making this point about PCs too, except now this all seemed to be working.

He was only partially right because in just a short time, Google would repeat the technical and partnership aspects of the Windows model exactly for phones, while upending the economic model and not charging for a software license, opting to further its advertising business model. Of note, the successful OEMs for Android turned out to be an entirely new set of partners, with none of the existing PC OEMs making the generational transition, perhaps in part because most had tried and failed when using Windows mobile software. The combination of iPhone and Android would leave Microsoft in a hopeless middle, with a shrinking partner ecosystem across OEMs and developers. The iPhone was not a broad or instant hit as is well-documented. History does not easily recall the bumpy first year because the following years went so spectacularly well.

Seemingly, at least for the moment, unrelated, there was that money-losing online retailer named Amazon.com led by Jeff Bezos plugging away on what Steve Jobs might have called a hobby or a side project. The company created Amazon Web Services, AWS, in 2002, though few noticed. The product was relaunched about a year before the iPhone with a new set of capabilities and two main new products: EC2 and S3, providing scalable on-demand computing and huge cloud-based storage. For developers, that marked the birth of the cloud era. Amazingly, perhaps, this new competitive front was not Google, which is where nearly all of our platform angst resided.

For Microsoft, this was all starting to sink in. We had competition on the client and at the infrastructure layer. We were getting squeezed on both of our platform businesses, Windows desktops and Windows servers.

Ray Ozzie (ROzzie) was leading a new project, code name Red Dog, with an incredible group of early Windows NT developers including DaveC. As chief software architect, ROzzie was looking to the cloud to reinvent the future of Windows Server, Microsoft’s dominant and extremely profitable business of running enterprise computing in customer-owned and -operated data centers. The running of important business functions in the cloud was still more than a decade away for Microsoft’s enterprise customers, but Amazon’s clarity of vision and the start-ups that gravitated to the approach were incredible. With the cloud, along came Linux as well. Microsoft already needed to catch up, but you had to look very carefully to believe that to be the case, as it was not at all obvious from a customer perspective.

Microsoft had invested a decade in building out Windows Server, a hardware ecosystem, databases, and the entire .NET stack along with a trained sales force. Suddenly AWS running on Linux with entirely new models of compute was the competitor. No salespeople required. To use AWS, developers just signed up online using a credit card and paid for what computing resources they needed as they needed. No hardware to buy. No servers to set up, maintain, and secure. No running out of disk space or network bandwidth. No need to buy more servers in case there’s a rush on the web site. A whole business could run off from laptop with a browser connecting to Amazon’s data centers in the cloud.

It was nearly impossible for many born of the Windows server world, whether at Microsoft or our customers, to fathom this approach. There were endless debates inside the halls and boardroom of Microsoft over whether this was crazy or fantasy. One of the most common debates centered around storing data and either how much bandwidth would be required to move data to or from cloud servers or how expensive cloud storage would forever be. To me these debates seemed rather like the debates over the browser taking over for Office—it is not a matter of if, but rather when everything aligned to make it possible and how different the resulting solutions would look from what we built today. The very existence of gmail seemed to demonstrate the present reality with the most mission critical of all storage intensive workloads, email.

We got so tangled up on how customers would migrate to the cloud, we did not really consider how much larger the market would be starting from nothing and growing cloud native. The irony of us failing to predict this same type of massive upside was almost too much, in hindsight, since that is exactly what gummed up the mainframe computing world and even the character-based (non-GUI) world of MS-DOS as the PC, Windows, and Office platforms took hold.

Additionally, when faced with disruption while substantially new ideas are fast pulling the market and customers in new directions, the previous generation of innovation does not stop. That is what makes it even more difficult for the new approaches to take hold with incumbents. At every step, we thought we would keep adding features in the direction we were going to keep winning. We were winning big. Microsoft’s revenue growth in 2007 and 2008 was 15% and 18% respectively, with 2008 revenue growing past $60 billion.

One example of this competitive pull was our focus on the biggest competitor to Windows Server, VMware. Why? VMware used virtualization to manage Windows Server and in doing so commoditized Windows as one of many alternative operating systems VMware could manage. It had started off as a brilliant invention for developers to isolate code under development on the desktop growing into a new components of enterprise infrastructure. We had been using it ourselves to simplify testing of Windows and even Office for several years already. If Windows Server could enable competitive virtualization, we could thwart the competition from VMware while also solving for the same scenarios Amazon seemed to be addressing with AWS but without Linux.

VMware was acquired (in a complex series of transactions) by a Windows partner, EMC, which soon after acquired a separate company started by Paul Maritz (PaulMa), the former leader of Windows. Paul transitioned to lead VMware as CEO, where he implemented the same enterprise playbook that helped to make Windows Server a success. VMware was rapidly becoming the enterprise standard for a new wave of enterprise datacenter management, which would turn out to be a stop along the way to a future of cloud. This mattered because it impacted the COSD team’s contribution to Windows Server and put the team in between two different versions of the future, being implemented by two different teams at Microsoft, each with serious competition—Red Dog building out one roadmap and Windows Server another. While one view might be that this was a prudent strategy, another view was that it was a strategy guaranteed to slow our progress to an inevitable future.

Our remaining competitive challenge was faced by Live Services. Competition was constant and coming from all directions. Many competitors came and went quickly, as was the norm in consumer, ad-supported services. Switching costs were low and whole populations changed quickly—it appeared to be a hit-driven business, which was not something Microsoft was geared up to navigate, especially after a failed decade of trying to make consumer and home software a thing with CDROM titles and later web sites. MSN Messenger and Hotmail had hundreds of millions of users, but daily active users (DAUs) were declining and engagement (usage time) overall was dropping. There was a good deal of advertising revenue, hundreds of millions of dollars, but it depended on intrusive display ads that riled users, even though the services were free.

Gmail rapidly became the new de facto leader in “free” email, offering essentially “unlimited” email storage in gigabytes while Hotmail was trying to build a business charging for extra megabytes. Originally announced as an April Fool’s prank in 2004 and released in beta, by the time the Windows 7 vision meeting took place Gmail had finally removed the exclusive invitation signup requirement. Though remained in beta, the service was exploding in use. While it would be a few years until Gmail surpassed Hotmail, Hotmail almost immediately stopped seeing growth and started to see a decline in engagement. Gmail was not a gimmick; under the hood was an enormously innovative database and operational capability. Gmail had no advertisements. None.

MSN Messenger, eventually Live Messenger, had become enormously popular around the world, especially outside the United States with hundreds of millions of active users. It too was facing an existential competitive threat. This time from Skype, a Swedish, Danish, and Estonian invention that offered free voice calls from almost any platform, notably both PC and Mac. While Messenger was often used to arbitrage SMS fees, Skype was arbitraging voice and creating a movement that would permit much of the world to skip using landlines for overseas calls when mobile minutes were incredibly expensive. Video calling was introduced as well, and while Messenger already had this capability, the cross-platform nature of Skype, as well as the focus on voice connections to local land lines, made for a much more compelling offering. Microsoft would finally acquire Skype from eBay (who had acquired it in 2005) in 2011 when it reached almost 300 million users worldwide, more than Messenger had achieved. In 2007-2009, Windows Live was still competing with Apple, Google, Yahoo, Skype, MySpace, and a host of category leaders across photos, blogging, and video. That was a lot.

SteveB and Kevin Johnson spent a great deal of time and energy on the potential of acquiring Yahoo, the dominant leader with which MSN competed. Such a deal would have added to my challenges given their email and messenger services were suffering much the same way. We might have gained in search and content services, but we would have added productivity services that were also losing share just as Windows Live seemed to be.

Apple struggled to find its way through the cloud and services world, even with the launch of iPhone. Apple’s decidedly client and device focused approach was quite similar to how we saw Live Services and Windows evolving together. The services would be augmented by rich “desktop class” applications for photos, video, messaging, blogging, and even productivity. Apple for years had been selling a suite of creativity products, iLife, later adding new productivity tools, notably Keynote for slide shows, called iWork. A collection of web services was originally called iTools then later rebranded as the .Mac service (pronounced “dot Mac”) and included email, online storage, and backup. In the summer of 2008, the service was rebranded MobileMe in a very bumpy launch that was not widely praised. After eight years and a good deal of iteration, Apple continued to work to find its way even as iPhone success grew.

The most disruptive announcement from Apple came a year after the initial iPhone launch. In 2008, Apple announced and then brought to market a software development kit with APIs to build third-party apps for the iPhone. This also included an entirely new store for software distribution and economic model for developers, the App Store. It is almost impossible to overstate the leap the App Store brought to computing. The PC was drowning in viruses and malware because of the internet—the ability in a few clicks to download software seemed wonderful at first, but then quickly became a cesspool of awful software that at best simply degraded the PC experience. Additionally, the world of PC software had stagnated simply because it was so large that it became almost impossible for a new desktop product to gain awareness, distribution, and enough sales to support a pure-play software company. In fact, Skype might be the most innovative native, though cross-platform, application to break through outside of browsers, and we acquired it in 2011 before it was profitable. While some would view the App Store as a sort-of closed ecosystem, it was literally the solution to the problems plaguing the PC. The Apple bet on OS X meant that there was a robust and proven platform and toolset to serve as a foundation, plus software distribution and economics. Developers hardly had all of OS X, but they definitely had a lot of it and Apple could add more over time.

Microsoft was steeped in a competitive mindset across every generation of leader and from many perspectives. BillG never missed an opportunity to cite some positive attribute or significant asset of a competitor. SteveB brought his relentless sense of competition from childhood math camp and sports. MikeMap and JeffH instilled this in all of us back on my first team with an intense business rigor. In working with the Windows and Windows Live role, I was faced with competition from more directions and with more depth than I ever thought possible. The team, at first as I moved into the role, seemed to consistently minimize this new reality. It would be rude to say Microsoft was in denial. I don’t think it would be unfair to say that after years of winning and even feeling like we had beaten back Linux and open source, Microsoft had become much more focused on its own universe of customers and their problems which was mostly immune to influences from outside that gravitational sphere.

In hindsight, that was what happened when two factors combined to create a step-function change in product trajectory.

First, the existence of a single massive product, Windows and the Intel PC ecosystem, Wintel, created constraints for those looking to build entirely innovative products. While many built products thinking of Wintel as an ingredient, amplifying the platform without posing a risk, a small percentage of risk-takers saw a different world. They saw the shortcomings of Wintel as an opportunity to reinvent. They built as though the leaders were not there and built what, in their eyes, the world should look like, whether they achieved critical mass success or not. Each of these new competitors had a worldview that revisited underlying assumptions about Windows and Windows Live and the PC ecosystem. Competitors assumed any web browser as the user interface, connected over the internet to Linux servers running open source software—no Windows Server or .NET at all. Google, Facebook, and a constellation of start-ups in Silicon Valley embraced this model as though Microsoft never existed. Even when it came to Microsoft Office, most new companies in Silicon Valley operated as though it was an insignificant part of the software landscape. In 2008, while Windows 7 was in testing as we tried to bring Internet Explorer back from hibernation, Google released the Google Chrome browser and with it putting an end to even that sliver of Microsoft as part of the next wave of innovations.

Second, the incumbent leader had to mess up. Customers generally didn’t spontaneously change, even if there was something better to switch to, because of processes, habits, and costs, and they don’t change all at once. Leaders messed up by ignoring new technologies, especially as over time little technologies added up to something material. Also, a risk was a failure to execute and deliver new products to market, simply dropping the ball. Microsoft mired in the journey through Windows Longhorn and a executing a Windows strategy put forth in the mid-1990s had indeed dropped the ball. It was increasingly difficult to appreciate or even see changes to the technology landscape when the company’s decision-making context is so dominated by goals, challenges, and issues entirely of its own making.

Waiting to pick up the ball was the competition born of the internet and web. While many wished to connect this potential disruption of Microsoft to the antitrust events and resulting settlement in the early 2000s, none of Apple’s iPhone, Amazon’s AWS, or Google’s Search or Gmail had anything to do with the trial and resulting settlement. Where some like to claim Microsoft was distracted, they would be wrong. If Microsoft was distracted, it was by simply trying to finish Windows Vista or compete with VMware or IBM or even Linux, or executing on our own plans and growth and dealing with issues like software security and quality. This wasn’t about the browser, the price of Windows, or even what software was installed on a PC. Those had already become old battles and irrelevant to the rapid structural changes that happened in software (the kind that produced Microsoft, then Windows, then Office in the first place). As fast as one company can rise to success, another can do the same in equally unexpected or counterintuitive ways. This was the argument or perhaps the defense Microsoft and BillG had put forth time and time again. No matter how many times BillG said this to the press, customers, or regulators none would believe him…even as it was taking place.

This was all happening as I was trying to get our house in order and make progress. Things just weren’t as simple as they were in 2005 when OEMs were just waiting on a new release of Windows. The PC makers were looking particularly unhealthy and deeply concerned about the rise of mobile phones on top of normal concerns about the price of components, delays in Windows, and the chip roadmap from Intel—would phones be an opportunity for PC OEMs or would they prove to be a generational change in hardware leaders as well? Should they be considering Linux on the desktop as a replacement of Windows given its popularity on servers?

SteveB, and increasingly the Board, had a lot of questions and concerns surrounding the competitive dynamic. Some board members were close to the hardware ecosystem and would oscillate between certainty that the ecosystem would deliver and that it would not. International board members were using Skype to talk to their families. Everyone wanted to know how to connect from their iPhones to their Microsoft corporate email or Windows Live personal mail, or why iTunes was so slow on Vista, or why Mac Excel was so different from Windows Excel as new Mac owners were discovering.

In fact, they were all asking how long it would be before they did everything on mobile phones. There was also deep concern over browsers, knowing it had been five years since the last release of Internet Explorer in 2001 and work had all but stopped. All of them wanted a PC as cool as a MacBook. Microsoft board members had a budget for PC purchases and always wanted to know the most Apple-competitive Windows laptop to buy, and for much of the duration of Windows 7 we had no answers. Each time I attended a Board meeting, I had to respond to all of these questions again.

Like Captain Kirk in ST:WOK (Star Trek: Wrath of Khan), I would look around and think, “Please, please…give us time…the bridge is smashed, computers inoperative.” We were rebuilding the team and trust with customers and OEMs. Windows 7 was going to pave the way for us to do big new things. There was little more we could do than get that done.

Whether it was desperation, a lack of alternatives, or simply misplaced confidence in the team, the questions kept coming yet there were few questions about Windows 7. Many were already looking beyond Windows 7, thinking, and plotting as though delivering Windows 7 was some sort of no-brainer.

Looking back, it was equally easy to ponder the radical idea of basically skipping Windows 7 and going straight for something to compete on these many fronts. We could theoretically catch up to these multiple competitive forces and not miss an entire cycle of innovation if everything was aimed at mobile and cloud. One big mega-strategy to build a new Windows, a new phone, and integrated cloud services.

That would have been absurd. It was the opposite of possible. The team was still recovering from the Vista release with its portfolio of stretch goals, to put it kindly, that did not go as planned. The last thing we should have even come up with was some sort of Longhorn-redo. Frankly, what we planned for Windows 7 was kind of crazy, given the recent track record. We planned Windows 7 and all the features with the assumption the team could deliver a major update to Windows, on time. Additionally, the Server team and its customers remained not only unconvinced of the cloud but actively campaigned against it. Besides, we had RedDog. Windows 7 had to serve both of those.

The impact and the constraints of the past had long-lasting effects.

While the Board was anxious about the post-Vista landscape, the technical trade press, mostly made up of Microsoft watchers, remained tuned to Windows. It was the product with the most familiarity, and the Vista release was causing difficulties. But the double-edged sword of the beat reporters was that they covered what we were up to, but not so much what we should have been up to, until it was too late. It would still be a few years before most reporters made the switch to Mac, but the switch to iPhone was happening quickly bringing renewed attention to Apple laptops.

At the same time, any little thing we did was chum in the water for the dozens of beat reporters covering Microsoft.

In the summer of 2007 word leaked out about the impending service pack for Windows Vista previously described. It was not a horrible leak, but it scrambled our OEM partners and immediately froze the few Vista enterprise deployments in process. The field sales team was livid that they had not been briefed on the release, again arguing for more transparency from Redmond. The problem was we had just gone through five years of transparency and every constituent was annoyed, at best. I wrote a 3000-word internal blog post “Transparency and disclosure” where I tried to put forth the idea that being transparent isn’t compatible with being good partners, but we needed to aspire to translucency (excerpt follows).

Transparent. Easily seen through or detected; obvious.

Translucent. easily understandable; lucid.

One topic I have been having an interesting time following has been the blogs and reports that speculate about how Windows will go from being an open or transparent product development team to being one that is “silent” or “locked down”. Much of this commentary seems to center around me personally, which is fine, but talks about how there is a Sinofsky-moratorium on disclosure. I think that means I owe it to the team to provide a view on what I do mean personally (and what I personally mean to do), of course I do so knowing that just by writing this down I run this risk of this leaking and then we’ll have a round of phone calls and PR management to do just with regards to “Sinofsky’s internal memo on disclosure”. But I thought it would be worth a try.

…

Customers and partners want to know about SP1 for Vista. Actually they need to know. We want to tell them. But we want to do so when our plans and execution allow that communication to be relatively definitive. We are not there yet. So telling folks and then changing the plans causes many more challenges than readily apparent. While it might sound good on paper to be “transparent” and to give a wide open date range and a wide open list of release contents, we all know that these conversations with customers don’t end with the “we’ll ship by date and we’ve prioritized ”. Folks do want to know “did you fix this bug?” That is reasonable, but we don’t have all those answers and thus we cannot have a reasonably consistent and reliable communication…yet. We are working towards that. While there is clearly a challenge in the near term in not offering details, this challenge is much less than if we get the wrong information out there and we have to reset and unset expectations. Even among our enterprise customers, for whom this type of information is routine, we have a long history of really scrambling these most valuable customers with “information” that turned out to be “misinformation”. The difference we are trying to highlight is the difference between transparency in what we’re “thinking” and transparency in what we’re “doing”. Everyone wants to know what we’re thinking, but making it clear that those are thoughts versus “doing” is a subtlety lost on a mass audience.

…

I know many folks think that this type of corporate “clamp down” on disclosure is “old school” and that in the age of corporate transparency we should be open all the time. Corporations are not really transparent. Corporations are translucent. All organizations have things that are visible and things that are not. Saying we want to be transparent overstates what we should or can do practically—we will share our plans in a thoughtful and constructive manner.

This too leaked. It became known as the “Sinofsky omerta” (awful) and the idea of being translucent was always said snidely. We had gone nine-plus months without any substantial forward-looking discussion of Windows. The reporters covering Microsoft were restless. The leaked blog post only served to amplify any other leaks.

A college student-blogger in Australia, Long Zheng, who had become somewhat of a canary in tracking Windows evolution, happened to catch an October 2007 college recruiting talk at the University of Illinois given by Eric Traut (EricTr), a Distinguished Engineer and one of the senior architects in COSD and a core member of the Windows NT architecture team. Eric was a key inventor of the hardware emulation technology used by Apple as it transitioned microprocessors the first time in the 1990s and then an early pioneer of virtualization at a competitor to VMware, Connectix, that Microsoft acquired in 2003.

EricTr presented a wonderfully detailed talk on the role of virtualization in modern computing, describing the work he did along with a number of the most senior people on Windows. He described the architecture of a modern scalable OS and the evolution of Windows over time. He even showed some code.

To that blogger, he had just seen a demo of Windows 7 or at least exactly what Windows 7 should be.

Zheng saw the presentation on a video posted on Microsoft’s own Channel9 website and promptly wrote a blog post about the future of Windows 7, referring to the talk as a “demonstration of Windows 7.”

It wasn’t that at all. What was so exciting, though?

Over the years there was that constant murmur underlying the evolution of Windows and its expression of bloat—expansion of code size, decreasing performance, the requirement that PCs have more and more memory just to keep up. Everyone’s PC got slower over time because of bloat. EricTr’s demonstration inadvertently played into this narrative and provided a huge hope for improvements in the future.

To implement virtualization, the OS kernel was being worked on to further reduce the impact it would have on memory and CPU consumption. Eric demonstrated this new “minimal kernel,” which he dubbed MinWin. This would be exactly the solution to every problem with PCs—if Windows was good but a bit bloated, then certainly a minimum Windows, or MinWin, would be what everyone would want. It would do everything Windows did but with minimal code. Who would not want that? If one set out to create an ideal branding to describe a release of Windows for every tech enthusiast, MinWin was it. As I read the blogger’s account, I thought “Oh my gosh, this is Office Lite, but for Windows”—it was a hypothetical product that did everything it needed to do, but was easier, smaller, faster, and lighter. What’s not to love? (See 076. Betting Big to Fend Off Commoditization)

Eric’s talk was about virtualization and scaling Windows Server. It was not at all about Windows the way most people thought about it. Eric described what he was showing as follows:

We created what we call MinWin. Now, this is an internal only, you won't see us productizing this, but you could imagine this being used as the basis for products in the future. This is the windows 7 source code base, and it's about 25 megs on disk. You compare that to the four gigs on disk that the full windows Vista takes up.

Everyone on the team, most certainly a COSD architect, knew the bloggers description that this was Windows 7 was incorrect—Eric even said so. Even assuming Windows was bloated, the OS kernel wasn’t the culprit. We ended up spending a lot of time with the press figuring out how to reduce the expectations and to not consider the next Windows some sort of “new kernel.” This backfired because they heard us downplaying expectations for the release overall. With our silence, this made sense, given the Windows history of overpromise and underdeliver. As word spread, we began to hear from enterprise customers who thought that a new kernel would introduce compatibility concerns, especially in the server. This was neither a practical nor theoretical issue.

The challenge this created was indirectly related to bloat. Rather, it created a perception that Windows 7 was going to be substantially “less bloated” (whatever that meant) than Windows Vista. That prompted people to talk about comparisons to the now, post-Vista, much-loved Windows XP. Nothing in the product plan had changed, but there was suddenly a perception Windows 7 would be dramatically improved.

The public expectations for the release went up, as if they weren’t already sky high. When the outer reaches of the company saw these stories, particularly where there were direct connections to customers, the optimism was contagious.

Scary? Sure. Except we already had thousands of people working on that very opportunity—making a leaner, more efficient Windows while also making it do a lot of new stuff.

The absence of information gave people ample room to create their own worldview. Many, especially SteveB and the OEM team, wanted to use this, or one of the other rumor cycles, to get out there with more information. The team was still in the early stages of executing, and we needed to make more progress. I did not want to be out there just yet. Besides, all I could do at that moment would be counter the now exaggerated expectations which would create more confusion and likely cause another news cycle condemning Windows 7 to be a limited or incremental update to Vista.

Just as the Fall computer selling season was gearing up, a new type of computer was all the rage in Asia and about to hit the US market. Maybe these “netbook computers” would breathe some life into Vista and buy us some time before we started talking about Windows 7?

On to 093. Netbook Mania

Whenever you take on a new role you hope that you can just move forward and start work on what comes next without looking back. No job transition is really like that. In my case, even though I had spent six months “transitioning” while Windows Vista went from beta to release, and then even went to Brazil to launch Windows Vista, my brain was firmly in Windows 7. I wanted to spend little, really no, time on Windows Vista. That wasn’t entirely possible because parts of our team would be producing security and bug fixes at a high rate and continuing to work with OEMs on getting Vista to market. Then, as was inevitable, I was forced to confront the ghosts of Windows Vista and even Longhorn. In particular, there was a key aspect of Windows Vista that was heavily marketed but had no product plan and there was a tail of Longhorn technologies that needed to be brought to resolution.

Back to 090. I’m a Mac

Early in my tenure, I received an escalation (!) to “fund” Windows Ultimate Extras. I had never funded anything before via a request to fund so this itself was new, and as for the escalation. . . I had only a vague idea what Ultimate Extras were, even though I had recently returned from the Windows launch event in Brazil where I was tasked with emphasizing them as part of the rollout. The request was deemed urgent by marketing, so I met with the team, even though in my head Vista was in the rearview mirror and I had transitioned to making sure servicing the release was on track, not finishing the product.

The Windows Vista Ultimate SKU was the highest priced version of Windows, aimed primarily at Windows enthusiasts and hobbyists because it had all the features of Vista, those for consumers, business, and enterprise. The idea of Ultimate Extras was to “deliver additional features for Vista via downloadable updates over time.” At launch, these were explained to customers as “cutting-edge features” and “innovative services.” The tech enthusiasts who opted for Ultimate, for a bunch of features that they probably wouldn’t need as individuals, would be rewarded with these extra features over time. The idea was like the Windows 95 Plus! product, but that was an add-on product available at retail with Windows 95.

There was a problem, though, as I would learn. There was no product plan and no development team. The Extras didn’t exist. There was an Ultimate Extras PUM, but the efforts were to be funded by using cash or somehow finding or conjuring code. This team had gotten ahead of itself. No one seemed to be aware of this and the Extras PUM didn’t seem to think this was an issue.

As the new person, this problem terrified me. We shipped and charged for the product. To my eyes the promise, or obligation if one prefers, seemed unbounded. These were in theory our favorite customers.

The team presented what amounted to a brainstorm of what they could potentially do. There were ideas for games, utilities, and so on. None of them sounded bad, but none of them sounded particularly Ultimate, and worse: None existed.

We had our first crisis. Even though this was a Vista problem, once the product released everything became my problem.

The challenge with simply finding code from somewhere, such as a vendor, licensing from a third party, or something laying around Microsoft (like from Microsoft Research), was that the journey from that code to something shippable to the tens of millions of customers running on a million different PC configurations, in 100 languages around the world, and also accessible, safe, and secure, was months of work. The more content rich the product was, in graphics or words, the longer and more difficult the process would be. I don’t know how many times this lesson needed to be learned at Microsoft but suffice it to say small teams trying to make a big difference learned it almost constantly.

And then there was the issue of doing it well. Not much of what was brainstormed at the earliest stages of this process was overly compelling.

With nothing particularly ultimate in the wings, we were poised for failure. It was a disaster.

We set out to minimize the damage to the Windows reputation and preserve the software experience on PCs. Over the following months we worked to define what would meet a reasonable bar for completing the obligation, unfortunately I mean this legally as that was clearly the best we could do. It was painful, but the prospect of spinning up new product development meant there was no chance of delivering for at least another year. The press and the big Windows fans were unrelenting in reminding me of the Extras at every encounter. If Twitter was a thing back then, every tweet of mine would have had a reply “and…now do Ultimate Extras.”

Ultimately (ha), we delivered some games, video desktops, sound schemes, and, importantly, the enterprise features of Bitlocker and language packs (the ability to run Vista in more than one language, which was a typical business feature). It was very messy. It became a symbol of a lack of a plan as well as the myth of finding and shipping code opportunistically.

Vista continued to require more management effort on my part.

In the spring of 2007 shortly after availability, a lawsuit was filed. The complaint involved the little stickers that read Windows Vista Capable placed on Windows XP computers that manufacturers were certifying (with Microsoft’s support) for upgrade to Windows Vista when it became available. This was meant to mitigate to some degree the fact that Vista missed the back to school and holiday selling seasons by assuring customers their new PC would run the much publicized Vista upgrade. The sticker on the PC only indicated it could run Windows Vista, not whether the PC also had the advanced graphics capabilities to support the new Vista user experience, Aero Glass, which was available only on Windows Vista Home Premium. It also got to the issue of whether supporting those features was a requirement or simply better if a customer had what was then a premium PC. The question was if this was confusing or too complex for customers to understand relative to buying a new PC that supported all the features of Vista.

A slew of email exhibits released in 2007 and 2008 showed the chaos and tension over the issue, especially between engineering, marketing, sales, lawyers, and the OEMs. One could imagine how each party had a different view of the meaning of the words and system requirements. I sent an email diligently describing the confusion, which became an exhibit in the case along with emails from most every exec and even former President and board member Jon Shirley (JonS) detailing their personal confusion.

The Vista Capable challenge was rooted in the type of ecosystem work we needed to get right. Intel had fallen behind on graphics capabilities while at the same time wanted to use differing graphics as part of their price waterfall. Astute technical readers would also note that Intel’s challenge with graphics was rooted deeply in their failure to achieve critical mass for mobile and the resulting attempt to repurpose their failed mobile chipsets for low-end PCs. PC makers working to have PCs available at different price points loved the idea of hardline differentiation in Windows, though they did not like the idea having to label PCs as basic, hence the XP PCs were labeled “capable.” Also worth noting was that few Windows XP PCs, especially laptops, were capable of the Home Premium experience due to the lack of graphics capabilities. When Vista released, new PCs would have stickers stating they ran Windows Vista or Windows Vista Basic, at least clarifying the single sticker that was placed on eligible Windows XP computers.

Eventually, the suit achieved class-action status, always a problem for a big company. The fact that much of the chaos ensued at the close of a hectic product cycle only contributed to this failure. My job was to support those on the team that had been part of the dialogue across PC makers, hardware makers, and the numerous marketing and sales teams internally.

The class-action status was eventually reversed, and the suit(s) reached a mutually agreeable conclusion, as they say. Still, it was a great lesson in the need to repair both the relationships and the communication of product plans with the hardware partners, not to mention to be more careful about system requirements and how features are used across Windows editions.

In addition to these examples of external issues the Vista team got ahead of itself regarding issues related to code sharing and platform capabilities that spanned multiple groups in Microsoft.

The first of these was one of the most loved modern Windows products built on top of Windows XP, Windows Media Center Edition (WMC, or sometimes MCE). In order to tap into the enthusiasm for the PC in the home and the convergence of television and PCs, long before smartphones, YouTube, Netflix, or even streaming, the Windows team created a separate product unit (rather than an integrated team) that would pioneer a new user interface, known as the 10-foot experience, and a new “shell” (always about a shell!) designed around using a PC with a remote control to show live television, home DVD discs, videos, and photos on a big screen, and also play music. This coincided with the rise in home theaters, large inexpensive disk drives capable of storing a substantial amount of video, camcorders and digital cameras, and home broadband internet connections. The product was released in 2002 and soon developed a relatively small but cultlike following. It even spawned its own online community called “Green Button,” named after the green button on the dedicated remote control that powered the shell’s 10-foot user interface.

The product was initially sold only with select PCs because of the need for specific hardware capabilities. Later, with Windows Vista (and Windows 7), WMC was included in the premium editions. The usage based on both sales and the telemetry collected anonymously was low and the repeat usage was a small fraction of even those customers. Nevertheless, there were vocal fans, and we had no plans to give up.

WMC was hitting real challenges in the market, though, especially in the United States, where television was moving from analog CATV to digital, and with digital came required set-top boxes and a new and not quite available technology called CableCARD, required to decrypt the cable signal. Not only did this make things difficult for WMC, but it made things difficult for anyone wanting to view cable tv, as if the encrypted analog channels were not difficult enough already. Everyone trying to use CableCARD had a story of trying to activate the card that included essentially a debug interface, typing in long hex strings, awaiting a “ping” back from the mysterious “head end.” The future for the innovative TV experience in WMC was looking bleak.

Additionally, WMC was bumping up against the desires of the Xbox team to expand beyond gaming. The Xbox team had recently unveiled a partnership with the new Netflix streaming service to make it available on Xbox. Some of the key leaders on WMC had moved from Windows to the Xbox organization and began to ask about moving the WMC team over with them.

At the time, I was up to my elbows in looking at headcount and orgs and was more than happy to move teams out of Windows, especially if it was straightforward, meaning they could just pick up the work and there was no shipping code being left behind unstaffed. This quickly became the first debate, in my entire time at Microsoft, over headcount and budgets because the destination organization was under tight revenue and expense review.

The WMC team was, surprisingly, hundreds of people, but it also had dependencies on numerous other teams across networking, graphics, and the core user experience. We could easily move the core WMC team but getting a version of WMC integrated with the new engineering system and to-be-developed delivery schedule (which we were planning) was a concern. Of course the team wanted to move to Xbox but had little interest in delivering WMC back to Windows, especially as the overall engineering process changed. They literally thought we would just move all the headcount and team and then create a new WMC team. They had awful visions of being a component on the hook to meet a schedule that was unappealing. We could not just give up on WMC, even with such low usage, without some sort of plan.

I learned that moving humans and associated budgets was fine. But CollJ had been working with finance on headcount and was told we had to also move revenue, something I had never heard of. I had no idea how that might even work. In Vista, MediaCenter was part of the Home Premium and Ultimate SKU, and no longer a separate product like it was for Windows XP. How could one arrive at the revenue for a single feature that was part of a SKU of Vista? Perhaps back when WMC was a separate product this made sense, but at the time it seemed like an accounting farce. In fact, the judge in the Vista Capable lawsuit even removed class action status because of an inability to determine which customers bought Windows Vista because of which premium features.

Microsoft had been divided into seven externally reported business segments; each quarterly earnings filing with the SEC reported a segment as though it were an independent business. The result of this was more visibility for the financial community, which was great. Internally these segments did not line up with the emphasis on code-sharing, feature bundling, or shared sales efforts. For example, from a product development perspective there was a lot of code sharing across all products—this was a huge part of how Microsoft developed software. Costs for each segment could never accurately reflect the R&D costs. An obvious example was how much of Windows development could/would/should be counted in the Server and Tools segment, given that so much of the server product was developed in the Windows segment.

My view was that there was a $0 revenue allocation for any specific feature of Windows—that was the definition of product-market fit and the reality that nobody bought a large software product for any single feature. This was always our logic in Office, even when we had different SKUs that clearly had whole other products to justify the upsell. Office Professional for years cost about $100 more than Office Standard simply for the addition of the Access database. We never kidded ourselves that Access was genuinely worth billions of dollars on its own.

Over several weeks, however, we had to arrive at some arbitrary number that satisfied finance, accounting, tax, and regulatory people. To do this, we moved the hundreds of people working on WMC to XBox along with a significant amount of Windows unit revenue per theoretical WMC customer. It wasn’t my math, but it added up to a big number moving to the Entertainment segment. In exchange, we hoped we would get back a WMC that had improved enough to satisfy an enthusiastic fanbase, knowing that the focus was shifting to Xbox.

Given the fanbase externally, including several of the most influential Windows writers in the press, there was a good chance that such a seemingly arbitrary organization move would leak. The move would be viewed by many as abandoning WMC. I used an internal blog post to smooth things over, describing my own elaborate home audio/video system, which included Windows Vista Ultimate and pretty much every Microsoft product. In doing this, I chalked up a ton of points from tech enthusiast employees, showing that I had a knee-deep knowledge of our products—something most assumed an Office person wouldn’t have, perhaps like BillG not understanding why a C++ developer knew Excel 15 years earlier when I first interviewed to work for him. In practice, my post made it clear that keeping this technology working to watch TV casually at home was impossible. I hated my home setup. It was ridiculous.

As part of the final Longhorn cleanup, I also needed to reconcile the strategic conflicts between the Windows platform and the Developer Tools platform, and as the new person I found myself in the middle. It was a battle that nobody wanted to enter for fear of the implications of making the wrong technology bet.

The Developer division created the .NET platform starting in the early 2000s to build internet-scale, web server applications delivered through the browser primarily to compete with Java on the server. It was excellent and remains loved, differentiated, and embraced by the corporate world today. It crushed Java in the enterprise market. It was almost entirely responsible for the success Windows Server saw in the enterprise web and web application market.

The .NET client (desktop programs one would use on a laptop) programming model was built “on top” of the Windows programming model, Win32, with little coordination or integration with the operating system or the .NET server platform. This created a level of architectural and functional complexity along with application performance and reliability problems resulting in a messy message to developers. Should developers build Win32 apps or should they build .NET apps? While this should not have been an either/or, it ended up as such because of the differing results. Developers wanted the easier-to-use tools and language of .NET, but they wanted the performance and integration with Windows that came from Win32/C++. This was a tastes great, less filling challenge for the Developer division and Windows. In today’s environment, there are elements of this on the Apple platforms when it comes to SwiftUI versus UIKit as searching for that debate will find countless blog posts on all sides.

It was also a classic strategic mess created when a company puts forth a choice for customers without being prescriptive (or complete). Given a choice between A and B, many customers naturally craft the third choice, which is the best attributes of each, as though the code was a buffet. Still other customers polarize and claim the new way is vastly superior or claim the old way is the only true way and until the new way is a complete superset they will not switch. Typical.

Longhorn aimed to reinvent the Win32 APIs, but with a six-year gap from Windows XP it was filled by the above .NET strategy when it came to Microsoft platform zealots. The rest of the much larger world was focused on HTML and JavaScript. At the same time, nearly all commercial desktop software remained Win32, but the number of new commercial desktop products coming to market was diminishingly small and shrinking. Win32 was on already life support.

The three pillars of Longhorn, WinFS, Avalon, and Indigo, failed to make enough progress to be included in Vista (together these three technologies were referred to as WinFX.) With Vista shipping, each of these technologies found new homes, or were shut down. I had to do this last bit of Vista cleanup which lingered long after the product was out the door.

WinFS receded into the world of databases where it came from. As discussed, it was decidedly the wrong approach and would not resurface in any way. Indigo was absorbed into the .NET framework where it mostly came from. Avalon, renamed Windows Presentation Foundation (WPF), remained in the Windows Client team, which meant I inherited it.

WPF had an all-expansive vision that included a unique language (known as XAML) and a set of libraries for building graphical and data-rich applications. Taken together and to their logical end point, the team spoke of Avalon as being a replacement for HTML in the browser and also .NET on the client. This was the reason work had stopped on Internet Explorer, as the overall Longhorn vision was to bring this new level of richness to browsing. From the outside (where I was in Office) it seemed outlandish, and many on the outside agreed particularly those driving browser standards forward. Still, this opened a second front in the race to improve Win32, in addition to .NET. All along WPF would claim allegiance and synergy with .NET but the connections were thin, especially as WPF split into a cross-platform, in-browser runtime and a framework largely overlapping with .NET. When I would reflect on WPF I would have flashbacks to my very first project, AFX, and how we had created a system that was perfectly consistent and well-architected yet unrelated to everything, in addition to being poorly executed.

But what should developers have used—classic Win32, or the new frameworks of .NET, WPF, or something else I just learned about called Jolt? These were big decisions for third-party developers because there was an enormous learning curve. They had to choose one path and go with it because the technologies all overlapped. That was why I often called these frameworks “fat frameworks,” because they were big, slow, and took up all the conceptual room. Importantly, the common thread among the frameworks was their lack of coherence with Win32—they were built on top of Win32, duplicating operating system capabilities. Fat was almost always an insult in software.

The approach taken meant the idea of both .NET on the client and WPF were built on the shakiest of foundations, and what we were seeing with .NET on the client was as predicted based on all past experiences. I had a very long and ongoing email thread (which I later turned into an Office Hours blog post) with the wonderfully kind head of Developers, S. Somasegar (Somase, aka Soma), on this topic where I pushed and pushed on the challenges of having fat frameworks emerge while we have a desire to keep Windows relevant. As I wrote the email, I was struck by how similar this experience was to the one I had twenty years earlier as we built, and then discarded, the fat framework called AFX. While history does not repeat itself, it does rhyme. Many would debate the details, but fundamentally the team took the opposite path that we did years earlier. I recognize writing this today that some are still in the polarized camp and even today remain committed to some of these technologies. One of the most successful tools Microsoft ever released was Visual Basic, which was an enormously productive combination of framework, programming language, and development tool. That was not what we had here.

Nothing with developers and Microsoft was ever simple. Microsoft’s success with developers was often quite messy on the ground.

Along with large product development teams, there was also a large evangelism team responsible for gaining support or traction of new technologies with developers. This team was one of the gems of Microsoft. It masterfully built a community around developer initiatives. It was largely responsible for taking the excellent work in .NET for Server and landing it with thousands of enterprise developers. In fact, part of that challenge was that the evangelism team had moved to the Developer division where the org chart spoke more loudly than the overall company mission and the priority and resourcing of evangelism tilted heavily toward .NET in all forms over the declining Win32 platform.

As a counterexample, the evangelism team seeing the incoherence in product execution provided significant impetus to force the Windows NT product to fully adopt the Windows API paving the way for Microsoft’s Win32 success. I previously shared my early days story as a member of the C++ team pointing out how Windows NT differed from classic Windows APIs in Chapter II, I Shipped, Therefore I am. Many of the lessons in how divergent the two Windows APIs were surfaced in the well-known Windows NT porting lab run by the evangelism team, where developers from around the world would camp out for a few weeks of technical support in moving applications to Windows NT or Windows 95, before both shipped.

Perhaps an organization-driven result was a reasonable tradeoff, but it was never explicit, as was often the case with cross-divisional goals. In many ways the challenges were accelerated by our own actions, but without ever making that a clear goal we would spend too much time in meetings dancing around the results we were seeing in the erosion of Win32.

The evangelism team didn’t ever fail at their mission and reliably located or created champions for new technologies. It seemed there were always some outside Microsoft looking to get in early on the next Microsoft technologies. The evangelism team was expert at finding and empowering those people. They could summon the forces of the book, consulting, and training worlds to produce volumes of materials—whole books and training courses on XAML were available even before Vista was broadly deployed. Although WPF had not shipped with any product, it had a strong group of followers who trusted Microsoft and made a major commitment to use WPF for their readers, clients, or customers (as authors, consultants, or enterprise developers). Before Vista shipped, WPF appeared to have initial traction and was a first-class effort, along with .NET on the client. WPF had an internal champion as well. The Zune team used early portions of WPF for software that accompanied their ill-fated, but well-executed, iPod competitor.

Things were less clear when it came to WPF and Vista. WPF code would ship with Vista, but late in the product cycle the shiproom command came down that no one should use WPF in building Vista because of the burden it would place on memory footprint and performance of applications. This caused all sorts of problems when word spread to evangelists (and their champions). People were always looking for signals that Microsoft had changed its mind on some technology. Seeing the risk to WPF by not being performant, the Avalon team (the team was also called Avalon) set out to shrink WPF and XAML into a much smaller runtime—something akin to a more focused and scenario specific product. This was a classic Windows “crisis” project and was added to the product plans sometime in 2005 or early 2006, called Jolt, while the rest of Longhorn was just trying to finish with quality.

Jolt was designed to package up as much of WPF as could fit in a single ActiveX control, also called WPF/E for WPF everywhere, and then later in final form called Silverlight. This would make it super easy to download and use. Streaming videos and small graphical games to be used inside of a browser became the focus. Sound like Adobe Flash? Yes, Jolt was being pitched internally as Microsoft’s answer to Adobe Flash. To compete effectively with Flash, Jolt would also aim to be available across operating systems and browsers—something that made it even less appealing to a Windows strategy, and more difficult to execute. I was of the view that Adobe Flash was on an unsustainable path simply because it was both (!) a fat framework and also an ActiveX control. By this time, ActiveX controls, which a few years earlier were Microsoft’s main browser extensibility strategy, had come to be viewed as entirely negative because they were not supported in other browsers and because they were used as malware by tricking people into running them. The technical press and haters loved to refer to ActiveX as CaptiveX. As an aside, one of my last projects working on C++ was to act overly strategic and push us to adopt the predecessor to ActiveX, known as OLE Controls, and implement those in our C++ library affording great, but useless, synergy with Visual Basic.

For me, this counted as two huge strikes against Jolt. Imagine a strategic project, at this stage in the history of the company, that came about from a crisis moment trying to find any code to ship while also using the one distribution method we had already condemned (for doing exactly the same thing previously.) I did not understand where it was heading.

Somehow, I was supposed to reconcile this collection of issues. When I met with the leaders of the team, they were exhausted though still proud of what they had accomplished. When I say exhausted, I mean physically drained. The struggle they had been through was apparent. Like many who had worked on the three pillars of Vista, the past few years had been enormously difficult. They wanted to salvage something of their hard work. I couldn’t blame them. At the same time, those weren’t the best reasons to ship code to hundreds of thousands of developers and millions of PCs without a long-term strategy for customers. My inclination was to gently shut down this work rather than support it forever knowing there was no roadmap that worked.

The team, however, had done what Windows teams did often—evangelized their work and gained commitments to foreclose any attempt to shut down the effort. With the help of the evangelism team, they had two big customers lined up in addition to the third parties that the evangelism group had secured. In addition to Zune, the reboot of the Windows Phone (which would become Windows Phone 7) would have a portions of the developer strategy based on Jolt—not the phone itself, but it would use Jolt as a way to make it easy for developers to build apps for the phone operating system (prior to this time, apps for the phone were built to basically use ancient Windows APIs that formed the original Windows CE operating system for phones). The Developer division wanted to bring WPF and Indigo into the .NET framework and create one all-encompassing mega-framework for developers but branded as the new version of .NET. The way the .NET framework generally addressed strategic issues was to release a new .NET that contained more stuff under the umbrella of a new version with many new features, even if those new features strategically overlapped with other portions of .NET.

Given all this, the choice was easy for me. As they requested, the Phone team and the Developer division took over responsibility for the Jolt and WPF teams, respectively. It was a no-brainer. Eventually the code shipped with Windows 7 as part of a new .NET framework, which planned anyway. Most everyone on the Windows team, particularly the performance team in COSD and the graphics team in WEX, were quite happy with all of this. The Windows team had always wanted to focus on Win32, even though there was little data to support such a strategy.

While this decision clarified the organization and responsibility, it in no way slowed the ongoing demise of Windows client programming nor did it present a coherent developer strategy for Microsoft. The .NET strategy remained split across WPF and the old .NET client solutions, neither of which had gained or were gaining significant traction—even with so much visible support marshalled by the evangelism team. Win32 had slowed to a crawl, and we saw little by way of new development. It was discouraging.

Again, many reading this today will say they were (or remain) actively developing on one or the other. My intent isn’t to denigrate any specific effort that might be exceedingly important to one developer or customer, but simply to say what we saw happening in total across the ecosystem as evidenced by the data we saw from the in-market telemetry. One of the most difficult challenges with a developer platform is that most developers make one bet on a technology and use it. They do not see histograms or pie charts of usage because they are 100% committed to the technology. They are also vocal and with good reason, their livelihoods depend on the ongoing health of a technology.

With everything to do with developers, APIs, runtimes, and the schism in place, the problem or perhaps solution was this was all “just code,” as we would say. What that means is twofold. First, there was always a way to demonstrate strategy or synergy. In a sense, this was what we’d disparagingly call stupid developer tricks. These were slides, demonstrations, or strategic assertions that showed technical relationships between independently developed, somewhat-overlapping, and often intentionally different technologies. The idea was to prove that the old and new, two competing new, or two only thematically connected technologies were indeed strategically related. My project to support OLE Controls in C++ was such a trick.

Technically these tricks were the ability to switch languages, use two strategies at the same time, or tap into a Win32 feature from within some portion of something called .NET. A classic example of this was during the discussion about where Jolt should reside organizationally. It was pointed out that Jolt had no support for pen computing or subsequently touch (among other things) since there was none in .NET or WPF to begin with. These were both key to Windows 7 planning efforts. Very quickly the team was able to demonstrate that it was entirely possible to directly call Win32 APIs from within Jolt. This was rather tautological, but also would undermine the cross-platform value proposition of Jolt and importantly lacked tools and infrastructure support from Jolt.

Second, this was all “just code,” which meant at any time we could change something and maybe clean up edge cases or enable a new developer trick. Fundamentally, there was no escaping that Win32, .NET, WPF, and even Jolt were designed separately and for different uses with little true architectural synergy. Even to this day, people debate these as developers do—this is simply a Microsoft-only version of what goes on across the internet when people debate languages and runtimes. Enterprise customers expect more synergy, alignment, and execution from a single company. More importantly, developers making a bet on the Microsoft platform expect their choices to be respected, maintained, and enhanced over time. It is essentially impossible to do that when starting from a base as described, and as Microsoft amassed from 2000 to 2007.

As simple as it was to execute moving these teams, in many ways it represented a failure on my part, or, more correctly, a capitulation. I often ask myself if it would have been better to wind down the efforts rather than allow the problem to move to another part of the company. I was anxious to focus and move on, but it is not clear that was the best strategy when given an opportunity to bring change and clarity when developers so clearly were asking for it, even if it meant short-term pain and difficulty. It would have been brutal.

It grew increasingly clear that there were no developers (in any significant number, not literally zero) building new applications for Windows, not in .NET or WPF or Win32. The flagship applications for Windows, like Word, Excel, and others from Microsoft along with Adobe Photoshop or Autodesk AutoCAD, were all massive businesses, but legacy code. The thousands of IT applications connecting to corporate systems, written in primarily Visual Basic, all continued daily use but were being phased out in favor of browser-based solutions for easier deployment, management, portability, and maintenance. They were not using new Windows features, if any existed. The most active area for Windows development was gaming, and those APIs were yet another layer in Windows, called DirectX, which was part of WEX and probably the most robust and interesting part of Win32. Ironically, WPF was also an abstraction on top of those APIs. ISVs weren’t using anything new from Microsoft, so it wasn’t as though we had a winning strategy to pick from.

Further evidence of the demise of Win32 arose as early as 1996 from Oracle’s Larry Ellison, who put forth the idea of a new type of browser-only computer, the Network Computer. (Sound like a Chromebook?) At the time, Marc Andreessen famously said that Windows would be become, simply, a “poorly debugged set of device drivers,” meaning that the only thing people would care about would be running the browser. Years later, Andreessen would point out the original was based on something Bob Metcalf had said. Eight years later we had reached the point where the only new interesting mainstream Windows programs were browsers, and at this time only Firefox was iterating on Windows and the only interesting thing about Firefox was what it did with HTML, not Windows. The device drivers still had problems in Vista. In fact, that was the root of the Vista Capable lawsuit!

Moving WPF and Jolt to their respective teams, while an admission of defeat on my part, could best be characterized as a pocket veto. These were not the future of Windows development, but I wasn’t sure what would be. We in Windows were doubling down on the browser for sure, but not as leaders, rather as followers. We had our hands full trying to debug the device drivers.

XAML development continues today, though in a much different form. While it does not make a showing in the widely respected Stack Overflow developer survey of over 80,000 developers in 181 countries, it maintains a spot in the Microsoft toolkit. XAML will come to play an important role in the development of the next Windows release as well.

With the team on firm(er) ground and now moving forward we finally started to feel as though we had gained some control. By September 2007 we were in beta test with the first service pack for Vista, which OEMs and end-users anxiously awaited.

The team was in full execution mode now and we had milestones to plow through. While I felt we were heading in the right direction and cleared the decks of obvious roadblocks, there was a looming problem again from Cupertino. What was once a side bet for Microsoft would prove to be the most transformative invention of the 21st century…from Apple.

On to 092. Platform Disruption…While Building Windows 7 [Ch. XIII]

Advertising is much more difficult than just about everyone believes to be the case. In fact, one of the most challenging tasks for any executive at any company is to step back and not get involved in advertising. It is so easy to have opinions on ads and really randomize the process. It is easy to see why. Most of us buy stuff and therefore consume advertising. So it logically follows, we all have informed opinions, which is not really the case at all. Just like product people hate everyone having opinions on features, marketing people are loathe to deal with a cacophony of anecdotes from those on the sidelines. Nothing would test this more for all of Microsoft than Apple’s latest campaign that started in 2006. I’d already gone through enough of watching advertising people get conflicting and unreconcilable feedback to know not to stick my nose in the process.

Back to 089. Rebooting the PC Ecosystem

Hardcore Software by Steven Sinofsky is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

“I’m a Mac.”

“And, I’m a PC.”

The “Get a Mac” commercials, starting in 2006, changed the competitive narrative overnight and were a painful gut punch welcoming me to Windows.

They were edgy, brutal in execution, and they skewered Windows with facts. They were well done. (Though it always bothered me that PC Guy had a vague similarity to the late and much-loved Paul Allen, Microsoft’s cofounder long focused on science and philanthropy.) Things that drove Windows fans crazy like “no viruses” on Mac were not technically true, but true in practice because, mostly, why bother writing viruses for Macs with their 6 percent share? That’s what we told ourselves. In short, these commercials were devastating.

They probably bumped right up against a line, but they effectively tapped into much of the angst and many of the realities of PC ownership and management. Our COO and others were quite frustrated by them and believed the commercials not only to be untrue, but perhaps in violation of FTC rules.

They were great advertising. Great advertising is something Apple seemed to routinely accomplish, while Microsoft found it to be an elusive skill.

For its first twenty years, Microsoft resisted broad advertising. The company routinely placed print ads in trade publications and enthusiast magazines, with an occasional national newspaper buy for launches. These ads were about software features, power, and capabilities. Rarely, if ever, did Microsoft appeal to emotions of buyers. When Microsoft appeared in the national press, it was Bill Gates as the successful technology “whiz kid” along with commentary on the growing influence and scale of the company.

With that growing influence in the early 1990s and a business need to move beyond BillG, a huge decision was made to go big in advertising. Microsoft retained Wieden+Kennedy, the Portland-based advertising agency responsible for the “Just Do It” campaign from Nike, among many era-defining successes. After much consternation about spending heavily on television advertising, Microsoft launched the “Where do you want to go today?” campaign in November 1994.

Almost immediately we learned the challenges of advertising. The subsidiaries were not enamored with the tagline. The head of Microsoft Brazil famously pushed back on the tagline, saying the translation amounted to saying, “do you want to go to the beach today?” because the answer to the question “Where do you want to go?” in Brazil was always “the beach.” The feedback poured in before we even started. It was as much about the execution as the newness of television advertising. Everyone had an opinion.

I remember vividly the many pitches and discussions about the ads. I can see the result of those meetings today as I rewatch the flagship commercial. Microsoft kept pushing “more product” and “show features” and the team from W+K would push back, describing emotions and themes. The client always wins, and it was a valuable lesson for me. Another a valuable lesson, Mike Maples (MikeMap) who had seen it all at IBM pointed out just before the formal go ahead saying something like “just remember, once you start advertising spend you can never stop. . .with the amount of money we are proposing we could hire people in every computer store to sell Windows 95 with much more emotion and information. . .” These were such wise words, as was routine for Mike. He was right. You can never stop. TV advertising spend for a big company, once started, becomes part of the baseline P&L like a tax on earnings.

The commercials were meant to show people around the world using PCs, but instead came across almost cold, dark, and ominous as many were starting to perceive Microsoft.  That was version 1.0. Over the next few years, the campaign would get updates with more colors, more whimsy, and often more screenshots and pixels.

What followed was the most successful campaign the company would arguably execute, the Windows 95 launch. For the next decade, Microsoft would continue to spend heavily, hundreds of millions of dollars per year, though little of that would resonate. Coincident with the lukewarm reception to advertising would be Microsoft’s challenges in branding, naming, and in general balancing speeds and feeds with an emotional appeal to consumers. Meanwhile, our enterprise muscle continued to grow as we became leaders in articulating strategy, architecture, and business value.

In contrast, Apple had proven masterful at consumer advertising. From the original 1984 Superbowl ad through the innovative “What’s on your PowerBook?” (1992) to “Think Different” (1997-2000) and many of the most talked about advertisements of the day such as “C:\ONGRTLNS.W95” in 1995 and “Welcome, IBM. Seriously” in 1981, Apple had shown a unique ability to get the perfect message across. The only problem was that their advertising didn’t appear to work, at least as measured by sales and/or market share. The advertising world didn’t notice that small detail. We did.

Starting in 2006 (Vista released in January 2007), Apple’s latest campaign, “Get a Mac” created an instant emotional bond with everyone struggling with their Windows PC at home or work, while also playing on all the stereotypes that existed in the Windows v. Mac battle—the nerdy businessman PC slave versus the too cool hipster Mac user.

The campaign started just as I joined Windows. I began tracking the commercials in a spreadsheet, recording the content and believability of each while highlighting those I thought particularly painful in one dimension or another. (A Wikipedia article would emerge with a complete list, emphasizing the importance of the commercials.) I found myself making the case that the commercials reflected the state of Windows as experienced in the real world. It wasn’t really all that important if Mac was better, because what resonated was the fragility of the PC. There was a defensiveness across the company, a feeling of how the “5% share Mac” could be making these claims. I managed a bit of a row with the COO who wanted to go to the FTC and complain that Apple was not telling the truth.

Windows Vista dropped the ball. Apple was there to pick it up. Not only with TV commercials and ads, but with a resurging and innovative product line, one riding on the coattails of Wintel. The irony that the commercials held up even with the transition to Intel and a theoretically level playing field only emphasized that the issue was software first and foremost, not simply a sleek aluminum case.

While the MacBook Air was a painful reminder of the consumer offerings of Windows PCs, the commercials were simply brutal when it came to Vista. There were over 50 commercials that ran from 2006-2009, starting with Apple’s transition to Intel and then right up until the release of Windows 7 when a new commercial ran on the eve of the Windows 7 launch. Perhaps the legacy of the commercials was the idea that PCs have viruses and malware and Macs do not. No “talking points” about market share or that malware targets the greatest number of potential victims or simply that the claim was false would matter. There’s no holding back, this was a brutal takedown, and it was effective. It was more effective in reputation bashing, however, than in shifting unit share.

One of the most memorable ones for me was “Security” which highlighted the Windows Vista feature designed to prevent viruses and malware from sneaking on your PC, called User Account Control or UAC which had become a symbol of the annoyance of Vista—so much so our sales leaders wanted us to issue a product change to remove it. There’s some irony in that this very feature is not only implemented across Apple’s software line today, but far is more granular and invasive. That should sink in. Competitively we all seem to become what we first mock.

Something SteveB always said when faced with sales blaming the product group and the product group blaming sales for something that wasn’t working, was “we need to build what we can sell, and sell what we build.” Windows Vista was a time where we had the product and simply needed to sell what we had built, no matter what.

The marketing team (an organization peer to product development at this time) was under a great deal of pressure to turn around the perceptions of Vista and do something about the Apple commercials. It was a tall order. The OEMs were in a panic. It would require a certain level of bravery to continue to promote Vista, perhaps not unlike shipping Vista in the first place. The fact that the world was in the midst of what would become known as the Global Financial Crisis with PC sales taking a dive did not help.

Through a series of exercises to better come up with a point of attack the team came up with the idea that maybe too many people were basing their views of Windows Vista on hearsay and not actual experience. We launched a new campaign “Mojave Experiment” that took a cinéma vérité approach to showing usability studies and focus groups for yet to be released and experimental version of Windows Mojave. After unsolicited expressions of how bad Vista was, the subjects were given a tour of Windows Mojave. The videos were not scripted, and the people were all real, as were the reactions. Throughout the case study, and the associated online campaign, the subjects loved what they were being shown. Then at the end of the videos, the subjects were told the surprise—this was Windows Vista. To those old enough to know, it had elements of the old “Folger’s Coffee” or “I Can’t Believe It’s Not Butter” commercials, classic taste-test advertising.

The industry wasn’t impressed. In fact, many took to blog posts to buzzsaw the structure of the tests and way subjects were questioned and shown the product. One post in a Canadian publication ran with the headline “Microsoft thinks you’re stupid” in describing the campaign. This was right on the heels of the Office campaign where we called our customers dinosaurs. We had not yet figured out consumer advertising.

We still had to sell the Vista we had built. We needed an approach that at the very least was credible and not embarrassing, but importantly at least hit on the well-known points about Apple Macintosh that everyone knew to be true. Macs were expensive and as a customer your choices were limited.

Apple’s transition to Intel was fascinating and extraordinarily well executed, releasing PCs that were widely praised, featuring state-of-the-art components, an Intel processor unique to Apple at launch, and superior in design and construction to any Windows PC. The new premium priced Intel Macs featured huge and solid trackpads, reliable standby and resume, and super-fast start-up. All things most every Windows PC struggled to get right. We consistently found ourselves debating the futility of the Apple strategy offering expensive hardware. The OEMs weren’t the only ones who consistently believed cheaper was better, but that was also baked into how Microsoft viewed the PC market. Apple had no interest in a race to profitless price floors and low margins, happily ceding that part of the market to Windows while selling premium PCs at relatively premium prices. In fact, their answer to the continued lowering of PC prices was to release a pricey premium PC.

The original MacBook Air retailed for what seemed like an astonishing $1,799. That was for the lowest specification which included a 13” screen and a meager 2GB main memory, an 80GB mechanical hard drive, and a single USB port and obscure video output port, without an DVD drive or network port. For an additional $1000, one could upgrade to a fancy new solid state disk drive which was still unheard of on mainstream Windows PCs.

As it would turn out the MacBook Air was right in the middle of the PC market, and that’s just how PC makers liked it, stuck between the volume PC and premium PC, neither here nor there. An example of most popular laptop configuration was the Dell Inspiron 1325. The 1325 was a widely praised “entry level” laptop with an array of features, specs, and prices. In fact, on paper many PC publications asked why anyone would buy an overpriced Macintosh. The Dell 1325 ranged in prices from $599 to about $999 depending on how it was configured. The configuration comparable to a MacBook Air was about $699 and still had 50% more memory and three times the disk space. As far as flexibility and ports, the 1325 featured not just a single USB port but two, a VGA video connector, audio jacks, Firewire (for an iPod!), an 8 in 1 media card reader, and even something called an ExpressCard for high-speed peripherals. Still, it was a beast, while the same width and length it was twice as thick and clearly more dense weighing almost 5lbs at the base configuration compared to the 3lb MacBook Air. As far as battery life, if you wanted to be comparable to the Air then you added a protruding battery that added about a pound in weight and made it so the laptop wouldn’t fit in a bag. Purists would compare to the MacBook (not the Air), as we did in our competitive efforts, but the excitement was around the Air. The regular 13” MacBook weighed about 4.5lbs and cost $1299, which would make it a more favorable comparison. It was clear to me that the Air was the future consumer PC as most PC users would benefit from lighter weight, fewer ports, and a simpler design. As much as I believed this, it would take years before the PC industry broadly recognized that “thin and light” was not a premium product. The MacBook Air would soon end up priced at a $999 entry price, which is when it began to cause real trouble for Windows PCs.

The higher-end MacBook Air competitor from the PC world was the premium M-series from Dell. Incidentally, I’m using Dell as an example, HP and Lenovo would be similar in most every respect. The Dell XPS M1330, the forerunner to today’s wonderful Dell XPS 13, was a sleeker 4lbs also featuring a wedge shape. With the larger and heavier battery there was a good 5 hours of runtime. Both Dells featured plastic cases with choices of colors. It too had models cheaper than the MacBook or MacBook Air but could be priced significantly more by adding more memory, disk storage, better graphics, or a faster CPU.

A key factor in the ability for the Mac to become mainstream, however, was the rise in the use of the web browser for most consumer scenarios. A well-known XKCD cartoon featured two stick figures, one claiming to be a PC and another claiming to be a Mac, with the joint text pointing out “and since you do everything through a browser now, were pretty indistinguishable.” Apple benefitted enormously from this shift, or disruption, especially as Microsoft continued to invest heavily in Office for the Mac. The decline in new and exciting Windows-based software described in the previous section proved enormously beneficial to Apple when it came to head-to-head evaluation of Mac versus Windows. Simply running Office and having a great browser, combined with the well-integrated Apple software for photos, music, videos, and mail proved formidable, and somewhat enduring with the rise in non-PC devices.

We were obsessed with the pricing differences. We often referred to these higher prices as an “Apple Tax” and even commissioned a third party to study the additional out of pocket expenses for a typical family when buying Macs versus Windows PCs. A whitepaper was distributed with detailed comparison specifications showing the better value PCs offered. In April 2008 we released a fake tax form itemizing (groan) the high cost of Apple hardware.

From our perspective or perhaps rationalization this was all good. Consumers had choice, options, and flexibility. They could get the PC they needed for their work and pay appropriately, or not. This thesis was reinforced by the sales of both PCs and Macs no matter what anyone was saying in blogs. The PC press loved this flexibility. Retailers and OEMs relied on the variety of choices to maximize margin. Retailers in particular struggled with Apple products because they lacked key ways to attach additional margin, such as upsell or service contracts, not to mention Apple’s lack of responsiveness to paying hefty slotting and co-advertising fees.

Choosing a PC while a complicated endeavor was also the heart and soul of the PC ecosystem. Once Apple switched to Intel, there was a broad view that the primary difference between Mac and Windows now boiled down to the lack of choice and high price and lack of a compatible software and peripheral ecosystem that characterized Macintosh.

To make this point, Microsoft launched a new campaign the “Laptop Hunter” that ran in 2009. In these ads, typical people are confronted outside big box retailers trying to decide what computer to buy. A PC or a Mac? In one ad, “Lauren” even confesses she is not cool enough for a Mac while noticing just how expensive they are (NB, Lauren is almost the perfect representation of a Mac owner.) She heads over to a showroom with a vast number of choices and whittles her way down to a sub $1000 PC with everything she needs. Another success.

Not to belabor this emerging theme, but no one believed these ads either. Only this time, the critics and skeptics were livid as it appeared Lauren was an actress and that called into question the whole campaign. In addition, Apple blogs went frame-by-frame in the ad to “prove” various aspects of the shoot were staged or simply not credible. The tech blogs pointed out the inconsistencies or staged aspects of Lauren’s requirements as being designed to carefully navigate the Apple product line.

Laptop Hunter offers some insight into how addictive (or necessary) television advertising became and the scale at which Microsoft was engaging. The television campaign debuted during the NCAA basketball tournament in the US, prime time. It was supported by top quality network prime shows (Grey's Anatomy, CSI, The Office, Lost, American Idol), late night staple programming (Leno, Letterman, Kimmel, Conan, and Saturday Night Live) and major sports events and playoff series (NCAA Basketball, the NBA, MLB, and the NHL). Cable networks included Comedy Central, Discovery, MTV, VH1, History and ESPN. The online campaign included home page execution on NYTimes.com, as well as “homepage take-overs” (the thing to do back then) on WSJ, Engadget, and CNN. We also supported this with an online media buy targeted at reaching people who were considering a non-Windows laptop (a Mac). We linked from those banner ads to a dedicated Microsoft web site designed to configure a new PC and direct to online resellers, closing the loop to purchase. The level of spending and effort was as massive as the upside.

I could defend the advertising but at this point I am not sure it is worth the words. Besides, Apple responded to the ad with a brutal reiteration of viruses and crashes in PCs and that lots of bad choice is really no choice at all. It is rare to see two large companies go head-to-head in advertising and you can see how Microsoft took the high road relative to Apple, deliberately so. The ads worked for Apple, but almost imperceptibly so in the broader market. Apple gained about one point of market share, which represented over 35% growth year over year for each of the two years of the campaign—that is huge. The PC market continued to grow, though at just over 10%. Still that was enough of a gain to ameliorate the share gains from Apple, which were mostly limited to the US and western Europe.

As much as the blowback from this campaign hurt, we were at least hitting a nerve with Apple fans and getting closer to a message that resonated with the PC industry: compatibility, choice, and value.

For our ad agency, essence of the PC versus Mac debate boiled down not to specs and prices but to a difference in the perceived customers. The Mac customers (also the agency itself) seemed to be cut from one mold of young, hip, artistic whereas the PC was literally everyone else. It seemed weird to us, and our advertising agency, that Windows computers were not given credit for the wide array of people and uses they supported, if even stereotypically. We were proud of all the ways PCs were used.

To demonstrate this pride, Bill Veghte (BillV) the senior vice president of Windows marketing (also reporting to Kevin Johnson) led the creation of a new “I’m a PC” campaign that started in the fall of 2008 and ran through the launch of Windows 7. Rather than run from the Apple’s “I’m a Mac” we embraced it. The main spot featured fast cuts of people from all walks of life, including members of the Microsoft community as well as some pretty famous people, talking about their work, creations, and what they do with PCs. The ads featured a Microsoft employee, Sean Siler a networking specialist from Microsoft Federal, who looked unsurprisingly like the stereotype PC users portrayed by Apple. These ads were us.

The advertising world viewed success through the creative lens so dominated by Apple. The ads were well-received and for the first time we landed spots (costing hundreds of millions of dollars) that we could both be proud while emphasizing our strengths.

The memorable legacy of the campaign would be the brightly colored “I’m a PC” stickers that nearly everyone at the company dutifully attached to their laptops. Meeting rooms filled with open laptops of all brands, colors, sizes all displayed the sticker. We made sure all of our demo machines featured the stickers as well. In the summer 2009 global sales meeting just before Windows 7 would launch, BillV led the sales force in a passionate rally around “I’m a PC” and the field loved it. He was in his element, and they were pumped. The Windows 7 focused versions of this campaign featured individuals talking about their work saying “I’m a PC and Windows 7 was my idea” building on the theme of how Windows 7 better addressed customer needs (more on that in the next chapter.)

By the summer of 2009, the back and forth with Apple seemed to run its course as we were close to the launch of Windows 7 (more on that in the next chapter.) The New York Times ran a 3000-word, front of the Sunday business section story titled “Hey, , PC, Who Taught You to Fight Back?” covering what was portrayed as an “ad war, one destined to go down in history with the cola wars of the 1980s and ’90s and the Hertz-Avis feud of the 1960s.” There was even a chart detailing the escalating advertising spend of the two companies. The story even noted that the ads caught the attention of Apple who pulled their ads from the market only to return with new “Get a Mac” ads criticizing Microsoft’s ads. In the world of advertising, that counts as a huge victory. On the store shelves, the campaign finally seemed to at least slow the share loss to Apple worldwide and definitely pushed it back in the US.

Nothing hit home more a few years later than the photo of the White House situation room in May 2011 during the raid on Osama Bin Laden. That photo was captioned by the internet to illustrate the point of just who is a Mac and who is a PC. The meme featured some barefooted hipsters in a coffee shop captioned “I’m a Mac” and then the situation room featured secured PCs captioned “I’m a PC” with the heading “Any Questions?” We loved it. That seriousness was what we were all about.

Of course, the real battle with Apple was now about software. Windows 7 needed to execute. We needed to build out our services offerings for mail, calendar, storage, and more where Apple was still flailing even more than we were.

While I was entirely focused on Windows 7 and moving forward, the ghosts of Vista and Longhorn would appear. Promises were made that ultimately could not be kept and we had to work through those.

On to 091. Cleaning Up Longhorn and Vista

Postscript. The “Get a Mac” ad that hit me the hardest for non-product reasons was the “Yoga” spot, which was funny to me because when I moved to Windows in March 2006 I switched to practicing yoga after a decade of Pilates. In the spot, PC guy switches from yoga to Pilates.

The word ecosystem is often used when describing Windows and the universe of companies that come together to deliver Windows PCs and software. Providing a platform is a much trickier business than most might believe. Bringing together a large number of partners, along with their competitors, who might share one large goal but differ significantly in the tactics to use to achieve it is fraught with conflict. The Windows ecosystem had been dealt a series of painful blows over the years resulting in a loss of trust and collective capability. Where partnerships were required, the ecosystem had become a collection of…adversaries…or direct competitors…or conflicting distribution channels.

Back to 088. Planning the Most Important Windows Ever

In the summer of 2007 six-months after Windows Vista availability as we rolled out the Windows 7 product vision to the entire team, the press coverage for Vista began to get brutal. I say the coverage, but this is really about the customer reaction to the product and the press simply reflected that.

Then the OEMs, large public companies with shareholders and quarterly earnings, started to do something almost unimaginable. They began to speak out about the problems with Vista. In a widely covered interview in the Financial Times discussing quarterly results, Acer president Gianfranco Lanci lashed out at Vista, saying the “whole industry is disappointed with Windows Vista" and stated that Vista had stability problems and he doubted that Microsoft would remedy the issues within the next six months. He went on to suggest that customers really wanted Windows XP knowing that in just a few months XP would be discontinued. Much of what he said in public, the OEMs had been telling us in private.

I had been in my role for more than a year and still did not have much to say about what was coming next. How could I? We just didn’t know and all my experience with customers told me that claiming I didn’t know would not be acceptable or even credible. Still, pressure was mounting to show progress.

The Windows (or PC) ecosystem is made up Intel, PC makers (the OEMs), and creators hardware components and peripherals known as Independent Hardware Vendors (IHVs). OEMs accounted for the vast majority of Microsoft’s extremely lucrative Windows business. IHVs were the key ingredients the OEMs counted on for innovation. Intel, provider of CPUs and an increasing portion of the main componentry, was the most central in the hardware ecosystem as half of the legendary Wintel partnership.

Suffice it to say ecosystem was in an unhappy and untrusting state after years of product delays along with a series of feature, product, and pricing miscues. The delays had been extremely painful to OEMs and Intel, who counted on a new release of Windows to show off new PCs and drive growth in PC sales. IHVs had critical work to do enabling new PCs. They had to build software drivers that enabled new hardware that was compatible with the new features of Windows (such as 64-bit Windows or new security features). They also faced the increasing complexity of maintaining drivers for old versions of Windows as the time between releases increased and customers demanded new hardware support on both old and new platforms. The rise of Linux was spreading the Windows ecosystem further as demand for Linux support increased. Fractures were everywhere.

Intel contributed an increasingly larger portion of the PC, much as Microsoft continued to add features to Windows. With Centrino® for example, Intel added WiFi support directly to the components they provided to PC makers. This greatly expanded and standardized the use of WiFi in laptops. Intel was in the process of broadening their support for graphics as well, continuing to improve the integrated graphics chips they provided to PC makers (this was a particularly sore spot with Vista.) Intel was able to better control pricing of their components, encourage specific PC designs, and shift PC makers to various CPU choices using a combination of pricing actions and co-marketing arrangements. Originally these “Intel Inside” advertising efforts were a huge part of how PC makers selected and marketed different models and lines of computers and was enormously profitable for Intel.

Microsoft’s relationship with Intel had not been particularly happy, going way back to the 1990s when Intel began to embrace Java and other cross-platform technologies. Recently, however, the rise of Linux was viewed by Intel as a large opportunity, while Microsoft perceived it as a competitive threat. What Microsoft used to perceive as a moat, device driver support for Windows, was rapidly fading due to active efforts by Intel to support Linux to the same degree. The specter of desktop Linux seemed to be held back by just a few device drivers should Intel support them, or so we worried.

There was also a complex relationship between enterprise customers and Microsoft when it came to Windows. From a product and feature perspective, Windows was making increasing bets on the kind of features businesses cared about, such as endpoint control, reliability, and management. Microsoft did not always want to give away those features for free to retail customers where they might not apply. The fact that these features existed caused OEMs to consider ways to add them to the base Windows they sold, feeling that the base Windows was under-powered.  In other words, features Microsoft added to premium editions of Windows simply served as starting points for features OEMs might look to provide with their own software on top of the basic editions of Windows, increasing OEM margin.

The response to the increasing gap between consumers and enterprise was another reason for OEMs to embrace, or at least appear to embrace Linux. At the very least, OEMs began to ponder the idea of selling PCs with free Linux and letting customers pick and choose an operating system on their own as a backdoor way to avoid the Windows license for every single PC. Microsoft did not want OEMs selling PCs without Windows when Windows was destined to be on the PC anyway, as that would only encourage piracy. This “Linux threat” was not as empty as the state of technology would have indicated as OEMs were actively starting to offer Linux on the desktop, especially if they were offering it on Server already. Some markets, such as China, which already had enormously high piracy pursued this path aggressively.

From the least expensive PCs for the budget conscious to the fanciest PCs for gamers, the Windows product and business depended on these partners, and vice versa. Any business book would tell you just how big a deal the Windows ecosystem was, as would anyone who followed the antitrust actions against Microsoft.

We needed to reboot the relationship with and across the Ecosystem. Doing so would be an important part of the planning process and run in parallel with planning the Windows 7 product.

The perspectives, insights, and data from hardware and OEM partners were only part of the input to the planning process. Another part was the usage data from tens of millions of Windows users. What features, peripherals, and third-party programs were used, how often, and by which types of customers. Vista had done excellent work to incorporate the performance and reliability measures of the system, especially for glitches like crashes and hangs, but usage data was inconsistent across the system. As we would discover, this data was not readily available or reliably collected across the whole product. We knew we would need as much as we could for Windows 7 and certainly down the road, so we began in earnest to implement more telemetry across the product during the planning for Windows 7. This data would form a foundation for many discussions with OEMs.

The feverish pace and tons of work over the six months that followed the re-org tackled an expansive set of potential areas and distilled them down to a product plan, the Windows 7 Vision. That six months would bump up against not one but two OEM selling seasons during which the OEMs would not get the news about “fixing Vista” they were hoping for. The planning memo came out in December 2006 even before Windows Vista availability. That timing, however, would be too late to impact the February selling season. The July 2007 Vision was too late to become requirements for PCs for back to school in August or September of that year. Even though PCs would not ship with Windows 7 for quite some time, every selling season we missed would make it frustratingly difficult for those PCs to be upgraded to Windows 7. This was a problem for every part of the ecosystem including Microsoft.

The relationships were difficult, but more importantly the quality of work across the ecosystem was in decline. Communication was adversarial at best.

Mike Angiulo (MikeAng) joined from Office and began an incredible effort at rebuilding the relationships with OEMs. Mike was not only a stellar technologist, but a strategic relationship manager, having grown up as a salesman within his future family’s business. He was also a trained mechanical engineer who rebuilt and raced cars, a natural-born poker champion, and an IR-pilot who built his own plane.

He recruited Roanne Sones (RSones) to lead the rehabilitation of the relationship with OEM customers. She was a college hire from Waterloo’s prestigious systems engineering program who had joined Office five years earlier. Having worked on projects from creating the Office layperson’s specification, to synthesizing customer needs by segment, to analyzing usage data across the product, Roanne brought a breadth of tools and techniques from Office to the OEM problem space. Also joining the team was Bernardo Caldas (BCaldas) who would bring deep insights combining usage data, financial modeling, and business model thinking to the team.

Roanne quickly learned that a big part of the challenge would be the varying planning horizons the OEMs required. “Required” because they told us that they needed “final Windows 7 plans” in short order if they were to make the deadlines for a selling season. Whether they needed the information or not, the reality was they were so used to not getting what they wanted they simply made any request urgent and expansive.

Each OEM was slightly different in how it approached the relationship, but all shared two key attributes. First, they viewed Windows as an adversary. Second, they did not take anything we told them to be the ground truth. They were constantly working the Microsoft organization and their connections, which were deep, across the separately organized OEM sales team, support organizations, and more, to triangulate anything we said to arrive at their own version of truth or reality. They also had no problems escalating to the head of global sales or to SteveB directly, several of whom had known Steve for decades.

After a decade of missed milestones, dropped features, antitrust concerns, and contentious business relationships, the connection between Microsoft and OEMs was painfully dysfunctional. Considering Windows accounted for so much of Microsoft’s profit, this was a disaster of a situation. It had been going on so long that most inside Microsoft seemed to shrug it off as just a part of the business or “OEMs have always been like this.” It was no surprise to me that the relationships devolved.

We found little to love in most new PCs while at the same time Microsoft was rooted in a long history of believing, as BillG would say though this is misinterpreted I think, that “ten years out, in terms of actual hardware costs you can almost think of hardware as being free.” He meant that to imply that relative to advancing software capabilities, the hardware resources required would not be a key factor in innovation. I’m not sure OEMs heard it that way.

What was really going on other than Microsoft’s lack of reliability as a partner, not to dismiss that perfectly legitimate fact? It goes back to the history of PC manufacturing and its evolution to the current situation. When Dell and then Compaq first manufactured PCs, they were rooted in engineering and design of PCs, and each built out manufacturing and distribution channels—PCs made in the US (Texas) and shipped around the world.

As the industry matured, more and more manufacturing moved to plants in Taiwan and China. Traditionally, components such as hard drives, accessory boards, and motherboards were shipped to the United States from locations around Asia for final assembly, including the addition of the Intel CPU manufactured in the US. Eventually, as more and more were made in Asia, it became increasingly efficient to aggregate components there for assembly as a complete PC, which could then be shipped around the world. This transition is one Tim Cook, now the CEO of Apple, famously took Apple through even though Steve Jobs resisted it.

Over time, these assembly companies aimed to deliver even more value and a greater share of the PC experience, as they described. They even began to create speculative PCs and sell them to the OEMs, such as Dell and HP for incorporation into their product lines after a bit of customization such as component choice and industrial design. The preference for laptops over desktops made it even more critical to engineer a complete package, which these new original design manufacturer partners became experts at doing. As the name implied, an ODM would both design and manufacture PCs (and many other silicon-based electronics). The ODMs developed such complete operations that some even created consumer-facing brands to sell PCs as a first party, in search of margins and revenue.

In a sense, the headquarters of an OEM was the business operation and the ODM the product and manufacturing arm, managed on metrics of cost, time to delivery, and quality. In this view, Windows itself became just another part of the supply chain, albeit the second most expensive part, usually far behind Intel. That’s why PCs tended to converge on similar designs. Some argued that the ODM process drove much of that with a small set of vendors looking to keep costs low and sourcing from a small set of suppliers to meet similar needs from US sales and marketing arms. Even though there were a dozen global PC makers, the increasing level of componentization and the ODM model caused a convergence, first with desktops and now we were seeing the same happen with laptops.

Effectively, ODMs were driving a level of commoditization. On the one hand, this was great for better device driver support and a more consistent Windows experience, as investments the ecosystem made were leveraged across independent PC makers. On the other hand, this led to margin compression for PC makers which put even more pressure on ODMs and Microsoft. Further, given all PC makers faced similar constraints, PCs tended to converge to an average product, rather than an innovative one. There were a few outliers such as Sony who continued to drive design wins, but with ever-decreasing volume (Sony sold off their PC business in 2014.)

Roanne and Bernardo were treating the ODMs with the same level of attention as OEMs, something that had not been done before. The PC business was extremely healthy in terms of unit volumes, but the OEMs were all struggling to maintain profit margins and were looking to ODMs for leverage. There was a great deal of envy of Apple and its sleek new MacBook laptops made from machined aluminum, but, more importantly, the margins Apple earned from those PCs were impressive. The OEMs were pressuring the ODMs to deliver the same build quality with room for ample margins and a lower price than Apple, which was believed to be charging premium prices at much lower volume. In manufacturing, volume is everything so it is reasonable to assume that much higher volume could make lower prices possible, but only if the volume was for a small number of different models which the OEMs were not committed to. The ODMs thought this was impossible and continued to push their ability to deliver higher-margin and higher-priced premium laptops.

Early in my time at Windows, I went to Asia to visit with some of the ODMs to see firsthand their perspective on the PC and the relationships across the ecosystem. Visiting with the ODMs brought these tension front and center and proved informative.

The ODMs that served multiple OEMs were quite stringent about secrecy and leaks across their own companies. Each OEM had distinct and secured facilities, and the ODM management structure was such that information was not shared across facilities. Visiting a single ODM meant seeing buildings for any one of the major global manufacturers all identical on the outside, but each entrance was guarded as though the building was owned and operated by the specific OEM. Access was closely guarded and employees of the ODM never crossed into different facilities. I recall once having an Apple building pointed to in a manner that reminded me of driving by a building on the Washington, DC Beltway when everyone knows it is a spy building, but just remains quiet and doesn’t say a word. An ODM even acknowledging they served Apple would jeopardize their business even though it was an open secret.

The ODMs themselves were struggling with margins, even though they benefitted from a highly favorable labor cost structure in Asia. Several were responsible for manufacturing Apple devices, and while they would certainly never, ever divulge any details about that process, we knew that much of the math they would show us, bleak as it was, was informed by what they were doing for Apple and other OEMs.

One of the larger ODMs that I also understood made Macintosh laptops—and was run by a founder and CEO who had grown the company from the 1980s—proved to be an adventure to visit.

I arrived for my tour and put on a bunny suit and booties, deposited any electronics and possessions into a safe, and entered through a metal detector. There were cameras everywhere. There were acres of stations on the floor of a massive assembly line, each one responsible for a step in the manufacturing process. Pallets of hard drives, motherboards, screens, and cases arrived in one end, and progressed through the enormous assembly line stopping at each station. One added the hard drive, while one was attached the screen. Another verified that everything powered up. The final assembly step was where they attached the Genuine Windows hologram that proved that the Windows software was not pirated and was purchased legally. The ODMs always made a point of showing me that step knowing their role in anti-piracy was something we were always on the lookout for. Then the machines were powered up and burned in for a few hours to make sure everything worked.

After seeing the line, we ventured to the top-floor of the building to the CEO’s private office, which was the entire floor. On this floor was a beautiful private art collection of ancient Chinese calligraphy and watercolors. After a ritual of tea and tour of the gallery, the discussions of business began.

Instead of hearing about all the requirements from Windows, the CEO raised many issues about our mutual customers. We discussed the constant squeeze for margin, the pressure to compete with Apple without paying Apple prices, and what I found most interesting: the desire for flexibility, which precluded everything else. The OEMs, it turned out, were born out of an era during which desktop PCs were made from a number of key peripherals, such as a hard drive, graphics card, memory, and other input/output cards. Each of these could be chosen and configured at time of purchase. This allowed for two crucial elements of the business. First, the customer had a build-to-order mindset, which was appealing and a huge part of the success of Dell. Second, the OEM could bid commodity suppliers of these components against each other and routinely swap out cheaper parts while maintaining the price for customers. This just-in-time manufacturing and flexible supply chain were all the rage in business schools.

The problem was that this method did not really work for laptops and especially did not work for competing with Apple. Apple designed every aspect of a laptop and chose all the components and points of consumer choice up front. This gave Apple laptops the huge advantage of being smaller and lighter while also not having to account for a variety of components placing different requirements on software, cooling, or battery life. This integrated engineering was almost the exact opposite of how the Windows PC makers were designing laptops.

During one visit in 2008, after the MacBook Air had recently been released, it was all the ODMs could talk about. The only PCs that came close were made in Japan for the Japan market or achieved little critical mass in the US except among tech elites, such as the Sony VAIO PCG-505 or the Fujitsu LifeBook that I used. The Air’s relatively low(-ish) price point would eventually lead to an Intel marketing initiative called Ultrabook™ but as future sections will describe, it would be years before the PC ecosystem could respond to the Air.

From an ODM perspective, the requirements for the supply chain were driven by non-engineers or marketing from the OEMs back at HQ and seemed disconnected from the realities of manufacturing. They felt they had the capability to build much sleeker PCs than they were being asked. Always implied but never stated was the fact that some of them built devices for Apple.

Meeting after meeting, I heard stories of ODMs who knew how to build leading and competitive laptops but the US OEMs, even when shown production-ready prototypes, would not add them to their product lines. They wanted cheaper and more flexible. Or at least that was the frustration the ODMs expressed.

From a software perspective, I began to understand why PC laptops were like they were. For example, they were relatively larger than Apple laptops to enable component swapping as though they were desktops. Nearly every review of a Windows laptop bemoaned the quality of the trackpads—both the hardware and software—and here again the lack of focus on end-to-end, including a lack of unified software support from Windows and a requirement for multi-vendor support, made delivering a great customer experience nearly impossible. It was also the case for cellular modems, integrated cameras, Bluetooth, and more.

The desire for lower costs would preclude advanced engineering and innovation in cooling. This led to most Windows laptops to have relatively generic fans and overly generous case dimensions to guarantee airflow and cooling for a flexibility in componentry. The plastic cases filled with holes and grills were just the downstream effect of these upstream choices. So was the fan noise and hot wind blowing out the side of a Windows laptop.

Review after review said Windows laptops didn’t compare to the leading laptops from Apple, and yet I could see the potential to build them if only one of the OEMs would buy them. They simply didn’t see the business case. Their view was that the PC was an extremely price-sensitive market, and their margins were razor thin. They were right. Still, this did not satisfactorily explain Apple nor the inability to at least offer a well-made and competitive Windows PC. Though simply offering it would prove to be futile because of the price and limited distribution such a low-volume PC would necessarily command. We were caught in a bad feedback loop.

A larger initiative Roanne and team would take on was the infamous “crapware” issue, the phrase coined by Walt Mossberg years earlier. Tech enthusiasts and also reviewers tend to view crapware through that namesake lens as software that just makes the PC worse. OEMs had a decidedly different view and to be honest one that as I learned about it, I worked hard to be more sympathetic to. To the OEMs, additional software was a means of differentiation and a way to make their own hardware shine. We tended to think of crapware as trial versions of random programs or antivirus software, but to the OEMs this was a carefully curated set of products they devoted enormous resources to offering. While some were trials and services designed to have revenue upside, others were developed in-house and were there because of unique hardware needs. The grandest example came with Lenovo ThinkPads called ThinkVantage Technologies or TVT. Under this umbrella the full enterprise management and control of the PC hardware was enabled by Lenovo. While I might have an opinion on quality or utility, there was no doubt they were putting a good deal of effort into this work and most of the features were not part of Windows.

Previously I described the OEM relationship as adversarial. That might have been an understatement. The tension with OEMs was rooted in a desire to customize Windows so that it was unique for each OEM or each product line from an OEM. Microsoft’s view was these customizations usually involved “crapware” and that Windows needed to remain consistent for every user regardless of what kind of PC it ran on. It is easy to see this is unsolvable when framed this way. It was amazing considering how completely and utterly dependent Microsoft was on OEMs and OEMs were on Microsoft. This is a case where new people with a new set of eyes had a huge opportunity to reset the relationship.

What I just described was a few months of my own journey to understanding why PCs were like they were, and now I felt I understood. Because I was new, and we had a new team led by Mike, we were optimistic that we could improve the situation. There was no reason to doubt that we could. We believed we understood the issues, levers, and players. It seemed entirely doable. We just had to build trust.

The primary interaction with OEMs were “asks” followed by “request denied” which then led to a series of escalations and some compromise that made neither happy. This would be repeated dozens of times for each OEM for many of the same issues and some specific to an OEM. As with any dynamic where requests are denied, the result was an ever-increasing number of asks and within those an over-ask in the hopes of reaching some midpoint. If an OEM wanted to add four items to the Start Menu, then the ask might be to “customize every entry on the Start Menu” and a reply might come back as “none” or “no time to implement that” and then eventually some compromise. It was painful and non-productive.

There are two schools of thought on these issues. One is that it is obvious that Windows is a product sold by Microsoft and the OEMs should just pass it along as Microsoft intended it to be—relegating the OEM to a wholesale distributor. In fact, the contract to buy Windows from Microsoft specifically states that the product is sold a certain way that should remain. Given the investment OEMs made in building a PC, they did not see the situation that way at all.

The other is that it is equally obvious that the OEMs are paying Microsoft a huge amount of money and they own the customer relationship, including support, so they should be able to modify the product on behalf of their end-user customers. As it would turn out, the first view was on pretty firm ground, at least prior to the 1990s antitrust case. After settling that case, the conclusion was that the right to modify the product as an end-user would pass through to OEMs and Microsoft had limits in what it could require. (If people reading this are thinking about how Android works with phone makers today, you have stumbled upon the exact same issue.)

Perhaps using the word adversary as I have previously used was too blunt. In fact, the relationships were often far more complex and nuanced, fraught with combinations of aligned and mis-aligned incentives. It was entirely the case that the OEMs were our customers, but that was confusing relative to end-users who were certain they were buying a Microsoft product while also a PC maker’s product, and often the Microsoft brand was paramount in the eyes of consumers. The OEMs were also Microsoft partners in product development—we spent enormous sums of money, time, and resources to co-develop technologies and the whole product—yet this partnership felt somewhat one-way to both sides. OEMs were often viewed as competitors as they ventured into Linux desktops and servers, while at the same time they viewed Microsoft as offering one of several choices they had for operating systems. We certainly viewed OEMs as the source our shortcomings relative to Apple hardware, yet the OEMs viewed us as not delivering on software to compete with Apple. Even as distribution partners, depending on who was asked, the OEMs were distributors of Windows or Windows was a distribution tool for the PC itself.

These dysfunctions or as most schooled in how the technology stack evolved referred to them as “natural tensions” had been there for years. There’s little doubt that the antitrust settlement essentially formalized or even froze the relationship, making progress on any part a challenge. There was no doubt a looming threat of further scrutiny as the ongoing settlement-mandated oversight body remained. I met regularly with the “Technical Committee” and heard immediately of anything that might be concerning. Every single issue was resolved, and frankly most trivially so, but the path to escalate was always there.

At the conclusion of the antitrust case, the Final Judgement or Consent Decree (CD) formalized a number of aspects of the relationship, some surprisingly made it more difficult to produce good computers and others simply reduced the flexibility the collective ecosystem had to introduce more competitive or profitable products. While the CD was generally believed to focus on the distribution of web browsers and Java (or in other markets, media players and messaging applications) it also dictated many of the terms of the business licensing relationship. Many of these related to the terms and conditions of how Windows could be configured by OEMs, essentially extending the OEM rights beyond simply installing competitive browsers to just about any software deemed “middleware” as Java was viewed.

In terms of bringing Windows PCs to market, the CD had three main sections:

* Non-retaliation. The first element was that Microsoft could not retaliate against OEMs for shipping software (or middleware) that competes with Microsoft, including shipping computers running competitive operating systems. This codified the right of OEMs to ship Linux and even dual-boot with Windows for example. My how the world has changed, now that is a feature from Microsoft!

* Uniform license terms. Basically, this term meant all OEMs were to be offered the same license and the same terms. Historically, as most all businesses see with high-volume customers, there were all sorts of discounts and marketing programs that encouraged certain behaviors or discouraged others. Now these offers had to be the same for all OEMs (for the top 10 there could be one set and then another for everyone else). In many ways, the largest OEMs got what they wanted but not since this put the best customer on the same playing field as the tenth best. This did not preclude the ongoing Windows Logo program described below.

* OEM rights. The CD specifically permitted a series of actions the OEMs could take with regard to Windows including “Installing, and displaying icons, shortcuts, or menu entries for, any Non-Microsoft Middleware or any product or service” and “Launching automatically, at the conclusion of the initial boot sequence or subsequent boot sequences, or upon connections to or disconnections from the Internet, any Non-Microsoft Middleware.” These terms, and others, got to the heart of many of the tensions with OEMs over “crapware” or software that many consumers, especially techies, complained about. Now, however, it was a right OEMs had and Microsoft could do little to enforce that.

There were many other terms of course. Since we were “stuck” with each other, with Windows 7 we tried a nearly complete reset of the OEM relationship.

The bulk of this work was captured in the Windows logo program—these were the instructions from Microsoft for how OEMs installed and configured Windows during manufacturing described in the OEM Preinstallation Kit (OPK) authored by Microsoft with ample compliance scrutiny. Given the above, one could imagine that most anything was permitted. However, Microsoft retained the rights to implement a discount program for strictly adhering to a set of constraints to earn the “Designed for” logo. Sometimes these were discounts and other times marketing dollars for demand generation, though these are equivalent and interchangeable pricing actions by and large.

We viewed these constraints as setting up a PC to be better for consumers. OEMs might agree, but they also saw them as hoops to jump through in order to get the discount, which their margins essentially required. These logo requirements ran the gamut from basics like signing device drivers and distributing available service packs and patches to how much to configure the Start Menu. None of them ever violated the CD as per ongoing oversight. It was these aspects of Vista that were particularly adversarial.

We revisited all the terms and conditions in the OEM license (and logo) and worked to make the entire approach more civil. We wanted OEMs to have more points of customization while also building the product to more robustly handle those customizations—we aimed to reduce the surface area where OEMs could fracture the Windows experience. We also would spend a lot of energy making the case for why not changing things would be a good idea and in favor of lower support costs or more satisfied customers. A key change we made from the previous structure was to have the same team responsible for taking feedback and producing the logo requirements. This eliminated the organizational seam as well as a place for OEMs to see potential conflicts across Microsoft, and exploit those.

As an example, early in the process of building Windows 7 Roanne and team would present to the OEMs examples of where they were given rights (and technical capabilities) to customize the out of box experience (OOBE) when customers first experienced a new PC. In one iteration we showed a color-coded screens where the OEM customizable region was clearly marked indicating just how much of Windows was open to OEM customization. This type of effort was a huge hit.

The process of collaborating with the OEMs was modeled after our very early Office Advisory Council (OAC) that was run out of the same product planning group where MikeAng and Roanne were previously. Instead of just endless slide decks that spoke at the OEMs, we engaged in a participatory design process with the OEMs, a planning process. We listened instead of talked. We gathered feedback. Then we answered their specific questions.

We began the process of working with the OEMs just as we completed the Vision for Windows 7. We did that because by then we had a real grasp of what we would deliver and when, and at least what we said was rooted in a full execution plan. This was decidedly different than past engagements where the meetings with OEMs reflected the historic Windows development process, which meant that much of what was said at any given time could change in both features and timing. For the OEMs with very tight manufacturing schedules and thin margins, information that was so unreliable was extremely costly to them. At every interaction they had to take the information and decide to act on it, allocate resources, prioritize a project, and more, taking on the risk that the effort would be wasted. Or they could choose to delay acting on some information, only to find out it was critical to start work to provide feedback that might be significant. It was a mess.

What Microsoft had not really internalized was just how much churn and the level of real dollars it cost the OEMs with this traditional interaction. In fact, most involved on the Microsoft side felt, as I would learn, quite good about the openness and information being shared. I learned this both from the OEM sales team and directly from the CEOs of OEMs who were starting to get rather uncomfortable with the lack of information. They began to get nervous over my lack of communication (literally me and not the OEM team) as I had not provided details of the next release even after being on the job for months. I just didn’t know the answers yet. Our desire to be calm and rational created a gap in communication that worried people. It was not normal. We had not set expectations and even if we had it wasn’t clear they would have believed us.

MikeAng characterized the old interaction as “telling the OEMs what we were thinking” when we needed to be “telling OEMs what we were doing.” By characterizing what we were going to improve this way we were able to avoid massive amounts of wasted effort and negative feelings. We also believed we would reduce the number of budget-like games when it came to requests. No matter how much Microsoft might caveat a presentation as “early thoughts” or “brainstorming,” customers looking to make their own plans under a deadline will hear thoughts as varying degrees of plans. Only later when those plans fail to materialize does the gap between expectations and reality widen—the true origin of dissatisfaction. At that point the ability to remind a customer of whatever disclaimer was used is of little value. The customer was disappointed. This cycle repeated multiple times over the 5-year Vista product cycle, and many before that over the years.

With the Windows 7 vision in place, we began a series of OEM forums and meeting at least every month with each OEM. Each forum (an in-person workshop style meeting) would focus on different parts of the product vision or details about bringing Windows 7 to market. Roanne and team dutifully documented the feedback and interactions. We actively solicited feedback on priorities and reactions to the product overall. Then we summarized that work and sent out summary of engagement memos to the OEMs. In effect, the relationship was far more systematic, and the information provided was far more actionable. From the very start we communicated a ship date for the product and milestones, and a great deal of information about the development process. We reinforced our attention to the schedule with updates and information along the journey.

The entire process was run in parallel for the key hardware makers: storage, display, networking, and so on. We also repeated it for the ODMs. The team did an amazing job in a very short time, for the first time.

Over the coming months and really years, the reestablishing of trust and the effort to become a much more reliable, predictable, and trustworthy partner would in many ways not only change this dynamic and experience for OEM customers, but significantly improve the outcome for PC buyers. At the same time, OEMs were able to see improvements in satisfaction and potential avenues to improve the business. The PC would see many major architectural changes over the course of building Windows 7—the introduction of ink and touch panels, broad use of security chips and fingerprint login, addition of sensors, expansion of Bluetooth, transition to HDMI and multiple monitors, high-resolution panel displays, ever-increasing use of solid-state disks, and the transition to 64-bits. The Ecosystem team would be the conduit and moderating force between OEMs, their engineering teams, the engineering teams on Windows, and even Microsoft’s own OEM sales and support team.

The Windows business faced a lack of trust from every business partner. The Windows team needed to move from chaotic process that promised too much and delivered inconsistently and late. Instead, we aspired to make bold but reliable promises—my guiding principle, the mantra of promise and deliver. While we talked big, the ball was in our court. We put in place a smoother and more productive engagement with OEMs. Throughout the course of developing Windows 7 and beyond, we consistently measured the success of the engagement with qualitative and quantitative surveys. Through that we could track the ongoing improvement in the relationships.

Promise and deliver.

Just as we worked to gain renewed focus with OEMs, Apple chose to declare war with Microsoft, and the PC, with clever and painfully true primetime television commercials. While the commercials began before Vista, the release and subsequent reception of Vista were exactly the material the writers needed for the campaign to take off.

On to 090. I’m A Mac

This section was the most difficult to write. At least people look back favorably on Clippy. The Windows 8 Start screen lacks any kitsch or sentimental value. It was the wrong design for the product at the wrong time and ultimately my responsibility. This is not the story of the design. There are better people to write about the specifics. This is not a story of ignoring feedback or failing to heed the market, but a story of just what happens when you’re out of degrees of freedom. This is the story of the constraints and the rationale for how we managed a situation that we saw as a quagmire. The good thing about the Start screen was everyone had an opinion. The bad thing was most of those opinions were not favorable.

Subscribers, only two more scheduled posts remaining.

One of the main challenges in leading a big team is that nothing ever seems to finish—there’s always more to building a team. Even at milestones, one looks ahead and sees more work to do. In the first few months I had been working on Windows so far, we re-organized the team in a huge way and shipped Windows Vista, only to then have to figure out how to plan a product release with this entirely new organization, while building an improved engineering culture. The planning work began in earnest in December 2006 and concluded July 2007. This is the story of those months and what it was like and what management tools we used to develop a product plan for what would become Windows 7.

Back to 087. Reorg! Why Are We Together, Exactly?

SteveB loved to talk about his discussions with engineers as he tried to better understand the company’s execution and culture challenges. He would say “I talked to this engineer on the team, and they told me ‘Look, everything is completely screwed up and everybody telling you how to fix it is wrong.’” Steve would continue to listen to a litany of problems and why everyone was being “dumb” wondering what he could possibly do. Then the engineer would look up and say to Steve, “But I [emphasis on “I”] know exactly what to do and how to fix it.”

My problem was I was also that engineer. I saw the problems and “knew” what to do. Except it was my job and I had to lead the team to fix the problems.

Fortunately, early on there was a set of like-minded engineers who were willing to sign up and take on the challenge of building a culture and now a plan for what comes next. From the very start it was not just me driving the cultural changes, but the set of leaders put in place from our big re-org.

Change across thousands of people, each of whom knows exactly what should be changed, is not a one-time event. Change takes repetition. It takes calendar time. It takes making some mistakes and using those as learning or teaching moments. While everyone was anxious for change, thousands of engineers must be given time to think and reach the point—on their own—of agreeing to a certain kind of change.

Every step over the next few months, from the time of putting an organization in place to starting the real building of products, we (the leaders) would be confronted with two realities. First, we had to remind everyone on the team consistently and repeatedly of the process we were using and how we aimed to work together. Every. Single. Communication. At times it felt like we were reading the inside of the box of a board game at every meeting. Second, every time we made a mistake and didn’t ourselves follow that process, expect someone to point that out and for that to become a moment of humility.

It was a constant push-pull with so many wanting to know what we were telling people to build while we were busy pushing back and saying how we needed them to figure that out. At the same time what we wanted to do would look radically different from the past. It wasn’t a top-down plan. It wasn’t a disconnected set of innovations. It was not about consensus of design as in design-by-committee, but a coherence of a plan. The investments (as we would say) were going to fit together into a holistic product plan across our new organization: WEX, LEX, IE, and COSD. After every step in the process, we regrouped as a leadership team and not only talked about what parts of the process we needed to improve, but we turned that into coaching and more outbound communication such as my Office Hours blog. At the same time, we were continuously adapting to what was understood, misunderstood, and especially challenged when it came to process.

An example of cultural change that was front and center was a desire to match the old Windows team in terms of scorecards or KPIs by automating or operationalizing key requirements. I would be out there talking about vision and scenarios and collaboration—abstract concepts that need to be made concrete by the team—only to find out some people were trying to make a vision scorecard or building an automated testing tool to check if scenarios were complete or tools to red/yellow/green dependencies between different teams. We’d come across this and then would need to course correct and talk about how accountability works without constant monitoring by others nor overwhelming bureaucracy.

Every email and memo, every team meeting, every 1:1 was a not just an opportunity to reinforce the new cultural norms, but a requirement for us to do so. The first and most important test was developing a product plan for the next release following Vista. For us to get to the finish line with a coherent product all at the same time and all on time we would need to get to the starting line at the same time.

First, we needed a product name. By now you know I was never a fan of codenames.

Windows had always had somewhat clever (too clever) code names with layers of meaning. As a consumer of these code names, they neither made for secrecy, as one could routinely read about the release code names in trade press, nor did they make it easy to remember what someone was talking about. “Is that in Nashville or Memphis? I can’t remember.”

Windows Vista was the sixth major release of Windows and it was version 6.0.6000 for techies. So, by fiat I christened the code name of the release Windows 7. I thought I was being the opposite of clever and we could simply move on, as we had done when we picked Office 9. Oops. Immediately I made two mistakes. First, did I reach consensus on this name? Second, did I even understand the ramifications of the name I picked unilaterally?

This sparked a debate that only geeks would participate in (at the time and once the name was made public), which was: How did we count versions of Windows? Technically, this was not the seventh major version, as some would debate. My view: Windows 1.0, Windows 2.x, Windows 3.x, Windows 95, Windows XP, and Windows Vista. But wait, there was Windows NT, and there was Windows 98, 98SE, and Millennium edition.

It turned out there were lots of ways to count and lots of ways to have more than six previous releases or fewer than six. Essentially, everyone could be right. I probably received two dozen emails with different algorithms for counting how many releases of Windows had been done, ranging from “well, it was really only four” to “at least a dozen.”

I stuck with seven.

Crisis averted by executive authority. Temporarily.

The test and engineering system team informed me that we could not possibly “bump the major version number,” as this would cause a whole slew of problems for application compatibility. It turned out many existing Windows programs were bad at checking what version of Windows was running and failed to run if the “major version” (that would be the first digit) was incremented. I knew this from Office 95 when we skipped several version numbers to align all the apps.

Marketing had input too: that we had to make it version 7.0 because if not the press would think we were doing a minor version and then enterprise customers would not see the need to upgrade. So even though the engineering system did not want the major version number changed, the marketing team did.

This whole notion of “major” versus “minor” as the press characterized releases would drive me nuts. It seemed as though a major release was one that broke a lot of stuff and finished late. A minor release was one that worked because it polished features and finished on time. My view, no surprise, would be based on resources. Did we have everyone working on the release or did we peel off a subset of people to work on something less for less time than a normal release? Windows 7 had everyone, 100 percent. And we were determined not to break things. And we were going to finish on time. It was a major release.

I had an urge to quit before we even started. If this trivial thing was going to be so consuming, imagine what the whole release was going to be like. Yikes.

Despite the uproar, we stuck with the Windows 7 code name, and the ultimate irony turned out to be that we eventually stuck with the name for the commercial product as well.

Planning moved forward, but it became clear that there was a new challenge at every step of the journey. There were two sides to every situation we faced.

Some people on the team wanted to be left alone, confident in what they would be working on and that there was nothing to be gained by delaying the start of the work. In some sense this was true because some parts of the product were known. We knew we needed to improve the engineering system, for example, and we knew we would do another turn of the crank on many areas, such as performance, device drivers, and security.

On the flipside, there were the people who wanted to be told precisely what to do, simply because they had frequently and repeatedly come up with ideas only to have the rug pulled out from under them by new strategies, scheduling, or resource constraints. Those people wanted to know what success would look like for them as individuals and on a granular level. The big picture was not their concern.

This made things tough.

It was tempting to remove constraints on the “correct” people and tell others what to do. It would feel quite good to be making progress and to be able to report work is happening, especially to the anxious executive team above me. Even identifying the right teams along these lines would fall into old behavior patterns we wanted to break, mainly, that there were always the elites in Windows who were given freedom to do what they felt was right, while other too often teams fell victim to management processes. I believed that we could do better if we followed the old Shipping Software adage and got everyone to the starting line at the same time. The goal was to get the maximum number of ideas on the table via broad participation of domain experts and create a holistic product plan from that—a Windows version of our Office approach to participatory design.

The planning memo was a tool developed in Office to begin the process of the release and to kick off a participatory design process. Over several iterations we came up with a format that provided a structure such that people could investigate what to build, without having the conclusion in advance and without necessarily having organizational ownership or structure in place. It was planning but without a pre-ordained plan arrived at by execs beforehand or retrofitted from known technology efforts already underway. It was a tool for empowering the team to ensure the best ideas came forward.

The organization needed to transform before we could transform the product and culture, but we would still need to avoid the perils of shipping a product defined by an org structure. Perhaps the biggest change we would make was the transformation of the next level of the organization away from the history of product units to a large group of feature teams of development, testing, and program management. Windows 7 (WEX, IE, and COSD) ended up being about 45 teams with about 1400 software engineers. In addition, there was a design and research team of about 100 people and about 20 product planners dedicated to Windows and reporting to JulieLar. We had a large team responsible for international versions of Windows coordinating the work with translation resources around the world.

The idea of less than 50 teams was important because each milestone would involve a meeting with teams and that needed to be manageable. I didn’t think we could scale beyond that, but frankly I thought we had more than enough by way of resources to build a great product. If we could better organize, we could simultaneously tap more creative energy from within the team while improving efficiency and causing the whole to operate smoothly and pleasantly.

In the process of organizing the team we moved several significant-sized teams to the division that makes Xbox, including the Media Center, music rights management, and the non-platform elements of gaming. Some other teams, notably what remained of Windows Presentation Foundation (Avalon) moved to join with the rest of the .NET Framework, putting an end to a cross-division skirmish. A small subset of Avalon that also moved was building a cross-platform browser-plugin that supported video playback and conferencing, codename Jolt. That plugin would eventually be renamed Silverlight and offered as a competitor to Adobe Flash while also serving as a developer platform for a new Windows Phone. The resulting Windows team became much more focused on delivering and building for Windows and these divisions were excited to have more control of key technologies that did not need to be part of the Windows platform. I was very happy to do these moves.

While some were amazed that we could create $150 billion in market capitalization with only a few thousand engineers, I still thought the team was a bit large. Office created as much with 20 to 40 percent fewer people. I wasn’t there to cut costs and never even thought about reducing headcount. Bloat, inefficiency, and lack of clarity in a product, however, come from too many people especially when poorly organized.

In the abstract, it is easy to see the attraction of small-focused teams tackling problems independent of each other versus a flexible and agile (though perhaps monolithic) group that adjusts to changing needs at scale. In practice, and especially at any scale, the small, multidisciplinary team rarely has an outsized impact in the context of a big business and always finds itself challenged to hire and grow deep engineering talent. Furthermore, when organized in such a manner the teams do not share in a larger mission and as a result the overall product loses the ability to shift resources around as needs arise. If a key feature team needs more resources, the head of engineering (AlesH or BenFa) can load balance across the whole organization without disenfranchising a multidisciplinary manager who would feel undermined by losing their resources to another manager. I was certain this would be important with Windows 7 because the teams had not previously done rigorous scheduling or hit a ship date.

This was a truism based on what Microsoft had achieved, not a theory or abstract concept, and was my rationale for why a structure of flexible feature teams wasn’t a management fad that would swing back in the other direction down the road. Windows was one product, and we would organize and operate like we were building one product.

JonDe, JulieLar, and I, with important contributions from marketing and product planning, wrote the December 2006 memo, Planning Windows 7, outlining the state of the business and putting forth product and business priorities. The planning memo puts a large bounding box around the release but is not yet the plan. It kicks off a process, inviting participation from everyone on the team. Using the familiar Harvard product development funnel, we were opening up the funnel to ideas.

Who knew that hitting Send could be so stressful? Again.

Julie and her counterpart in COSD, ChuckC, would drive the planning process and own the resulting plan, which would be a document called the Vision for Windows 7. Julie, having been part of the process in Office several times, would be the key owner. Julie also wrote an outline of the overall vision process, a primer basically, that was sent and resent many times throughout the next few months. The first challenge was that a good portion of the PM team believed the planning memo was the plan, when it was a framework to think about what the plan could be. To others, this memo and process seemed to be bureaucratic or arbitrary process getting in the way of what everyone knew we needed to do. Out of the gate the need to talk about building a coherent and cohesive plan where everyone on the team was accountable to promise and deliver was our key leadership message.

The planning memo was over 30 pages, but the first two pages were essentially instructions for how it works or “the inside of the box” as we described it—another example of the ongoing repetition of how we will work.

The planning memo is where the business enters into thinking. With most of the team and audience engineers, we would use every product start to reiterate the business fundamentals and what levers were being explored.

It is in the planning memo we talk about the kinds of challenges the financial side of the business face, as we did in Office with respect to enterprise sales. In Windows there were multiple constituencies: PC makers (OEM) representing a huge portion of Microsoft’s business concentrated in just a few customers, developers who make use of API innovations in Windows, ecosystem hardware partners who supply components to OEMs and peripherals to end-users, enterprise customers that run their business by deploying Windows desktops and laptops, and of course consumers and end-users. Also critical was the role the core Windows operating system played for Windows Server. Nearly every aspect of Windows impacts two or more of these directly and generally speaking it was not the type of challenge that had been pushed down to teams the way we were working to do.

The first section of the memo focused on the need of Windows to bring energy and health to the PC business, especially by finding scenarios where home users would have more than one PC and where business users would see value in more feature-rich editions of Windows. Unlike the Office business, the Windows business was much more sensitive to the sales of new PCs rather than the core value proposition to enterprises.

It is worth keeping in mind that “renewed growth” and “health” were somewhat counterintuitive to any business metrics readily visible to the team—Microsoft’s history of paranoia was definitely present in our planning, and that was a good thing. There were no material signs that the PC expansion was slowing. We still had not seen the giant leap Apple would make in “personal computing” with the iPhone that was announced in January 2007. In the coming months (exactly 3 months) Steve Jobs would announce that there would be an SDK to build apps for the iPhone and iPod. Phones were getting smarter, but people were decidedly still reliant on PCs for the internet.

About three-quarters of Windows revenue came from sales directly to PC makers. While we talked about one billion Windows users, they were only our customers in an indirect way. People bought PCs and those PCs came with Windows, which was purchased by the OEMs. Even if a person had a problem with Windows on their PC, support was provided by the OEM and not Microsoft. Effectively, Windows is a business with fewer than 10 customers, but those happen to be Microsoft’s largest customers by orders of magnitude. This idea of a buyer and a user being different parties with different influences on the product development process was quite familiar to me from the rise of enterprise customers in Office. Where in Office we had an ever-present struggle over the needs of the enterprise versus the needs of individuals across the product, Windows had a much more uneven approach. Some teams were extremely focused on OEM customers while others were entirely focused on end-users.

Contrary to most perceptions, the cost of Windows on a new PC (that is the price to OEMs baked into the final consumer-visible price of a PC) was a fairly low percentage of a PC price and the price had remained largely unchanged for years. This would soon become an issue with the introduction of Netbook PCs (to be discussed in Chapter XIII), but by and large the Windows license was both unchanged and a constant source of frustration from PC makers because of that inflexibility. For a variety of reasons, Microsoft lacked the kind of pricing power one might have expected in such a market. This was in contrast with the price of the Intel portion of a new PC, which was much higher and had increased over the years as Intel provided more and more integrated capabilities and provided more pre-assembled parts of a PC with each new processor generation.

PC sales in 2006 were about 240 million units worldwide. That was an astounding number and our responsibility to do the right thing and better things for all those units. The predictions for 2010 and beyond (from analysts such as Gartner and IDC) showed no end in sight for PC growth, breaking through 400 million in the years to follow. However, as frothy as that might have seemed, there were concerns that the growth rate was finally starting to slow. In fact, 2006 appeared to be the first year since economic downturns when the overall growth rate slipped and never reversed that trend with any staying power. Nevertheless, PCs were forecast to grow about 10 percent (adding 25 million PCs, or about the size of the entire global PC-installed base in 1990). The most interesting trend was a bottoming out of sales of desktop PCs—the laptop had supplanted the desktop PC in work, and totally dominated the home PC market. Computing was becoming ubiquitous, and laptops represented both mobility away from home and in the home. Gone were the days of computers taking over a whole tabletop permanently.

As a reference point, worldwide PC sales for 2019 were forecast to be slightly above 230 million following a pandemic surge approaching 325 million that appears to have receded.

To say the business was entirely dependent on OEMs would vastly understate the potential with business customers who would add the enterprise version of Windows to both new and existing PCs, which represented a substantial uplift in pricing (and that translated directly to profit.). As important as this was, it was much more a matter of packaging and pricing as the company had long ago shifted to developing a wide array of business-friendly features for Windows, starting with security and business networking, with much more in the works.

A significant evolution of the Windows business, rooted in both upsell and competing with Linux, was the release of a low-end SKU, called Home, and a more expensive SKU, Professional. Where Office had different applications (or modules), Windows had different features. The emphasis on these SKUs began with Windows XP but was put into full force with Windows Vista. This is a classic product strategy, but due to the nature of the Windows business the financial upside is enormous. A small percentage in unit upsell from Home to Professional is a price increase of tens of dollars multiplied by tens of millions of units, and all of that is essentially zero incremental cost to Microsoft. The leverage was magical. [To those keeping track of present-day Microsoft quarterly earnings, there’s a consistent talking point about the role of business SKUs in Windows revenue.]

Unique to Windows was the desire to make sure developer APIs were consistently available in the most broadly distributed SKU. Everyone wanted every API to be in Home. This constraint is what made specialty SKUs like Windows Media Center or Tablet PC destined to fail with third-party developers—the APIs developers would use to target those PC form factors were only in those narrowly available SKUs (with expensive hardware.) Seeing the tiny sliver of market, developers would rather attempt to roll their own solution rather than ride the tiny coattails of a niche market. This would become important as we broadened Windows 7 to include touch, where most of that support existed only in the Tablet PC specialty SKU.

The Windows Ecosystem could be thought of as four sets of deeply dependent yet independent entities, each believing that they contributed an outsized effort when there was success while each believing the other parties had more than their fair share of responsibility when things were not going well: Microsoft, Intel making and selling CPUs and associated chips and storage, PC OEMs and hardware makers (Independent Hardware Vendors, IHVs), and software developers (Independent Software Vendors). The mutual dependencies are illustrated by a cycle:

* PC and hardware makers depend on Intel and Microsoft to deliver a complete PC experience.

* Microsoft depends on Intel to continue to drive demand with faster chips and new capabilities while enabling PC makers to take advantage of those.

* PC OEMs depend on IHVs to enable all sorts of new hardware capabilities that will excite consumers and drive demand.

* Microsoft courts the fourth leg of this stool, the independent software vendor (ISV or “Developers, Developers, Developers” as SteveB would calmly state) such as Adobe, Autodesk, Intuit, or PC game makers to make applications for a new version of Windows with new APIs or that require new hardware (such as faster graphics cards), which in turn require new PCs.

A new version of Windows without cool new PCs or new PCs without cool new chips or hardware or new software that didn’t take advantage of any of those were all reasons why the ecosystem could become unhealthy. This codependency created an enormously tense network made up of a small number of large public companies, each with quarterly earnings reports. Also, at the time, in the United States, Japan, and Europe, PCs sold through a large number of retail stores so companies such as Best Buy, Dixons, or MediaMarkt were also part of this equation, and they were ruthless champions of low price and opportunity for margin.

The second section of the planning memo outlined what were called big bets. We hoped this would engage the architects and long-term thinkers by laying out significant challenges that we knew would need to be scoped and refined. Intentionally, there was only a small number of these so as to scope them to a single release. The constant discussion on bets was about how to define a bet as a set of steps that could be accomplished over reasonable time periods and incremental success, rather than one giant leap a decade later.

One of the unique things about Windows being part of the PC ecosystem while also being an open platform was that when new hardware was available to integrate into PCs, PC manufacturers could build PCs with support for new devices or peripherals without built-in Windows support. OEMs would write their own code from device drivers through user interface to support a new hardware gadget (for example WiFi or a fingerprint reader.) Unfortunately, this created a problem. Too often, such support did not have great APIs for developers or was not always integrated into Windows in a way that allowed others to make the most of it. But with Windows releases not being so reliable and PC makers always looking for an advantage over the competition, waiting for Windows to figure out support for new peripherals never really happened. With Windows 7 we set out to get ahead of some classes of devices (such as printers, graphics, storage, and so on) with a big bet on hardware-driven innovation but would leave it to the planning process to identify areas where such an approach would work.

There were two other big bets of note. Virtualization was becoming a huge push across the industry. But on that front, Microsoft was falling behind. Interestingly, at many team levels, there was a deep resistance to virtualization because of security concerns that the whole system could be compromised. There were also business concerns due to the Windows business having a foundational belief of one Windows license for every CPU. All the while, virtualization was growing rapidly and on every CIOs radar precisely because of security. Their belief was that virtualization was inherently more secure. It was also the core technology that would enable cloud computing and as such it was critical that we get it right. Competitively, virtualization was critically important for the Windows Server business. VMWare, the inventors of virtualization, was rapidly becoming a technology powerhouse under the leadership of Paul Maritz—yes, the former leader of Windows. Ironic moments such as this were in no short supply.

We also wanted a big bet for the typical Windows consumer, which would give us a chance to incorporate Windows Live services as a key part of the overall value proposition for Windows. Historically, Windows had duplicated services provided by MSN (the predecessor to Windows Live), ostensibly for a whole variety of reasons from legal to performance to security, and at the same time the MSN services did not do any work to shine on new versions of Windows. The ultimate achievement of this was the debacle when Microsoft shipped both Windows Messenger and MSN Messenger on new PCs and both had different sign-on, networks, and features. Another example was when the Windows Mail program did not do a good job connecting to Hotmail. This gave us a chance to say, “We will plan on not duplicating work,” at a minimum, but also push to do great work that could potentially compete with Apple or maybe Google.

In order to account for the heavy lifting that would be required to build on the Vista foundation and yet also fix it to the degree we needed to, we defined a big bet that we called “continuing bets.” This provided a catch-all to plan on the needs for improved PC security, 64-bit computing, and overall cleanup work. The fact that the release ultimately succeeded in cleaning up or completing this work led to the frustrating belief by some that Windows 7 was, in fact, a minor or cleanup release.

The traditional Windows view loved big bets—that felt like the kind of work we did for Longhorn. Many on the development side were perfectly happy to define a release by making progress on big bets, even if the manifestation of big bets would take years and the visible features not particularly visible.

From Julie’s perspective, the plan or vision for Windows would be start with planning themes. Rather than a plan itself, the memo contained ten planning themes. A planning theme was a precursor to a specific main pilar of the release. Themes are an invitation for brainstorming and creativity within that theme. Prior to this there is a step to even pick these themes, but that is a small group and done relatively top-down. The planning themes were broad strokes. The introduction of those themes was really an invitation to begin a process whereby the specific groups of engineers (feature teams) work together to define what it might mean to deliver on that theme—a literal call to innovate and be creative. The themes for planning Windows 7 included:

* Refining the Vista User Experience

* Building Customer Confidence

* Embracing the Best of Web Development

* Helping OEMs and IHVs Win the Hearts of Customers

* Turning IT Pros into Windows Evangelists

* Making it Easy to Add or Replace a PC

* Lighting Up Everywhere with Servers and Services

* Finding Everything Easily

* Connecting Multiple Devices to Multiple PCs

* Embracing Hardware Advances for Better Multimedia Experiences

Over the next three months there were countless offsites, meetings, design sketches, and more to arrive at more detailed views of what features might be built. It was this part of the process that is both the most uncertain and nerve-wracking for me. I not only had no idea if the ideas being generated were good, but I didn’t even know if the teams were converging. There’s no way to even measure this. In the back of my head, I was also wondering if there were developers writing code for new features that we won’t even want to ship while PM was off figuring out what to make. If the goal of the planning process starting with the planning memo was to bake a cake, then I just couldn’t open the oven every 15 minutes to check without ruining the cake.

Over the three months from the planning memo to the creation of a product vision the team is not producing code. The PM team was producing slide decks, PM prototypes, design sketches, and even a little bit of prototype code. The development team participated in this part of the process but was also tasked with watching the market telemetry for Vista and fixing a lot of bugs. The test and development teams together were working to improve the daily build and test process—an enormous undertaking that GrantG referred to as building out “the factory floor.” The 6 years of Vista development and the numerous side releases of Windows had made for a neglected engineering process. There was plenty of work to go around. Having the time to address these pain points and to do so together without a crisis enabled even this type of work to become part of the culture change. JonDe dug into every aspect of the daily development process, which he had become acutely aware of in his role leading Engineering Excellence. Fixing the factory floor would prove to be an enormous win for morale and efficacy.

Then suddenly the cake was ready. There was a vision. Reading this, one might really want to know what precisely went on for those months. How did the team go from brainstorming to a plan? The lack of a concrete description of this is why it has always been somewhat magical. It really isn’t magic, but it is empowerment, accountability, and creativity. There was never an answer other than build a great product, but pieces had to fit together, and everyone had to agree and reach a shared view of what was being committed to and being built. Every offsite, prototype, and sketch were talked about, debated, and considered. Most were thrown out for any of a myriad of reasons.

There was, however, one bit of magic and it was connected to a cultural change. The typical (in Windows and elsewhere) executive management role is one where teams go off and generate ideas and come back with a plan, for approval. Invariably during a meeting for approval the plans would be changed with the incorporation of executive feedback. The problem I always had with this was the underlying assumption that an executive thinking on the fly about whatever specifics or details arose during one meeting for an hour after weeks (or months) of work was truly value added or just value changed. I never had that much confidence. We started from an assumption that the plan was already approved, and the meeting was a confirmation of the plans the team created and was accountable to. The magic was that leading up to those review meetings we were, JulieLar in particular, in a constant and iterative conversation about ideas, tradeoffs, and specifically adherence to the evolving product vision. This led to a much deeper sense of ownership and buy-in and avoided the historic problems of swoop and poop or simply random executive thoughts.

We called the transformation of planning themes to the product vision a pivot (Microsoft loved to use the word pivot in just about every context, especially because it had nothing to do with basketball.) We were pivoting from a long list of themes with ideas of problems to be solved to a much shorter list of vision areas each with specific scenarios we would implement. This is why the vision represented a true product plan.

On July 27, 2007, we gathered the team at the Meydenbauer Convention Center—yes the entire Windows product team was invited—for a meeting where we presented the product vision. The all-team meeting was another step in the culture change. It would be the first time the whole of the Windows team got together to hear the entire product plan—the committed product plan—for a Windows release before coding started. It was so important to me that everyone really experience what we intended to build and to have that moment when as a team we commit.

Just as we did with Office, the product vision consisted of a substantial memo (this time with a bit more up front on how to read the memo), a series of produced design sketches showing each of the main themes of the release as we intend to develop them, a mock press release created by marketing showing how the release would be communicated upon shipping, and my favorite the one page cheat-sheet for the vision.

Even though we had been together for more than year as a team, and Windows Vista had been in market for six months already, we were still transforming and growing as a team. While everyone really wanted to know what everyone else was going to build (by this time most people knew what they were going to start to build) I wanted us to continue to build the culture. I had a slide defining a successful Windows 7 as a set of key traits feeding into success (using Office SmartArt of course): promise and deliver, develop satisfying features + scenarios, create partnerships [not dependencies], participate and communicate, learn and iterate and improve. Still, we had one more slide articulated how to use the vision. At this point, if you’re not convinced management is repetition…

Before JulieLar would take the stage and share the vision themes and features, we had a special speaker. Although now formally transitioned from his role as Chief Software Architect to philanthropist and Chairman of the Board, I thought it would be important for BillG to share a personal view on the role of Windows within Microsoft. He delivered a wonderful and improvised talk without any slides. It was a mix of history and enthusiasm for the most recent innovations lasting about 15 minutes. He spoke of the patience we showed in building Windows after the first releases that were too early and the bet on having Office for Windows which made Windows better and Office better. I did ask Bill to emphasize competition knowing that was near and dear to him, given I had already shared with him my view that there was a bit of a lack of fire in that regard. The iPhone was just weeks on the market and the potential impact on the PC industry was just becoming clear and did not escape Bill’s mention, including some speculation about a tablet-sized device for reading (this will be discussed in Chapter XIV.) He also touched on Linux competition which was acute in the enterprise space and on servers. The highlight for me was when Bill held up the vision one-pager and reinforced that this was the product he was expecting, and he too would behave and not ask people about things not part of the plan—the team applauded and that made for quite a moment for me. That moment didn’t last long as he then told the team it wasn’t critical that we hit the ship date as long as we got all the scenarios working—that is the Office baggage described in previous sections where Office somehow cheats by cutting features to ship on time. There is a recording, but it is poor quality—just a camcorder in the back of the room. 

JulieLar presented the vision itself. It was a work of art. From a dead stop after Vista she pulled the entire PM team across WEX and COSD through a foreign process (an Office process no less.) I could see the excitement and almost amazement from the team as I stood in the back of the room doing all I could to get a sense for the vibe. The vision for the release had five areas:

* Specialized for Laptops

* Designed for Services

* Personalized computing for everyone

* Optimized for Entertainment

* Engineered for Ease of Ownership

Each of these were detailed with scenarios, business motivation, and a definition of success and then illustrated with a narrated design sketch.

Following this ChuckC, Julie’s counterpart from the Windows Core System team in COSD, presented the project tenets. These were the non-negotiable aspects of the project:

* Design for interoperability

* Security is a key promise to customers

* Runs with existing hardware

* Application and driver compatibility

* Getting ready for 64-bit only

* Performance breakthroughs for key scenarios

* Improved Reliability

* Design for sustainability, manageability, supportability

* Design for every market, every language

* Improved accessibility for all users

Chuck outlined the project schedule which included three milestones—each an opportunity to re-evaluate, adjust, re-allocate resources, and adapt the plan. We would begin coding in 5 weeks, after the US Labor Day holiday. Windows 7 RTM was set for May 13, 2009.

Mike Sievert (MSievert), the CVP of marketing (and as of this writing, the CEO of T-Mobile) provided a detailed overview of the current state of the business and opportunity. KevinJo spoke about the importance of Windows Live, which was in the process of executing a plan to run on a shorter schedule and would have a releases of services for Windows 7 at availability. He also addressed what was top of mind for both of us, which was adhering to the newly announced Windows Principles a series of proactive steps to managing the business that the legal team put forth on their own in hopes of setting a different tone with regulators.

JonDe spoke to the deep technology shifts in the PC industry where the COSD team had historically focused their energy and where the big bets at the core OS level were critical, especially for Windows Server which shared the OS. He spoke to the work we needed to continue including:

* Multi-core and many-core

* Virtualization

* GPUs

* Wireless

* Storage and non-volatile memory

* Power management

* New and popular devices: GPS, biometrics, web-cameras

* Diverse form factors

To set an example, the meeting went like clockwork and lasted three hours, and there was even a break. After the meeting, I sent out the full memo to the whole team. I recently acquired a new ultra wide-angle lens for my (then fancy) DSLR and took a team photo. Everyone was in their limited-edition color-coded t-shirts which was always done tongue in cheek but certainly plays like something one would see on a bad take of a tech on HBO. I still see these Windows 7 t-shirts around town, which amazes me. I even saw one in a yoga class in Silicon Valley, years after vision day.

I followed up with an Office Hours blog post expanding on my themes of what would make Windows 7 a successful release.

The day could not have gone better. I had been through many vision days in Office, but this one was truly a special moment. I genuinely felt like we had reached a milestone of cultural change within the team.

I was of course kidding myself. I only felt that way because for 15 months non-stop I had been saying the same thing over and over again gradually improving. But we were just now starting the real work. Other than my own fatigue, there was no evidence yet to support an assertion that we would get the release done. In reality, I remained terrified. I couldn’t even hide it. KevinJo sent me mail after the meeting saying he felt the meeting was great, but he thought I seemed down.

I was not down—the day was really excellent. I was, however, worried. Would this be enough? Would we get done on time? Was on time even soon enough? We had so much to do. We had so much to fix, starting with the relationships with PC makers who were truly suffering with Windows Vista.

On to 089: Rebooting the Ecosystem

After thinking and writing to provide context to BillG, SteveB, and KevinJo, I had to begin the real work of changing the team. As much as I would have liked to avoid the second step of the “Three Envelopes” (having skipped the first) I found myself planning a reorganization. Not just a reorg though—Microsoft was by many accounts in a perennial state of “reorg hell”—I was planning an organizational change and cultural transformation that would have an effect on every member of the team, almost immediately. That meant more writing. More communicating. A lot more.

Back to 086. The Memo (Part 2)

Most big company reorgs are fairly routine affairs that nevertheless cause teams to drop everything, stress out over the weekend (because reorgs always happen on Fridays) and contemplate what might change. But then returning to work on Monday, little changes immediately except for somewhere up the org chain there’s a new boss who will in a matter of time introduce some changes. Most reorgs are not nearly as big a deal as all the time and energy that goes into talking about them.

This was especially true at Microsoft which, at least to many, felt like it was in a constant state of reorg hell. In my early days at the company, I experienced several reorgs in the most senior (other than BillG) executive structure from having a president to not having one, to adding a COO to removing a COO, three-in-a-box (the BOOP, Bill and the Office of the President), back to a president, then a president and COO, then SteveB as CEO and BillG as Chief Software Architect, and so on. Office itself bounced between a few executives over the years as well. In fact, just as I was in the middle of planning this June 2006 announcement, BillG announced he began transitioning from Microsoft to spend more time at the Foundation. Ray Ozzie (ROzzie) would be appointed Chief Software Architect (CSA).

The thing about reorgs is that most people are trained, best case, to scan the reorg mail and see if their team is directly affected by the change. Specifically, how far away is the new boss. If there’s no immediate impact, then just go on doing what they were doing. In practice, most reorgs at scale don’t affect most people directly or immediately.

The Windows and Windows Live changes were not like those reorgs. This was not a change at the top. This was a change for literally everyone in the organization. More than half the team would get new managers soon after Vista shipped, and everyone would have a new manager no more than three hops up the chain.

It was even more than just that. Jobs were changing and with that many mental models of career paths were being upended. Everyone who thought they had plans for what would be next would wake up to something different. Aspirational jobs as a PUM or an architect with no direct reports (or code) were no longer going to be available. We were an engineering organization, and everyone was going to be asked to focus their trajectory on building products. Even becoming a manager was deemphasized as we asked managers to take on more directs while we reduced the percentage of the team that were managers by one-third.

Then beyond that we had every intention of radically changing the way we would work. Everything from the planning process to daily builds to milestones. Even meetings with execs would decidedly change (or mostly go away).

I spent May and June 2006 on two things.

I was mostly meeting more people on the team and figuring out who would be filling in the organization I am about to describe. These meetings were a constant reminder of the desire for change. They were also opportunities for ongoing reminders that Windows and Services are different and more difficult than Office. I probably wrote 500 long emails replying to questions about everything from the future of specific technologies (most of which I knew nothing about: USB, DirectX, virtualization, and more) or to suggestions for how we could improve. I received quite a few questions asking “how do you want us to…?” on everything from hiring to signing purchase orders. There were many questions that were very specific to situations and people that I knew nothing about. The questions always seemed to boil down to process and culture challenges, never about domain expertise. It was 7x24 from the end of March to the end of June.

To remain sane, I was also installing daily builds of Vista and Office 2007 which were both winding down. Not being in the daily triage meetings for Office was kind of sad for me. I vividly remember sneaking over to the ship-room meeting one time, which proved to be silly and indulgent on my part and a distraction to the team. It was, for me, a moment of sanity just to see the team working, and by that I mean not taking any code changes.

Mostly, however, I was genuinely scared. I had absolutely no doubts about what we needed to do, including how to structure the team and what to ask of them. I had a lot of doubt that I’d be able to pull it off and most days wondered if I was the right person to drive these changes. There was so much baggage coming from Office.

Something that I was keenly aware of was how many managers, myself included, viewed reorgs as something of an adversarial process. A reorg was something to protect the team from, not something that could help. Reorgs prevented work from happening and were a distraction. That’s certainly how I treated a lot of what went on above me for most of my career.

Now it was my turn. The very last thing the company needed was for people to view the changes I was putting in place to be prevented or redirected. I was terrified.

Would people quit? Or likely, how many people would quit?

Would people run to the gossipy press or Mini-Microsoft?

How much email would be sent to SteveB or BillG? And, yikes, would they answer it?

What if no one wanted any of the new jobs I was proposing?

My first step was to figure out the new leaders. In picking those leaders I was also certain of how the overall organization would be shaped, my direct reports and their direct reports and so on. This structural change was the visible symbol of the reorg. It was a massive pivot away from a product unit organization to what I called a “functional organization.” A functional organization is based on having discipline specific leaders reporting at the top and their teams consisting entirely of people within those disciplines of development, testing, and program management. Across each of the disciplines we would have mirror structures of group managers, leads, and individuals. I sketched out the math and knew we could build the organization out of about 40 teams of 25 developers each (and 25 testers and a dozen program managers, under their discipline leaders.) In due course, the intention would be to organize COSD this way as well though we needed to let them finish Vista for a bit more time.

I would love to spend more words in this section describing the inherent tradeoffs between these two organization types, but it would be a bit of a distraction from the story. Instead, I would refer the reader to Functional versus Unit Organizations, an essay I wrote in 2016 on this topic.

In assembling a team of new leaders, I tried not to be the guy who brought “his people” from his old job, but there simply weren’t any candidates in Windows that would champion the changes we needed. You’re not supposed to show up with a team, but managers almost always do. I never understood why that was the case, but after living through this I have a more visceral understanding. It is not about the personal connection, as most think, but in times of change you need to have a team of people who share the same world view by default without having to guide at each step. Without that, change is impossible.

I thought I wasn’t going to be that exec, but I was. Only to a point, however. Within the team, I was able to find a balance of “natives” and “imports.”

Here’s how the leadership team shaped up: The Search team remained as it was, under Christopher Payne (ChrisPa) working on its own roadmap and plans, but with much more capital and more people and soon a functional org structure. Chris Jones (ChrisJo), a longtime executive on the Windows Client team, would lead program management, design, and research for Windows Live Experience, WLX. Leading development would be Steve Liffick (SteveL.) Steve had Windows Live deep in his DNA, but he had been a program manager his entire career (having grown up in Seattle, interned at Microsoft, and joined straight out of college the same summer as I did.) The challenge facing the team was a lack of senior enough software engineering leadership to manage a team of several hundred, so he agreed to manage the engineering team and would prove to do an excellent job over time. Arthur de Haan (ArthurdH), a longtime test leader in Office who had built out the internet services operational infrastructure, also joined the team to lead test and internet operations.

The new name for Windows Client was the Windows Experience team, or WEX (pronounced weks). WEX needed a program management leader. In many ways this job was the program management job at Microsoft. Vista screamed out in need of program management—it needed a holistic view of the user, the customer, and the experience. Julie Larson Green (JulieLar) was ready for a new and bigger challenge after leading such an extraordinary effort redesigning the Office user interface. She was just recently promoted to vice president for that contribution on top of her long history of successful product development and team leadership.

Aleš Holeček (AlesH, which coincidentally is the proper pronunciation of Aleš) wore his Czech heritage proudly and maintained close connections to Prague, one of the most creative and vibrant tech communities in Europe. He also frequently, and inexplicably, wore bright red pants. AlesH was in the process of leading a rescue mission for large parts of the most visible portions of the Longhorn Reset. In short order, as a new hire to Microsoft, he had established himself as a strong leader and deeply knowledgeable and respectful of Windows as a third party developer, but also clear on where Windows needed to go. After several discussions, I sent him the shortest of emails asking if he wanted the job leading WEX Development. An hour later we had a leader.

The testing role for WEX was going to be the most visible testing leadership job in the entire company. Windows, almost more than anything, was a product of testing. Grant George (GrantG) was busy completing Office 2007 and was so focused he was reluctant to even chat about what comes next—focus was one of Grant’s defining traits as a test leader. In speaking with him, it was clear he was excited about the challenge. But he had also been much more deeply involved with Windows than I had considered, especially over the past few months, and hesitated because of his concerns about the culture. After a couple of weeks of being left to his own thoughts, he came back willing to sign up. This was a huge win for the team.

With a team in place, I penned the longest reorg mail of all time. In hindsight, this surprised nobody, but at the time it was, well, shocking. It was not just an announcement, but an explanation and justification for an organizational pivot—moving from product units to a functional organization with large groups of each engineering discipline and very few product unit managers. While not an intentional play on words, functional organization worked that way too.

On the last Thursday in June 2006 (breaking with the tradition of Friday afternoon reorg mails), I sent out a 3-page email with an attached 20-page memo (with no org chart or diagram, and no to-be-hired spots). At more than 13,000 words the memo was titled “Windows and Windows Live: Organizing for agility, Competing with focus, Building must-have software.”

I even did something I had never done before, which was to copy the mail to all of Microsoft’s executive staff and their direct reports all around the world. There were about 150 execs at the time plus their directs (and usually staff). I broadcast the mail, in the last days of the Vista project, to send a message that we were working and making progress.

As soon as this mail landed in the inboxes of about 6,000 full time engineers (and designers, localizers, planners, and more) they would all hear that their jobs would be different. But precisely how would take time. It would take weeks to build out the five or so layers of the organization, down from 7 to 10. There was no spreadsheet with all the answers for each person. Not even close.

In fact, taking a lesson from Office, we put in motion something that was yet another point of evidence of how different things would be. There was going to be a bit of a free market for people to stick their collective heads up and decide what they might want to work on next. Everyone had a job, working on their old area or perhaps trying something new. At the same time, the new execs would be choosing new direct reports who in turn would be choosing new managers and those people choosing new leads.

The previous two sections detailed the process I used to learn and the memo I wrote for an audience of three to crystallize my thinking. Now it should be clear it was a rough draft for broader communication. I moved from “Observations, Aspiration and Directions” to “Organizing” and as you look at both you can see the tone moving from analysis to action. In many ways I was employing the same planning process we use for software to design the organization—open a funnel to inputs, iterate, and at each step distill down the actions to what is essential for success.  

But hitting send on this memo led to the most workplace stress I had ever experienced or would experience, not to mention the stress for all the new leaders who would be crushed with questions and concerns. Significantly, I knew how stressful this was for every individual. I felt or hoped that the messages would be read and considered even if not immediately validated, recognizing the emotional nature of so much change.

There was sizable pent-up demand for a reorg as that is what people were expecting, but I was terrified that somewhere in this memo I unintentionally offended someone, or that I perhaps expressed too much candor, offending a constituency in a deep and unrecoverable way. I was certain that I was going to immediately get an email from Mary Jo Foley at ZDNet, who was going to reprint the whole memo (I even had a “I am being transparent so don’t make me regret it" plea in the mail message cover note). It worked. No leaks.

I diverged from Microsoft culture in ways many found shocking but was routine for me and Office. I sent out a reorg mail without a directed acyclic graph of the organization at the top of the mail. Even more shocking, there was no org chart at all. When people opened the mail, it was as if they had opened a box of Cracker Jack candy and couldn’t find the prize. I received countless replies to the mail asking for the org chart, some of them not particularly supportive of this cultural statement which was simply perceived as incompetence or insensitivity. Additionally, the organization was complete in the mail, absent any open positions or to-be-hired.

On the other hand, I also received so many replies that were positive beyond words. The desire for something significant to put the team on a path to better results was clearly in the air. From my former co-worker in Office, Jeanne Sheldon (JeanneS), who is (even to this day) an absolute stickler for brevity and clarity in writing (a decade leading Word testing would do that even if originally choosing to work on Word because of this skill) had perhaps the kindest words. Jeanne replied to me saying “This doc is a masterpiece of clarity and focus. Although it is long, it could have been neither longer nor shorter. Wish you could do another employee poll tomorrow.” I needed that.

Much to my relief, the mail received a rather heartwarming reception. I received hundreds of messages from people who appreciated the transparency—the mere heft of 20 pages, which I know most people did not comb over like the Code of Hammurabi or anything, provided some air cover. (Some even complained about having to read a memo of such length—a complaint that would become something of my brand if it wasn’t already.) Being able to answer questions in town hall settings and then saying “there’s more in the memo” became a bit of a rallying cry for me along with a pointer to the inevitable follow-up post on my Office Hours blog.

Still, I received a few dozen deeply emotional mails combined with one-on-one conversations. These were people who were the most affected, particularly by the perceived loss of status or career trajectory when it came to product unit management. I knew these conversations would be the most difficult and dealt with those the best I could. No one was being demoted in any way from my perspective and the organization had a place of equal level and opportunity for everyone. There were no formal staff reductions at all. Surprisingly, we fielded queries from the press about layoffs which were never considered. I was asking people to take on roles more directly accountable to engineering outcomes. For some, and it was a small number, it was just not appealing, and they moved on. Each one of these cases was enormously difficult. I’d like to say there was some emotional distance for me because I didn’t create the situation we were in, but there’s no way to avoid the feelings of the moment—I in fact did create this change.

With the mail and the memo, I went out on tour and so did each of the new leaders. The slides to explain the reorg were focused on the strategy of “Why are we doing this” and “Why are we together.” KevinJo came up with a hierarchy that we used across his expansive world consisting of product lines, engineering areas, and feature teams. Kevin was used to organizing tens of thousands of people and had real insights in how to use hierarchy to communicate.  

I answered the “Why are we doing this” question with a slide on “Goals of Organization Changes.” This was the core of the discussion. I made people sit through my talking about this slide at length rather than, as usually done, emphasizing the structure or org chart of the team. The reasons behind the org were a direct reflection of the past 90 days of learning as I thought back to the first memo previously described.  Many of the exact same words were used that I had written a month earlier.

In the description of product lines, we intentionally left off the name COSD but it was implied in the Windows/Windows Live product area. People would get the message that COSD was part of Windows, not separate or even Windows entirely.

To address the question of why we were together I created a table of the engineering areas for WWL: Search, Live Experiences, Internet Explorer, Windows Experience. The “glue” as I said at the time was that Windows, as critical as it is, needed a series of connected services that were core to Windows. This was a subtle shift away from Services independently focused solely on advertising. This vision would take time to materialize. One can see how Apple was also just starting this same push with iLife and iWork on the Mac. Recalling the fits and starts of services connected to Apple products is a great learning exercise. What we know as iCloud today was originally launched in 2000 as iTools, which were desktop applications for photos, video, and productivity. In 2002 the addition of email and other online services came with the branding of the .mac service. Then in 2008 (two years after our org change) the service was renamed to MobileMe and greatly expanded, which lasted until 2011 when it became iCloud. Phew. That is some journey to get right. We would struggle much the same. It is interesting when everyone seems to have the same idea of where to go but takes many years to get there and not everyone even arrives at the future the same way.

The other glue across WWL was Internet Explorer. This was the era when tuning online services to the latest browser was still important. The struggle to deliver great experiences via the web that matched desktop applications was significant, as was owning the “frame window” for delivering advertising and promotions. Due to the declining popularity of IE and lack of work on a new version, Search and WLX (and the rest of the internet) had pivoted hard to optimizing for Firefox. It is not without irony that as I write this in June 2022, Microsoft has just announced that Internet Explorer has been officially retired and replaced by the Edge browser based on Google’s open sourced code.

Each of WEX, WLX, Search, and Internet Explorer had sections that outlined the major themes to be investigated or worked on for the next products. There were no names of feature teams, no schedules, no user interface sketches. Astute readers could see where we were heading and how, as we dove into more understanding about these areas, it would inform the next level of the org structure and then specific product features would follow. This is what we had mastered in the past four releases of Office, so I felt confident we could scale it here.

Change started with this memo. I summarized this change as follows, quoting from the original memo:

This memo represents a change.  Change is difficult.  Change is uncomfortable.  Changes that look good today might also have looked good before and failed.  Changes that look good today might not be so great tomorrow.  Change is risky.  The changes outlined here are not just tweaks, but represent the first steps in working in a substantially different manner.  Many of the issues raised by members of the team are about the culture of our organization—these are the aspects of “how we work” that must be addressed. 

This memo is about the top line changes—the organization and priorities—and over the coming months the way we work together will also change.  We will push more decisions down.  We will aspire to a more consensus approach to decision making, rather than an escalation approach.  We will streamline our organization with fewer managers overall, and fewer levels of hierarchy.  We will value our core engineering disciplines more and demonstrate this by building an organization that focuses on the role of development, testing, program management, with integral contributions across the product line from design, usability, planning, localization, business development, operations, and more.  We will ask our teams to be clearly focused on deep technical contribution in a smaller number of well-defined areas, rather than breadth of coverage at too shallow a level.  We will allocate resources more deliberately and generally in smaller teams.  All of us may not operate with the same tempo, but we will all operate with a rhythm and not move from crisis to crisis.  We will operate with a clear framework with a clear understanding of how we will define success, a framework that is flexible and has vast room for innovation, yet represents a commitment to customers that we will deliver. 

These changes are part of the agenda of this memo and our organization moving forward, but will require all of us to learn and grow together.  I am committed to doing my part.  I will not dive into the middle of situations.  I will not randomize your work.  I will not be a bottleneck for decisions.  I am here to work with the senior leaders of the team to provide the framework, define success, provide the resources that map to those, and make sure we have the right people with the right skills in the right jobs to get the work done that you commit to doing.  That is my commitment to change. 

A few weeks after this communication blitz (July 22), KevinJo announced that Jon DeVaan (JonDe) was going to lead COSD also reporting to him. Partnering with JonDe was going to make everything better—Microsoft was very lucky that Jon took on this role. This was a bit of a reunion for us. I thought back to meeting Jon the first time in the summer of 1989 when he pointed out so thoughtfully how interesting yet naïve (in a commercial sense) my views of memory management bugs were. Then through a few releases of Office as peers and then Jon as my manager, promoting me to vice president. Over the past few years while I remained in Office, Jon had been leading a new team called Engineering Excellence, which brought all manner of excellence company wide. Under Jon’s leadership the team introduced and deployed tools and software for training and management as well as individual excellence. Largely not followed outside of Microsoft, the EE team was critical in scaling, training, and developing the company’s engineering capabilities across every product line. It was the first substantial effort at training engineers since “Klunder College” for new applications developers, which ended decades earlier. Jon was uniquely qualified given his lifetime of experience to re-energize the engineering culture of Windows. So loved as an engineering leader, an early 1990s pre-beta build of Excel once read “Excel DeVeloper Release” in the About box.

Jon created a top-level organization structure to parallel WEX by naming three senior leaders for development, program management, and testing, respectively Ben Fathi (BenFa), Chuck Chan (ChuckC), and Darren Muir (DMuir), each experienced Windows leaders, for a new team Windows Core Services (WCS). Their peers and counterparts in WEX were AlesH, JulieLar, and GrantG. In addition, Jon would have a team of architects (the original COSD architecture team) as well as the corporate resource team for security engineering, a.k.a. Trustworthy Computing, and a large team providing the fundamentals engineering, engineering tools and measurement, sustained engineering, and support for in-market products that would produce urgent, monthly, and regular service updates led by Wael Bahaa-El-Din (WaelB) called Windows Engineering Services (WES.)

The WEX and WCS split of Windows was a first turn of the crank organizationally to building a unified Windows team. Jon and I were 1000 percent unified at the top. Our respective teams were unified. Still, it would be fair to say that the old rivalry or tension between Windows Client and COSD would continue to manifest itself until we were well into building the next product. Jon and I were working to create an organization of peers, but history did not see the teams that way. There was a lot WEX would need to prove to WCS in term of focus on performance and quality, and much WCS would need to prove in terms of building an exciting product. When tensions would arise so would the old names of Client and COSD—that’s how Jon and I knew we still in the midst of a culture transformation. In practice, the COSD name stuck around for the release as we most always were talking about WCS and WES (I will generally refer to COSD throughout this chapter.)

In practice, this was all part of the slow-rolling process of changing the direction (the culture) of a giant ship. The structure is only the first change of many. I remember when I was relatively new to Microsoft and BillG created the Office of the President and announced it at a big meeting (well, it wasn’t that big since all of Apps fit in the old Kodiak room back then—still hundreds of people total) and then went back to my office and kept working. An analogy I often used about change came to mind. The reorg was like how the Soviet Union fell and then the next day everyone was back at GUM waiting for winter coats to arrive, but over time there would be huge cultural changes.

As interested (or perplexed) as people were with these changes, they wanted to know who their boss would be and what they were going to build. Reorgs always come down to the most localized interpretation possible.

Something I should say about this organization that is incredibly important. While I’m obviously as biased as can be, this was the very best team at precisely the right time to do exactly what Microsoft needed to get done. Perhaps that is a bit much to say, this was decidedly a collection of Super Friends, each of whom brought their own unique “super-power” when Microsoft needed it. For the remainder of this work, everything good that I will write about happened because of this group of leaders. The Microsoft of today owes them enormous gratitude, not just because of what they did from this point forward for Windows, but several were also foundational leaders of Office that so dominates Microsoft today. They ran towards the fire.

But figuring out what we would do was going to take another six months. Whether that seemed like a lot of time or a little was a matter of perspective. Teams that were done with Vista would just start doing what they thought should come next, likely what was just cut, rather than what might be optimal for a product plan. Whether the team wanted to acknowledge it or not, there was also a ton of work to be done on the basics of the engineering system.

The changes weren’t over. They had barely started.

On to 088. Planning the Most Important Windows Ever

The previous section detailed the raw observations on Windows and Services culture I saw after weeks of hearing about the situation from as many people as I could. I could not just put that out there without specifics of what I thought could improve. I had to put some structure on what I learned and to offer optimism and aspirations.

Back to 085. The Memo (Part 1)

Reflecting on this moment of both optimism and fear, today I look at the candor I expressed with a bit of amazement. I wrote with detail and assertiveness yet seemed to forget that I was writing about one of the most successful businesses ever created. I was writing about hundreds of billions of dollars of market capitalization. I was writing about many friends. At the same time, there was so much that needed to be improved or more specifically to be repaired. I think what really motivated me were all those 1:1s I did and hearing all the different people expressing their pain and troubles, knowing things could be better. This was not a team that was dug in ready to resist change. It was a team waiting for change. It just needed to be the right kind of change.

That reality made this much easier. I felt if I could document what was going wrong and the broad population agreed then I was on a path to addressing challenges. If I could articulate reasonable aspirational goals, then what remained was to build a product plan on that rebuilt foundation of trust in management.

I was quite worried that both the problems described and the aspirations I would document would seem cliché. With BillG in particular, over the years he had shown little patience for the broad topic of management. His world view was always that the business would be best served by taking on the most difficult technical problems and developers would be anxious to tackle such challenges. That recipe propelled Microsoft for twenty years of Windows but was failing us now. SteveB was never one for patience and while he would be receptive to these management challenges, he was far more anxious about a plan and the timeline for the next product to address the concerns that were mounting about Vista—the company hung in the balance. KevinJo had just orchestrated a massive restructuring of the global sales force before taking over most of product development. He was deeply in sync with the idea of identifying organizational problems then directly addressing those.

The memo, Observations, Aspirations, and Directions for Windows and Windows Live, proposed three main areas to address: decision-making, agile execution, and discipline excellence. Each was presented in a section with both observations and aspirations.

* Decision-Making

* Agile execution

* Discipline Excellence

These points will sound like random musings from any generic book on management, both at the time I wrote them and reflecting on them today. The lesson learned, using the phrase from the previous section, is to demonstrate that these are more than clichés by citing specific examples that resonate with the employees who are being asked to operate differently and specifics on exactly how we will achieve aspirations.

Decision-Making

Across all of Microsoft, “decision-making” had been a constant and nagging issue. We discussed it after every MS Poll (the yearly survey of employee attitude and feedback), and each year I was left puzzled. It had never been an issue for our team (in the MS Poll and other feedback channels). I didn’t understand what was so difficult about decisions. We made decisions all the time in Office, so many it wasn’t even clear to me what decisions were so difficult.

Then I arrived in the Windows hallway.

There, it was an endless discussion of who “owned” a decision or who was “accountable” and, worse, people were asking me what “model” I used to make decisions. This was a reference to classic models of business function (or more aptly dysfunction) that use tools known as a responsibility assignment matrix (RAM, one such tool) for decision-making. One labels participants as: Responsible, Accountable, Consulted, and Informed (or RACI). Another such tool, OARP, stands for Owner, Approval, Responsible, Participant. These tools consistently proved frustrating and there was little evidence that decisions were made with less effort or more importantly, more staying power or higher quality.

The use of these tools arose as a defense mechanism against executives and managers who were prone to swoop and poop, a metaphor I learned as I assimilated into the team. As with birds, many managers seemed to show up at inopportune times, issue a quick opinion or edict, and not stick around for the mess they left behind. How much of this was actually a mess or simply a reaction to executive authority or inability to influence decision-making would take time to untangle. The expectation for me as a new Windows executive was that I had a tendency to employ this technique, no matter my own personal history or approach.

What I knew already to be the case turned out to be a big part of the problem, and that was a culture of escalation. In all software projects at scale, it is always the case that one team depends on another team—to provide code, consume code, integrate things together, and more. And this extends to sales and marketing connections. In Windows, escalation seemed to be the way most situations between teams were handled. It was a culture in which nothing was decided until people got in front of a VP, resulting in a culture where most of the middle management layer was biding time. And did I mention there were 7 or 10 management layers in Windows?

Weening the team off the culture of escalation proved to be one of the bigger cultural transformations I needed to make. It was also the root of challenges over many years of work between Windows and Office. In a culture of escalation, decisions made by people on the front lines, so to speak, rarely stick. In fact, escalation was done expressly to reverse lower-level decisions. If a Windows partner or collaborator doesn’t like the situation then an escalation ensues, and rarely did things stay the same. Office loathed escalation. Decisions were pushed down and stayed down. When people tried to escalate, they were told to work it out. The result was that when Windows tried to escalate decisions in working with Office they rarely got overturned, which proved enormously frustrating to Windows. And when Office tried to make plans, they would often find them upended at executive escalation meetings with Windows.

In Office, escalations happened so infrequently I cannot even recall any specific instances. In fact, we in Office had a saying that “escalation is failure.”

The primary downside of escalation is the way it shifts accountability. The winning side in an escalation feels an accountability not to the decision, but to winning the process of escalation. The losing side (and yes, they feel like they lost) does not feel bought into the decision and if it does go wrong, they too will join in the chorus of pushing blame up the chain. This is exact opposite of what you want to happen in times of making difficult decisions. The second-order effect is the obvious problem that as decisions are pushed up the chain there is less detail on execution related issues available, and usually that is where the trouble starts. These downsides were especially acute in mid-2000s Microsoft which was so much about improving accountability.

Given the crisis situation I was facing it would have been trivial to declare some sort of emergency and take control like a field general in a losing battle situation. Not only would this have been straightforward and arguably predictable, but it would also have fed right into the dysfunction that was already present. Sucking up all the difficulty would have been another management cliché, but one I could avoid.

Changing the culture surrounding escalation was going to be tricky. I decided to focus on consensus as a core tool for decision-making. I had to work hard to help people to understand that consensus was not the same as design by committee or groupthink—I’d always seen these as distinct when operating well. I also felt it was important to remove two tools that were all too frequently used to avoid either committing to consensus or collaborating, or to create dependencies between teams: Agree to disagree and Non-goals.

Agree to disagree gave each team the freedom to act how they would have acted prior to coming together to reach agreement, while also getting credit somehow for trying. The result was a product design/development conflict, which would fester through the development cycle and later be a customer problem.

Non-goals offer up a list of all the things a project won’t accomplish, which at first seems helpful. I never understood how such a list could be finite since there was an infinitely long list of features and ideas not in the plan. In practice, it became a way to kneecap executive input on potential collaborations or connections to other parts of the product by simply stating them as non-goals up front.

Executive presentations often began with a slide stating non-goals. Such presentations often ground to a halt debating non-goals as a result. Often the non-goals ended up looking as though the team would get nothing done at all. There’s a general rule to follow which is never offer negative goals up front. Early readers of Hardcore Software might recall the story from Office 97 when I spent weeks unraveling the damage done when the routine status report included a very long list of feature cuts, but no indication of what we were actually delivering. Bad idea.

My new team had an over-reliance on metrics and process as a mechanism to drive or force agreement on issues. This was exhibited by the constant drumbeat of red-yellow-green scorecard reviews in Windows or the KPI process in Services. These processes took an enormous amount of energy while also creating a sense of disempowerment in the organization.

The execution of these practices was fundamentally flawed. In both Services and Windows, the culture developed around having a policing team derive and measure the results, which only created an us versus them dynamic. As one example, in Services the small product planning staff organization actually believed it had the job of “determining the work that needs to get done by 800 FTEs” (a quote from a planning manager). Yet most of the debate and discussion took place around “are these the right metrics” or “are we measuring this correctly” as expected. And when the organization wanted to do something, but the metrics did not all point in the right direction the org still moved ahead. The result undermined the entire KPI process.

I offered a specific example that was going on in real-time. The team was deciding whether to turn on a new HotMail user interface for all users. The KPIs established by the planning team clearly said not to do this, but the engineering team needed to for testing and scale. Thus began a discussion over “maybe it is OK to meet 2 of 5 KPIs” or “perhaps we should weight the KPIs.” All the while when you think about it, this is an engineering organization, and it was unable to determine if the software was ready then that was some seriously deep trouble—and this was the largest flagship service.

These common techniques—decision-making frameworks, non-goals, agree to disagree, and metrics—were too often employed in forums for deciding and seemed to have the exact opposite result. These were, however, just obvious signs of poor decision-making. It was apparent we could improve everything about deciding if I personally modeled behavior and worked from the top-down to change the culture. With that in mind, the aspirations with respect to decision-making included the following (summarized from the original here):

Consensus among engineering peers. To avoid escalation, the team needed to arrive at a culture where the experts in the code (no matter who their least common manager is) can together reach a consensus on what to do. Once a decision about what to do in code (design or test) brings in general management we have reached a failure point.

Consensus among disciplines. A significant issue in decision-making was the failure for executive management to provide a framework for decisions. I saw too often that poor choices were the result of discipline silos or unsolvable situations. For example, executives pushing on development for a certain date while pushing on program management for more features while not giving testing enough time. To counter this, I offered an aspiration of reaching consensus across engineering disciplines before escalating while also committing to providing frameworks that allow for the unsolvable problems (schedule versus features for example) to be solved.

Agreeing to disagree is failure. Too many decisions were actually never made. A key example I came across early was the big bet in Longhorn on Avalon (what became Windows Presentation Foundation.) WPF was shelved for a future release, but development continued. Yet at the same time to ship Vista the use of WPF (or its precursor, managed code from the .NET framework) were specifically precluded from shipping in Vista. In other words, on the one hand a big bet did not pay off and was effectively put on hold yet on the other hand it was banned from inclusion in the product. This was a prime example of the kind of non-decision that was made at a time when the team desperately wanted and needed clarity. It would be only a matter of time until the Avalon team would just assume they would be part of Windows again and yet the whole Windows team that was shipping was making sure to never use the technology. Agree to disagree was a huge failure point.

Agile Execution

No topic caused me more personal grief and angst than the phrase agile execution. The concept of agile execution—seemingly a religion with terms like scrum, sprints, and stand-ups, as well as development process approaches that put experimentation on customers above all other methods—was top of mind on the Services teams. The team believed that the only way of addressing the poor results they were seeing was to move faster and become more agile. And while they were focused on this new methodology, the Vista team was gummed up unable to do things but somewhat irrationally believed that their problem was not taking enough time to get things done. The key leaders in Windows believed the problem with Longhorn was that the team was not given enough time, enough time to complete WinFS, Avalon, or other key initiatives.

The Services view was consistently expressed as “delivering internet services is entirely different than releasing boxed software.” The use of “boxed” was always meant as an insult specifically aimed at me, even if occasionally said with a neutral tone. The implication was old, easy, and irrelevant. A key aspect I was informed about repeatedly was: “Services do not use the waterfall approach, but rather they must iterate in the market.” Waterfall was another code word for old and dumb.

The problem with describing Office (or Windows) as waterfall was (and is) that this presumed a development process of writing specification and handing off to development and then later to testing—a sequence of discrete steps known as a waterfall. Implied was that there was never any notion of reevaluating what was going on, iteration, or that no work was done in parallel. Also implied was a perceived timeline of years. This was not how Office worked, but there was no chance I would change the minds of those arguing for agile. Whatever Office did, it was not agile, and the proof was that a product took 24 to 36 months. Still, Office iterated throughout the milestone process and also updated the product with hundreds of changes every month, and those were based on data of how the product was being used in the real world. But that was only evidence of maintenance not innovation, even though the vast majority of Services updates were simply to keep the services running and not new features—roughly equivalent in my book. There was little evidence of innovation in Services to counter this example.

As an aside, the concept of waterfall development has been misunderstood for generations. The first description of the process came from Dr. Winston Royce and appeared in the Proceedings of IEEE WESCON from 1970 in an article "Managing the Development of Large Software Systems.” Royce diagramed out what became the canonical waterfall process of gathering requirements, analysis, program design, coding, testing, and so forth. One discrete step after another. Royce, however unfortunate for us all, meant for that diagram to be what not to do. In the full text, he explained how critical it was to iterate at each step to be successful. Yet because of that diagram generations of engineers treated the process as a stepwise and discrete, one after another. Also, maybe IBM was to blame too.  Nevertheless, many on the Services and Windows teams perceived the Office planning process, including a vision document and milestones, as a waterfall approach in the classic and incorrect manner.

What I had learned as I gathered information ahead of writing my memo was that our use of these new agile methods was causing multiple real execution challenges. One example was the Spaces service, which was poorly architected for scale while racing to put features into market to compete with MySpace. In fact, they were asking me (the new person) for budget approval for a lot more data center spend because the costs per user on the free service continued to rise significantly and non-linearly—that is, each new user being added to Spaces was costing more than previous users. Clearly, that was unsustainable.

The most shocking example of management by self-induced crisis was Internet Explorer. In many ways IE was the symbol of a rapidly developed product, participating in the creation of “Internet Time” as it competed with Netscape 1995-1999. Once the original Longhorn plan started in 2000 to 2001, development on Internet Explorer was, for all practical purposes, shut down. In my first days on the job, I met with the recently reconstituted IE team who had been given a “hurry up and get a release done for Vista mission.” A recognition that Vista needed a browser as part of the Longhorn Reset.

Internet Explorer 6 shipped with Windows XP in August of 2001. Here we were, almost five years later, and while there was a great deal of activity in terms of security fixes and supporting the myriad of Windows releases, nothing substantial in terms of product features was released. Ironically, perhaps, the intention in 2003 was to stop releasing standalone browsers to focus on integrating and synchronizing the browser with Windows. IE had effectively ceded the browser war to Firefox (Google’s Chrome was two years away, but there were rumors of its development). IE was riddled with security holes due to the use of Microsoft’s ActiveX technology and components which were not architected for the modern security landscape, while also falling behind on performance and web standards. IE had become a pariah on the internet and attracted scorn from the developer community. Realizing this, a crisis was created by the very people who ended development and essentially commanded an updated browser in time for Windows Vista. This amounted to a classic arsonist-firefighter dynamic within a culture that always seemed to love a good crisis.

The good news, if there was any, was that Dean Hachamovitch (DHach, former Word and Office PM of AutoCorrect fame) was leading the new team, reconstituted from across the company. In the first meeting I had with the team, all the managers fit into one small conference room. The team was woefully understaffed for the work it needed to do. This was nine months before the product was to be completed. Dean was already exhausted, but we found ourselves allies. In talking about IE with BillG, SteveB, and KevinJo, the irony was not lost—voluntarily ending work on browsing after a fairly well-known legal battle was an odd choice, to say the least, and one I did not spend time trying to understand.

There was also the idea that planning and being thoughtful were archaic and the modern way of building products was via lean methods, as they became known—get an experiment or something “minimally viable” to market and then iterate. Though by this time, the biggest successes of these agile methods had also mostly imploded as companies. On the other hand, most people were consistently surprised at how long even relatively thin-featured products gestated before becoming viable and then successful. Managing every product like it might be the next Google search made no more sense than managing every product like it was a NASA mission. There was a rational approach in between, especially for products that were mature or necessarily focused on enterprise customers.

This issue as I would later discover was one that none of my new management receiving this memo would quite know what to make of. The conversation would come back to needing a plan and me returning to the reality that the team hadn’t ever developed and executed on a plan. That meant there was more needed than a slide deck with a set of features and a schedule, all while needing to find a way to agree to the highest level of development methodology.

It also meant that the odd-even curse around Windows might have been due at least in part to a lack of patience, and that regardless of my plan the team might not have the patience to see it through.

While on a recruiting trip I caught up with Sarah Leary (SarahL), the product manager who represented Office at the Windows 95 launch event. Sarah invited me to attend her class at Harvard Business School in 1998. Professor Marco Iansiti taught his classic case study on the development of Microsoft Word—the one where the Word team was called the worst development team at Microsoft by my future manager JeffH. Marco and I got talking and he invited me to spend the fall of 1998 helping to teach that very class with his colleague Stefan Thomke, which proved to be an incredible learning experience for me.

Marco later helped us to articulate our aspiration for agility as defined by Agility = Execution + Impact. This was a way to talk about three challenges all at once without having to define what agility really meant or even that it meant fast or, worse, faster. By focusing on execution, I was able make clear the issues of simply failing to get things done, like MSN Messenger working correctly for people with more than one PC or big features of Vista that were cut. With the addition of impact, I would discuss the issues of the Services team spinning their wheels while not making any strategic progress. This definition also helped me to avoid picking a specific development methodology which was about as appealing as choosing to become ISO 9000 certified (that’s a joke a few people will get.) Instead, we would focus on planning, plans, and timelines using my favorite methodology of “promise and deliver.”

To put a time scale on agility in my memo, I pointed back to ChrisP’s Shipping Software mantra (Chris was my manager in Office and had joined Microsoft to work on Mouse 1.0, Windows 1.0, Word 1.0, and also led Excel engineering, then Word, before leading Office.) I said we would aspire to a milestone-driven process, with more than one milestone, and a process to plan, execute, reevaluate, and iterate. I had a great deal of difficulty bridging my experience in product cycles lasting years with the perception of needing to last days, no matter how much we talked about how processes can scale while the absence of a process is still a process, known as chaos.

Across all teams there existed a cacophony of agile development that was defined as a cultural high-order bit. In many years of working with teams as they moved into Office or were aligned with Office, my experience was that there was some degree of correlation between teams executing poorly and a very specific development and engineering process that the team was overly proud of developing. Such a process was one the team pioneered and was deeply committed to, even to the exclusion of success. This wasn’t a causal relationship, but rather a correlation often seen. Certainly, teams with a unique methodology also executed super well, but that probably wasn’t causal though they believed it was.

The challenge, or properly my baggage (Office worked differently than Windows), was much more acute when speaking with the Windows teams. Windows felt they were not moving fast enough, but after six years of Vista the more general view was that they were not given enough time. This was rooted in the way that Windows NT was developed, with architects and a lot of upfront design (in practice, much closer to a historic waterfall approach). The project, which started approximately in 1989, was not ready for mainstream usage until almost 2000. And to many on the team, a decade was the expected amount of time needed to build robust platforms at scale.

The Windows team had a belief that Office shipped releases mostly on time by “cheating” because it cut features from the product before it shipped. PaulMa (pioneering manager of Windows, including NT, and former CEO of VMWare) often told me, “You just can’t cut things from Windows like you can in Office.” In any discussions about Office processes, I always felt a bit of OS snobbery directed at me. While this could have been my own inferiority complex, there always seemed to be that unsaid feeling that Office was the simpler product.

For what it’s worth, back in the day, Office people always thought that Windows was a perfectly good product to have in order to launch Excel and Word, but not much else. This was reinforced externally because Office on the Mac operating system was equally loved. We had our own expression of snobbery in Office.

The two gardens continued to exist.

There was another truth that emerged as I researched and tried to sell my plan. There was overall perception of Office, and by consequence me: aside from cheating by cutting features, I was confronted with the perception that I was a tyrant, literally. The reason Office shipped on time and was so structured was because of how I ruled the team—by terror or by some sort of iron-clad grip on process. The more I talked to people the more I learned of what I thought were crazy stories about how the teams worked, and how I worked—hearing them was like learning about some exotic culture across a vast ocean, not just another part of Microsoft. Not my Microsoft.

It was the first time I had to face the perceptions people had of me personally but also had to reconcile how those perceptions could be so opposite of my reality. At times the disconnect between perception and self-awareness had me questioning my sanity. I understood how I could be intimidating just as any executive could be, but at the same time I felt the team knew I was fully supporting them and worked hard to avoid the trappings that contributed to that perspective.

It was, after all, Windows where the manager punched his fist through a wall. It was Windows where people (including me) were regularly chastised in front of big war-room meetings. It was Windows where managers often found out about changes to their schedule or plans via rumors or indirectly. I did none of those things. I didn’t yell. I didn’t skip over managers. I didn’t escalate decisions (or tolerate escalation). Generally, my biggest offense was writing lengthy emails late at night with too many points in them, and sure, an occasional barb, though I rarely replied-all and did my very best to focus on ideas and products, not individuals in emails. That and refusing to go to endless meetings, especially early in the morning or when they were scheduled at the last minute were where I regularly messed up. Besides, how could anyone hold a crisis meeting for a strategic discussion?

Whatever my flaws as a manager, what I thought was going on was that the Windows team was looking at how they worked and assuming that to achieve the results that Office achieved it must be doing what Windows did but just more, or better. So, more escalation, more big meetings, more VP decisions along with better PowerPoints and shorter lists of non-goals (or is that longer?)

That wasn’t reality. But it was the reality I had to deal with, as out of body as it felt.

In hindsight I began to realize that the two gardens were not styles but deeply held beliefs. Each of Windows and Office operated the way they operated, and loved it. Each had achieved tremendous success in the market. Where I thought Windows achieved success in spite of how they operated, they saw their success as because of it, and vice versa. It just so happened that the most visible cultural differences were also almost the opposites: planning versus crisis, consensus versus singular leader, cult of team versus cult of leader, promise and deliver versus over-promise and deliver, and on and on. Even today, it can be challenging to describe the gardens without sounding judgmental one way or another.

Top of mind during this transition were some of the more legendary efforts at cross-pollination between Windows and Office. Several extremely talented and senior people in Office had taken roles in Windows only to quickly return to Office sharing tales of their adventures. And while there were stories in the other direction, it often felt like we had more success with Windows people moving to Office. From the outset, I was deeply worried about that sort of rejection knowing I had nowhere to go back to.

Our aspiration, Agility = Execution + Impact.

Discipline Excellence

Despite having thousands of engineers with more seniority (as defined by salary level) than any other engineering team in the company, the team did not have the depth or breadth of talent (human capital) to build products of the scale being attempted. Sharing this observation was scary. It was both counterintuitive in thinking and felt like the height of arrogance. To BillG who valued IQ above all and prided himself personally on the IQ assembled to build Windows, to express this was, for lack of a better word, insulting.

I used data to explain it.

Something PeteH once explained to me: “You can’t build a billion-dollar business out of 10 products each doing $100 million dollars.” What he meant was that the characteristics of a billion-dollar business are different than a collection of smaller businesses (he was referring to the struggles Microsoft was having in the Microsoft Home division). That pertained to my challenge at hand: we couldn’t create a product team at scale for billions in revenue with 100 teams of 25 people each. A 2,500-person product team operating in unison was qualitatively different than all those small teams added together, even if headcount was the same. Even worse, it was almost always the case that the bulk of the value delivered was due to a small number of those teams anyway, leaving most of the teams work essentially unaccountable or even squandered.

Windows was sold and experienced as one product, but it was organized as though 100 small teams came together to create that product while operating essentially independently. What was supposed to make Windows be Windows was how all the pieces fit together. There was no organization, however, to build that product. Simply put, the whole was not greater than the sum of the parts.

The driving force behind all the small teams was to empower people to work outside the complexities of the bigger team. The team had found itself caught in a negative reinforcing cycle. It was too difficult to get things done because processes were failing, which caused management to assign senior leaders to work out of band or off the books to get truly important things done (translation: make it a crisis), which made it harder to integrate those into the product and amplifying the overall difficulty of shipping the whole of Windows. The empowerment led to poorly integrated and architected products such as Media Center and Tablet PC, as well as disconnected core architectures such as DirectX graphics, Networking, and Security. The success of early Internet Explorer working this way reinforced this as a methodology, but all that came to a standstill once the goal of the product was to integrate it with a whole.

That would be challenge enough, but accelerating this cycle was the existing approach to managing. In order to conjure up these small, agile teams, management pulled people from the ranks and gave them responsibility for managing a team of developers, testers, and program managers—creating product unit managers, PUMs, or multidisciplinary managers, MDMs (the HR expression). PUMs were a direct manifestation of the old list of people and problems, formalized to an org structure.

For a culture that loved a good crisis, the heroics of being a PUM managing a crisis became an aspirational job. As I was making the rounds talking with middle managers before writing the memo, a frequent topic raised was the desire to become a PUM, and my view of the career path to become a PUM in my new world. When speaking with PUMs, I heard time and time again, “I work best overseeing a small, multidisciplinary team.” The problem was the lack of supporting evidence proving that point. Being a PUM was a career goal for nearly every mid-level engineer, not being a great engineer.

A direct result of pulling people from the ranks and promoting them to manage multidisciplinary teams was to cut off the pipeline of talented engineers and, more specifically, program managers. The very people who would be called upon to scale and manage larger teams of engineering leaders were robbed of the depth of discipline expertise that would train them to do so.

As if this wasn’t enough, these new leaders were then responsible for hiring, mentoring, and growing the next generation of leaders in job functions they had not even done at any level of seniority or tenure. As a result, most of these teams had a management structure where the PUM was also filling the role as development manager or group program manager (the titles for the role of leading the job function). This further stunted the development of new leaders.

To illustrate this point, I compiled the statistics of the approximately 40 product units in the Windows and Services group (not including COSD, but the numbers matched almost identically). It revealed that half of the product units were being led by people who would not have been senior enough to be discipline leaders (dev managers, test managers, or group program managers) in Office.

The lack of seniority was immediately recognizable in program management, arguably the most crucial role for achieving synergy in product design and features across a single product. Overall though, Windows had more senior employees than Office, but they were allocated to pure management roles, PUMs.

The quest for PUMs and autonomy had pushed all the relatively senior talent to be managers of managers (or their managers). That was a shocking realization. This was also a generational problem because the presence of PUMs robbed the junior engineers of opportunity. The Windows team had been robbed of a generation of talent development.

Perhaps nothing was more shocking than the Software Test discipline, where, once again, I was up against a long-held belief, by BillG and SteveB in particular, that having testers was not a sign of success but somehow represented a failure of tools and processes in engineering. For many years, I tried to have this debate or discussion but simply ran out of ways to sound anything but defensive. But in truth: there was no engineering or manufacturing, in any field, without the role of quality assurance, and the more complex a product the more testing it needed. Software projects brought with them two unique characteristics not seen in hardware or manufacturing. First, Windows for the most part provided programming interfaces to developers who would do all sorts of things, some expected but most not. Testers came to work and found ways to exercise APIs by writing adversarial code against them. Second, every release of Windows shipped supporting every previous release and previous capability on all the hardware that existed and all the hardware that would exist. Of course, Windows had enormous libraries of automated tests and more being added all the time, but all they could do was tell you that you had not broken something that already worked the way you thought it should work. There is much more to testing. I understood that start-ups and smaller projects could do without testing, as Microsoft had in the early days, but complexity, extensibility, and backward compatibility caught up to every product.

Later, when I made my case after sending the memo, I experienced a lot of friction on the topic of testing because SteveB as CEO had been pushing teams to reduce headcount as a cost-saving measure. Both Services and Windows had reduced headcount by reducing testing and moving responsibility offshore or to vendors. The Services team, where there would normally be one tester for every software developer, had half as many. As we learned in operating internet services in Office, testing wasn’t reduced but rather shifted to and shared with operations, which was also understaffed.

Tactically, our plan was to aim for two important structural changes. First, we would dramatically reduce the height or depth of the organization. This was something that SteveB would get excited about as he had been trying to get people to understand Jack Welch’s General Electric approach to org span of control and depth (at this time, everything Jack Welch said was undisputed business canon). SteveB had run up against PUMs and the depth and minimal span of control that model imposed on an organization. This would dramatically alter the jobs and career paths of dozens of the most senior people on the team. It would be a very expensive change to undergo.

Second, I proposed reducing the number of pure managers, those with no line of responsibility but who had management oversight. They did not write code, specs, or tests but focused on the process. Some were needed, but the organization had too many, which contrasted with Office where even the most senior discipline leaders were managing people and writing code and/or fixing bugs.

At the strategic level I used this memo to begin what I knew would be the most important management journey of my career: restructuring the Windows and Services team into a functional or discipline-led organization.

A reality I could count on was that it seemed nothing could have messed up the Windows business, and hence all of Microsoft’s revenue and profit, at that point. In hindsight, what Windows had was the greatest product-market fit in the 20th century, except maybe for oil. That stability enabled the company to thrive during macro issues of recessions and wars. It thrived throughout the largest antitrust trial in our lifetimes. It thrived through successive changes in leadership and company reorganizations. It thrived through a restructuring of the PC manufacturing industry. More than anything, it thrived despite products receiving lukewarm reviews at best and a lot of releases being broadly panned, and nearly every single product being released to market years later than planned with notable quality issues.

Windows had no trouble surviving the odd-even nature of flawed products and changing leaders. To date, there had been no credible competitors or alternatives.

As I write this today, I realize just how wild that sounds. It was, however, true.

In one exercise, my colleague Adrianna Burrows at our communications firm WaggEd researched key product reviews for all the Windows releases going back to Windows 3.0. Surprisingly, out of that selection, while some were glowing (Windows 3.0 and Windows 95) most were lukewarm to good (Windows 3.1/3.11 and Windows XP), and many were quite painful to read (Windows 98 and Windows Me). Windows Vista was shaping up for reviews akin to the latter. Looking back on the reviews solidified my opinion that there was much more of a Windows challenge than a Vista-only challenge. The business model and momentum were sustaining the product, not the march of consistently improving products and increasing customer satisfaction. At one point, I even suggested to SteveB that Microsoft would have been fine not shipping several of the Windows releases. Heresy. To be fair, in Hardcore Software I have pointed out that absent the contractual obligations and staggered adoption of Office, it is not entirely clear the same would not be said of Windows.

While I did not have the vocabulary of product-market fit, I knew that I had the luxury of being patient and deliberate. SteveB showed restraint, even though every bone in his body wanted something fast. I was not going to rush. I was not going to have a short-term tactical plan to show we were awake or listening—something that had been suggested many times by those more senior than me and in subsidiaries. I knew we would spend a lot of time in push-pull conversations, but ultimately, I believed I had the support to do what I thought needed to get done.

The goal was to have the whole organization collectively, including COSD, deliver one Windows product to customers, OEMs, and enterprise/business customers. The cardinal rule of having everyone finish at the same time was to have everyone start at the same time. But with the Windows team still finishing and also about to undergo a major organization change, I needed to develop a hybrid approach. This would also remove some of the pressure at the company level to show progress or, worse, to make sure we did not look like a few thousand engineers were going into hiding.

In this transition memo, sent to BillG, SteveB, and KevinJo (which I sent when Vista was still six months from shipping), I proposed an entirely new organization and a rationale for why we were going to operate together as one.

On to 087. Reorg! Why Are We Together, Exactly?

Everyone in their career should have one memo that they think of as the most consequential. For me, it is a memo I wrote after a about six weeks on the Windows team. Under intense time pressure to figure out what comes next with Vista rapidly approaching final release (not formally, but it was going to soon be all but impossible for code changes to make their way into the product) I had to come up with next steps. Over the next four posts, I want to share not just the memo but more about what it is like to live through a major organizational crisis and work to set things up for building a new engineering culture and new team structure, all in a couple of months.

Back to 084. How Many On the Team, Exactly?

The history of Windows releases was cursed when it came to product and leadership. Like Star Trek movies, Windows releases alternated between good and bad, odd and even. Line up the OEM products by availability date, and you’ll see this is basically true—starting at Windows 3.0 and changing to the NT kernel with XP (3.0, 3.1, 95, 98, 98 SE, Me, XP, Vista.) Compounding this, the curse says, no leader seemed to last more than two major releases of Windows.

My neighbor, a successful biotech entrepreneur, asked me about the curse the day he read the org announcement in The Wall Street Journal story saying that I was moving to Windows. He wished me luck.

After 140 scheduled 1:1s, 20 team Q&A sessions, over 30 hours of office hours, and countless hallway conversations in a dozen different buildings I had to do some thinking and organize what I observed, heard, and learned. That meant writing.

A dose of reality was needed with BillG, KevinJo, SteveB, and to some degree even the Board.

I did that with a 20-page memo titled Observations, Aspirations, and Directions for Windows and Windows Live. For me writing is thinking and I really had a lot to think about, hoping others would join in. I felt alone for long enough and I was certain SteveB was growing increasingly anxious for what would come next. I had been talking to KevinJo constantly over the past few weeks as he was doing a huge amount assuaging those that essentially rejected the idea of an Office person leading Windows.

The 20 pages were the most difficult I wrote in my entire career—to literally put these words down—I knew they would be impossibly difficult to read. I was deeply concerned that what I wrote would be viewed through the simple lens of setting expectations or painting as bleak a picture as possible so that I could be a hero later.

It seemed that everyone, especially SteveB, wanted the plan for getting things back on track and a product roadmap. He also wanted to be able to communicate to the field and bring comfort to customers, while continuing to support Vista when it shipped. Bill was especially keen to restart discussions over product investments that had been cut since the Longhorn reset. Kevin was getting his footing across wildly disparate businesses including the massive money-losing online services.

I couldn’t kid myself, however, as I too needed a plan. The team was still frantically fixing bugs, but in order to ship by October that would soon end. The bar for fixing bugs would rise dramatically by summer. Idle hands will make trouble for sure. Projects will start, code will be opened up to changes, and worse presumptive commitments to outside customers and partners would be made, and so on (all business as usual for Windows.) For there to be a release that addresses any challenges I would need to orchestrate that every team at a project arrive at the starting line at the same time in order to finish at the same time. In other words, I had only about four months and one shot to get all this figured out.

Adding to the stress, the OEMs were extremely anxious as they were reeling from Vista missing both back to school and holiday selling seasons. They were used to hearing plans, or at least slide decks, about future releases so they too could plan, as much as that was worth. A January launch was painful for PC makers as it meant they had to stock up retail outlets with PCs unsure if the buzz over a new OS release would dampen Holiday sales or not, and then deal with upgrades new customers demanded on those PCs. It was messy.

In round numbers, fiscal year 2005 had revenue of about $40 billion and net income of about $15 billion. The Windows OEM business on its own was $12.2 billion (about 30% of Microsoft—incidentally it is not possible using public data to compare these to today’s Microsoft, much as people claim to) and $9.4B in net income (about 63% of all of Microsoft). OEM revenue was highly concentrated in six major and global PC makers, each CEO with a direct line to SteveB and KevinJo.

My memo solved for none of these immediate issues. Instead, it was a lot of bad news and, in contrast to conventional wisdom or expectations, was less about strategy as it was about execution and culture. It diagnosed, without blame, the situation as I saw it. I provided a ton of data about the organization. I detailed structural problems that I was worried would feel trivial up the management chain. It was a lot of work to count the number of people and find out how much money was being spent (on projects, not salary). It was disappointing that for all of the staff and managers, the most basic controls over dollars and headcount were not in place.

Something BrianV once told me really stuck in my head years earlier. In his inimitable way he reminded me, “There’s just a lot of s**t going on in Windows all the time.”

I was fast learning he meant that in every way possible.

There’s an old business story usually called “The Three Envelopes” about an incoming executive taking over a dysfunctional team. The outgoing exec offers advice to the successor in the form of three envelopes, with instructions saying, “when things get tough, open them one at a time.”

After a bit of time, things indeed got tough. The new exec opens the first envelope. It says, “blame your predecessor.” They do and it buys some time. A bit more time passes, and things take a turn for the worse, so the second envelope is opened. It says, “plan a reorganization” which improves things. Some more time passes and desperate for help, the third envelope is opened. This envelope reads, “prepare three envelopes.”

Good grief, I thought. I felt like I’d become the punchline to a business joke.

I promised myself I would never blame my predecessor and never ever did. I went out of my way to avoid that not only myself, but to remind people not to do the same. There was no escaping we were going to enter some new era as a team, hopefully for the better, but I was not going to permit our time to be defined as positive compared to a blame-worthy negative.

I was troubled, however, because I knew we were going to reorg. I really thought I could get through this change without becoming a living cliché, but as I quickly realized sometimes a cliché is born out of countless experiences. As it turns out, most of the time to fix a dysfunctional team there’s going to be at least changes in leadership if not structure. With so many of the leaders choosing to make Vista their final release of Windows, I would need to hire replacements, so why not new jobs? The memo was a precursor to much larger changes and designed to motivate those changes with facts, not blame. Unlike most reactionary reorgs I had seen (at Microsoft and elsewhere) it was also not based on swinging a business pendulum in the other direction as is often the case.

I continued to be concerned there was a perception that if we could just get a good strategy deck then my job would be to do what I do, which was to be a tyrant—take the new strategy and execute. The strategy wasn’t there, nor would it be, but I viewed that as a third-order problem. Besides, strategy without a product plan isn’t really a strategy. As the saying goes, “culture eats strategy for breakfast” (often wrongly attributed to guru Peter Drucker.) I was under no illusion that the current team and structure presented with even a perfect product strategy could execute it.

The engineering culture was broken.

In fact, over the previous few years, while SteveB had been increasingly leading the company, he embarked upon initiatives that presumed execution was the key problem to address. Key among those was an updated performance review system based on “commitments.” Everyone was required to document their commitments (goals, tasks) and share them up and down the management chain for review and approval. On some level this is a solid approach, and in start-ups the concept often works well (such as the well-known OKR process used at Google). At scale, however, this type of process too often devolved into people gaming the system with vague commitments or aiming to set low expectations. I was not a fan. That wasn’t going to help this team.

There was a special difficulty in diagnosing and sharing execution and management problems with two people who basically never had managers, BillG and SteveB. KevinJo, on the other hand, was an expert in scale management and a true ally in this regard. In fact, he had clearly orchestrated many more people than I ever had. Adding to the degree of difficulty was to what extent they would, especially Bill, take my assessment personally. I was quite concerned that I would come across as way off base on what needed to change, and even more concerned that this would not go well. Perhaps worse, they would think I was blaming their leadership and JimAll’s as well.

I was having flashbacks to a mismatched conversation with SteveB about Windows Phone leadership (c. 2000) and what was needed back when Steve was looking to change phone leadership for the third time in as many years. He ended up talking to several other product leaders, each of us saying essentially the same thing—the phone needed a full reboot, in the team, business, and code, to compete with (then leader) BlackBerry. There was a mismatch that continued for quite some time.

Avoiding an early product strategy discussion was important. The easiest thing for execs to do in time of crisis is debate the specifics of product features. In those discussions, there’s a strong desire for a silver bullet—one change, one addition, one synergistic initiative, or one deal—and then to ignore all realities and externalities and rush execute that. We were in the midst of the Vista project which itself was designed around both synergy and silver bullet features, such as WinFS and Avalon.

Above all, this would all be extraordinarily difficult for me because I’d been either watching or participating in this brewing problem for most of my career. I had come into this role not thinking there was a Vista crisis but thinking there was a Windows crisis, years in the making, with Vista merely the latest symptom. It was not just the odd-even curse of releases but the challenges we had collaborating because of the differing methodologies of the two gardens, which was difficult in the best of times. Not only would I have to break free of my own prejudice, but any visible display of prejudice would immediately snowball into a horrible situation that would be perceived as something of a hostile takeover of Windows by Office. Given that Office was always viewed as the subservient business and technology, this was not acceptable.

The risk of being rejected outright by the Windows team was very real, much more so than the external view of the savior arriving.

Working to my advantage were the ever-present “quality of life” challenges the team faced. Most every discussion—1:1, team meeting, or small group—was much more about the way work was done rather than what work was done. There was a deep-seated victim complex, and the perpetrators were management at every level and some specific managers/execs. I abstracted these concerns to what I considered three relatively mundane concepts, the kind found in any management book, and illustrated them for BillG, SteveB, and KevinJo with some concrete and dramatic numbers. The details on the Services teams were decidedly different from Windows, though the issues were largely the same. In fact, the challenges were identical, just manifested differently owing to the delivery of code and business model more than anything.

While I diagnosed three main areas to work on, areas that would motivate the proposed changes I was going to make, I spent almost five pages on a situation analysis. Writing about the way I saw things at the time I shared some of the following (summarizing from the original):

Engineering Skill. Windows has the industry leaders in PC technology, having invented much of it. In industry technologies ranging from Wi-Fi, USB, printing to Microsoft’s own technologies such as Hyper-V or DirectX, the team has unmatched and extraordinary technical depth. Translating that depth into high-performance, secure, robust, production code has been challenging. The Longhorn project showed a great deal of technology potential but across the main initiatives there was a broad inability at every level to turn that into products.

Fatigue. The Online Services team has been running non-stop for years, releasing every month and spawning new projects, but with little in the way of product success or share gains to show. The recent financial results causing a pullback on headcount growth have really left the team shattered. The Windows team is on year 5, though optimistically it is only year three since the reset. The recent schedule change all but cancelled summer and the holiday season for most of the team. The team is fried.

Maturity. There is a decided lack of subtlety or nuance in how the team approaches problems. By and large even the most senior people think and act locally, almost in survival mode. In discussing the situation with senior people, they invariably jump to unsophisticated solutions such as cancelling projects or putting groups under a single manager. The idea of being both fiscally responsible and investment minded is difficult for most to grok.

Bloat. The organization is bloated with middle management. There are too many multi-disciplinary managers (PUMs) which (as will be discussed) create a deficit of senior engineering leaders. This creates an absurd engineering structure where small groups flail on problems too big to solve, escalating to a PUM who has the sole motivation to keep the decision local for fear of losing control while lacking the personal experience to adjudicate the issue. This bloat also caps the ability of the organization to grow senior engineers.

Science Projects. The organization is filled with science projects. These are projects operating as though they are building product features, but they have little chance of achieving critical mass and an even smaller chance of remaining sustainable over time, if they ship at all. One way to view this is how cool it is to be exploratory and entrepreneurial. The vocabulary used to describe these is always “delivering value to customers” which is far from the reality. These continue despite the broad view of a resource crunch.

Hiring. The lack of deep excellence in senior leadership for development, testing, and program management creates a difficult hiring situation. There exists a highly distributed hiring decision process and a large number of open heads. This pressures relatively junior people who are under the gun to deliver to onboard any “warm bodies” they can find and in doing so these hires are often over-leveled or over-compensated, creating a down-stream fairness problem for the whole organization. The PUM model often drives poor calibration for promotions simply because the PUM sees people only through the lens of a tiny team they are trying to hold together.

Competitive Fire. There is a curious lack of competitive fire relative to Macintosh, Linux, Google, and Yahoo. There is a broad and vibrant spirit around the concepts of providing software that competes with these companies, but a clear lack of understanding of how what we build stacks up and what we are doing about it. For the most part this shows as an organizational challenge since everyone thinks to be competitive everything must be under one person and nothing is today. This was particularly odd as I was already running Linux at home long before this job and posting unboxing videos of the iMac to YouTube. I saw few Macs, iPods, or Linux boxes anywhere. In fact, the team was even lobbying to prevent the use of Google search at Microsoft’s firewall. Everyone is aware of these but thinks competing is the job of a mythical compete team or belongs in a compete lab, not just in daily use. This is not just at the top level, but at every subsystem where the technologists are not aware of how competitive platforms support an industry standard technology.

Bureaucracy. The engineering process is loaded with universally accepted yet loathed and mindless bureaucracy. For Windows, the processes pushed down to teams in the name of security, builds, quality, etc. are not yielding the results but forcing people to spend creative energy working around those processes hoping to get something done. In Services, thought and judgment have been replaced by a Rube Goldberg set of key performance indicators that themselves would make for a case study in how to make sure things don’t get done. Even the most basic corporate administration work from finance, to legal, to administrative assistants seem over-staffed relative to headcount. Here again the tiny teams headed by a PUM create excess overhead.

I was rather reluctant to share the above. I recognize just how harsh and potentially insolent these statements were. Any one of them could be taken out of context as too broad an indictment of too many or worse about specific people. For each I could offer specific examples if called to, but I so much wanted to avoid this becoming personal. I saved specific callouts for things that were clearly going well or simply stood out relative to these themes.

This was a brutal list. I remember meeting with BillG and seeing his felt pen markup, his callouts, all over this section of the printed memo—and we debated many points he did not agree with. SteveB was deeply in touch with the management challenges, and his unusually silent agreement spoke volumes as I felt he was disappointed to see these findings while also relieved, in a sense, that someone was willing to diagnose and address them directly.

The bulk of the memo documented three areas in need of attention: decision-making, agile execution, and discipline excellence. I presented a situation analysis with supporting facts and data. To avoid being super negative, I also suggested what our aspirations would be for each of these attributes.

Initially, these felt rather anodyne but soon became rather crisp talking points for what amounted to my stump speech as I began to engage a very small set of people such as Ray Ozzie (ROzzie, now CSA) and Dave Marquardt (member of the Board). I perceived a consistent feeling of uncertainty over what to do with my assessment. The questions were much more about what to do—when WinFS would get done, or what should we tell the OEMs. In KevinJo’s case, he simply agreed and said we need to just keep moving and asked how he could help. He was so supportive.

Decision-making was the first topic to address. Windows was an organization that loved decisions. They loved having decision-making meetings. BillG and SteveB were always meeting with the team on important decisions. What could I possibly mean by decision-making and what should the team aspire to?

On to 086. The Memo (Part 2)

Much of what Hardcore Software has been about was what we were building (and why). This chapter is about how. Specifically, I wanted to delve into the management structure and what we worked through to restore efficacy and build a new kind of Windows team. Over the next few posts, we will journey through understanding of the cultural challenges the team faced, figuring out a plan to lay the foundation to address those, and then putting that plan into action. This first post gets to the core of understanding what precisely the team is building by figuring out how many people work on what projects. That should be simple, no?

Back to 083. Living the Odd-Even Curse [Ch. XII]

When you move into a new job there are a lot of things that need to come first, too many. You want to touch base with the most critical individuals, but don’t want to minimize the importance of those less so. You want to focus on the high priority areas of work, but it is times like this that the lower priority work hardly needs to be reminded of that fact. You’re dying to ask a lot of questions, but people are dying to tell you things. Then there’s the political reality that the many things pushed to you or that arrive in your inbox are often those least needing your attention, but most likely to notice a lack of attention.

I had all this to think about while both being reminded of Windows Vista every day and needing to let the team in place finish the project without interference, inadvertent or otherwise.

It was extremely weird to commit myself to learning about Windows and the Windows team. I had, after all, essentially grown up around it, just not in it. I knew the Windows product. I knew the Windows people. I just had no idea how the people made the product. I knew the organization at a super granular level from Windows 3.x and Windows 95 working on toolbars and app compat and the shell from C++ and Office. I knew things at a strategic and executive level.

I had a high-altitude view of the organization, and I knew a lot of individuals, but between a few feet off the ground and 50,000 feet above the ground I had a lot to learn.

Little was as it seemed, however, when it came to the details.

There’s a well-known military principle on knowing the difference between lessons and lessons learned, between reading about something and having learned that same thing through the experience of changing how one operates. Any management book will tell you to know the budget and resources on a team and that’s a good lesson. In the Microsoft culture filled with cookie licking, shiny objects, and side projects my most important lesson learned is to actively track how many developers there are and what code are they writing. Every time I was uncertain of what a team was actually building or if a project was real, understanding the number of developers assigned to which code was the most valuable information to have and the most critical to keeping a project on track. I learned that with NetDocs, the Tablet PC, and so many 1990s internet projects long since passed. Everything other than actual working developers is just talk.

Therefore, the first thing I chose to do was to get a handle on the composition of the team. With the help of Kristen Roby Dimlow (KristenD) from HR, one thing became clear: I was in a new world. KristenD was previously our finance partner in Office, coincidentally, and brought with her a refreshing analytical view of the structural challenges I (now we) faced. Kristen began immediately trying to collect the data on who was doing what.

In Office, headcount, resource allocation, and org structure were readily visible and, for the most part, easy to figure out by looking at the company’s online system headtrax. Windows was a different apparatus. While there was a headcount number, what they were working on, for whom they were working, and even their actual physical location, were all less clear, or fuzzy.

In keeping with Windows tradition of reorgs that “split the baby,” or product organizations that were structured such that accountability and ownership were muddled, the job I was given was not as much the “Windows job” as most would at first perceive. This wasn’t a surprise at all to me—I knew what I was getting into. This was the Windows Client team previously described. COSD remained separate as it was already.

To KevinJo and SteveB, accountability was clear, even if the organization structure and people were not. This was typical Microsoft accountability in the 2000s. I was their Windows “guy” and decidedly on the hook to figure out what comes next. Kevin had a huge amount to figure out. He was clear just how much he was hoping I could wrap my brain around with respect to “what comes after Vista?”

Along with the Windows client, there was Internet Explorer and the user facing side of Live services—the split of everything down the middle was alarming when it came to accountability, but just how alarming required more investigation.

The Live services represented a lot of headcount but the revenue numbers did not seem so big to me at the time. By Microsoft Online Services standards there was significant revenue associated with Hotmail and Messenger. Hotmail sold display advertising, perhaps $300-400M worth. The ads were intrusive “right rail” ads that took up the right side of the screen. The running joke was that the most popular ad was for a toe fungus medicine. The team was working hard to try to sell Hotmail Extra Storage, upgrading to 10MB (later 50MB) for $19.95 per year. Google’s Gmail had no ads and essentially free unlimited storage. The unlimited storage was not a gimmick, Google invented a novel “infinite” and reliable storage mechanism enabling the capability. MSN Messenger was selling ads inside the client application (less than Hotmail), also intrusive, though the move to mobile phones and the growing competition from Skype were both problems. In other words, the few hundred million dollars in revenue was not remotely sustainable and at the same time the products were struggling.

Almost an after-thought in all the discussions about me taking this job was the fact that I would also manage the new homegrown Search product, which was recently branded as Live Search. It would not be Bing for another two years. The team was growing rapidly (up to almost 100 engineers) but was still very new and clearly a very distant competitor to Google (with over 10,000 employees). The first beta test of Live Search started just weeks before I joined the team.

Christopher Payne (ChrisPa) was chartered with leading the team. He was the vice president and team founder and had returned to Microsoft to lead many of the MSN Services efforts. In a moment of boldness for a team under a great deal of fiscal pressure, in 2003 he proposed to BillG a massive effort (expensive investment) to build out a search product that would compete with Google. This included maps, instant answers, books, and more. At the time, as crazy as it sounded, Search across all of MSN was a hodge-podge of business development deals and outsourcing—to compete with Google. In his prior time at Microsoft, Christopher (he preferred his full name in spite of the email name) was a product leader on the first versions of the Access database product in Office and some of the early MSN properties (he later went on to run eBay North America and is currently COO of DoorDash).

Over two years or so, the Search team built an extremely credible effort, first releasing at the end of 2004. The team was the first fully organic one at Microsoft, tasked to build scaled cloud services, employ artificial intelligence and machine learning, and create the kind of tools Google had developed to automate and manage tens of thousands of servers in multiple data centers. Many of these pioneering efforts were critical to Microsoft’s cloud data centers over the next decade.

While ChrisPa knew what he needed to do from a product and technology perspective, there were only two things holding the team back. The first was resources. The team needed to spend a lot of money on capital expenses for servers and data centers, as well as hiring more people. Second, the team needed to be given the time to build much more of the product and technology base before being pushed on revenue—they were far behind Google and the complexities of overlaying a new advertising business did not seem prudent at the time. Google was doing about six billion dollars of revenue directly on search that year, doubling year over year. It was already a juggernaut. In 2003 at the exec offsite, Payne said it would “take at least 18 months and $150 million dollars to even enter the race with Google, and that it was critical we own our own search infrastructure.” The first time Christopher and I met (as part of Search and Windows) he told me he needed an additional $1 billion just in capital equipment (data centers) next fiscal year and revenue was not yet a priority.

As I would learn, there was only so much patience above me.

Combined we called all of these “Windows and Windows Live” and my official title was Senior Vice President, Windows and Windows Live or WWL (I was already Senior Vice President of Office, another fact several people pointed to as evidence I was not up to the job.) COSD continued to report to Kevin, though figuring out how to manage and organize it was all part of our ongoing efforts.  That meant the broad view was that there was WWL and COSD, just as before there was Windows Client and COSD. To some this was comforting. To others they were waiting for the other shoe to drop.

To put some numbers on all of this: There were approximately 3,500 full-time R&D employees in over 30 cities around the world for WWL, with about 1,000 software design engineers. In Office, we worked using ratios that would translate to 1,000 software testers and 500 program managers, compared to WWL, which had 750 testers and 600 program managers. We had only a handful of managers to oversee multiple job functions (Office 2007 had about 10), but this organization had more than 40.

COSD was a bit larger with about 4,700 people (in most every country Microsoft did business), but more than 1,500 were part of a major push to move all bug fixes and servicing of old releases of Windows to India. This was a radical out of sight, out of mind move designed for cost-effectiveness, and something we did not do in Office. COSD also had about 1,000 software engineers, but over 680 program managers (and not much user interface!) and about 1,000 software testers (about what one would expect). COSD had another 40 to 50 multidisciplinary managers.

The number of vendors and contractors and open positions in WWL plus COSD product development approached 10,000 people. Yikes. The number of open positions was astonishing, thousands upon thousands. Not only could they never be filled, but the question was also how would they have helped to ship Vista? That couldn’t be more different than what we did in Office.

Perhaps the most surprising data point was that almost one third of the team was managers and there were easily seven, and often up to nine, levels in the management hierarchy. Office was about 20 percent managers and rarely more than five levels of hierarchy domestically. Another measure of complexity in the system was the number of cost centers. In Microsoft lingo, a cost center was a locus of financial controls, budgets, and headcount monitoring. In practice, it was a numeric field in SAP. According to finance the mere existence of a cost center was about $100,000 a year in operational overhead. In actual practice, every cost center was a headache as it was another place someone could come up with unique budgets, costs, and headcount, and when everything was considered for one product release, cost centers became overhead and bureaucracy. Windows had around 300 cost centers. By comparison, Office had about 30, and most of those were needed because people were paid in local currency and a cost center could have only one currency.

Mini-Microsoft was looking more and more accurate. I was beginning to understand why I thought Mini was so off base when I compared what they said about Windows to Office.

I completed an inventory of the products and projects that were underway, and resources assigned. Doing so felt a bit like an excavation. There wasn’t a single place where the allocation was tracked. Finance knew how many dollars were budgeted by cost center which were created to essentially streamline accounting or sometimes to park open headcount. The projects underway were mostly tracked by multi-disciplinary managers (MDM, or PUM for product unit managers). The mapping of projects to products or a roadmap of product releases didn’t exist. Finance had one view of open headcount which had little correlation to the view HR had for recruiting. It was quite chaotic. When asked, managers had a solid idea of what they were doing but that certainty did not roll up in either a strategic or fiscal sense. Compounding this were what I came to call “headcount gymnastics”. In order for one group to rely on a contribution from another, groups engaged in headcount bartering where heads were offered or loaned from one group to another as a way of creating accountability or a reliable contract for work. Absent headcount gymnastics, partnerships or collaboration between teams would be subject to the whims of PUMs. I suppose.

I knew about these gymnastics because more times than I could recall, Office was asked to support something new in Windows and as part of the ask they would provide headcount to get it done. It should be readily apparent as to why this is just not going to work, but when you think about it even for a bit you realize just how absurd such a system is. It basically says that headcount is the tool for changing the priorities of a group. If you don’t want to do something then you don’t want to, and the idea that if you had more headcount then that thing you were asked to do is the thing you’d choose to do next is absurd. That’s on the face of it. There’s the second order problem that headcount is not the same as a human being, a developer. It means the receiving group, the one that signed up to do something it didn’t want to do naturally, has now committed to do that very thing but has no person to get the work done. If one continues to play this out, then you ask all sorts of other questions about what schedule the work would get done on and what would happen if the work required changes to parts of a system that were not open to accepting changes (for a variety of reasons) at that time. I could keep going but it should be clear operationally why this is awful. Yet, this is how almost everything worked.

Let me indulge with a brief view as to just how broken headcount was and how key this was to the whole mess I was now facing. There are some basics of all software projects, among them there is always more that the team wants to get done at any given time than is currently planned and that adding more people once a project starts not only fails to help get more done, but likely will result in less efficacy. There’s a simple corollary to these rules, which is that most every project will end up scaling back work as it progresses to finish on time. Said another way, projects don’t get more done by the end than they said they would get done at the start. These basics go back to the Mythical Man-Month, one of the books issued to every new Microsoft developer going back to the earliest days.

Therefore, the basic way we worked in Office (also for as long as I could remember) was that projects were planned to use the number of people currently in place at the start of the project or milestone (sub-unit of a full release). If you don’t have a human who can start the work, then whatever work was under consideration doesn’t get put on a project plan. Groups that were growing had open heads but did not commit to work based on filling those heads.

This makes it very easy to know what a project is actually going to accomplish because everything without a human assigned to it simply won’t get done. It will only get done the next time the team regroups, builds a new plan, and starts. In the case of Office this took place every milestone (projects had 2 or 3 milestones) and in the large every release.

A big part of how we ran in Office then was to free everyone from ever thinking about headcount, ever. There was really no process to request headcount. We started a project with a known number of people. Every team could hire people to replace attrition. And then every new project cycle we assessed where we wanted to spend resources and increased, decreased, shut down, or created new efforts. Lather, rinse, repeat. We grew the Office organization from 350 to 2,500 over a decade using this deliberate approach, and never had thousands of open heads.

Whenever we wanted to do something entirely new the first step was to create the team by reallocating from our existing teams, in a significant enough way we could execute the whole project just as described above. This is how we created OneNote, SharePoint, InfoPath, and even the original Office Product Unit. By starting new efforts this way, we benefitted from having experienced people volunteering for the new work who were committed to seeing it through and we never went through a period of one manager telling us they are still hiring people to do the work.

Some reading this description would be critical and point out how this lacks agility. They might suggest that this does not allow for flexibility or entrepreneurial thinking. What if a really great idea comes up or a competitor does something requiring a response, people would ask? Easy, change the plan, allocate people to that new thing, and scale back or cancel something else. What if something is much more difficult than originally conceived and there’s no way to get it done without more people? Easy, the team really messed up and either we immediately reallocate from elsewhere on the team or we kill the feature.

Why are all these so “easy” then? Because anything that relies on hiring, onboarding, training, and getting up to speed with people that don’t currently exist has zero chance of getting the work done in conjunction with the rest of the product plan. If the business wants credit for the feature then it is going to want it to finish with a release on some schedule, be incorporated into marketing, and launch. Otherwise, it probably won’t exist for customers anyway.

Were there complaints or grumbling? Of course and primarily along the lines of “we could do so much more” which was hardly specific to any single team.

There’s a certain psychology that takes hold while building out a product plan once execution starts. There are people who always think about “just this one more thing” or “if only we could also do this too.” They fall into the trap of believing that it is always one thing that makes all the difference. That one extra thing. But it is never like that. And on the outside chance it is, then it is far more likely that the whole of the plan was not that great in the first place. That one last thing is never considered in the context of the entire plan, rather it is just in that one moment. That’s the whole flaw with planning by headcount rather than holistic plans based on people that exist, ready to do work.

Ultimately, the key for how we worked in Office was to remove headcount from ongoing discussions. There was never a headcount request or approval process. Everyone was expected, and did, simply work with what they had. The deal from management (at every level) was that we lived with the tradeoffs teams made along the way. Into that process of tradeoffs, we baked in a culture of commitment to partnerships across the organization so we avoided one group prioritizing locally at the expense of other groups depending on previously committed work.

Windows (and Windows Live) had almost the mirror image of this approach. Nearly every team ran with open heads that sometimes approached half their existing team size. It was not just that the team was always hiring (we were always hiring in Office too) but the team was also in a constant state of having no idea what would get done and when. This lack of clarity extended to cross-team collaboration where headcount gymnastics were still not enough to make good on commitments.

It was even a bit more insidious than I just described. As I began talking to teams about what they were planning on releasing, it was almost as though at every step I was running into a manager explaining that they had open heads. I would ask then if the feature was in the plan or not, and they would always say yes. I would follow up, asking when it would be done. The answer was that it depended on when they could hire someone. Yet if someone left the team (in general, Microsoft teams at this time were attriting at 6-8% per year, more so during Longhorn as per the articles in the last section) then the next hires were simply replacements for who had left.

None of this reality slowed teams down from working in a constant state of signing up to do more, requesting and being granted more headcount, and furthering the gap between what was sitting on slide decks as the plan from a team and what code was going to be written and delivered (and when). Meetings with executives (aka me) were viewed through a lens of expansive slide decks and accompanying headcount requests.

The culture of headcount, as I called it, led to a world where people were seemingly rewarded for thinking up big ideas and making the case for more headcount to implement those ideas. It seems entrepreneurial—making a case for an idea and getting resources to build it. Everyone can make a case for resources to get something done, but the question quickly becomes what will actually get done. The process of circling back to those original proposals and checking in didn’t really exist, other than meetings where projects went from expressing goals to expressing “non-goals” or what was no longer in scope. My inbox was filled with these decks offering to get me up to speed, or maybe to approve more headcount.

The flipside of the culture of headcount is just how much bloat it causes. People do get hired on to these teams and the teams eventually grow though never as much as the open headcount (also more headcount keeps getting added as the team expands the charter to do more, at least on paper). The problem is that as soon as people show up they are invariably added to the efforts that have already fallen behind and not scaled back. This is a big part of how the original Outlook and NetDocs projects got to be so large, both of which reached a point where in order to ship headcount was frozen and plans shifted quite a bit. In Systems, this explained the growth of the Cairo project which was ultimately cancelled.

The fiscal tracking systems in place only exacerbated the challenges this process created. The finance team trying to budget expenses gave up accounting by heads and simply tried to use actual dollars being spent on payroll and then literally guessed how many dollars might be spent the next year. In other words, rather than asking executives how many people were on the team, finance maintained a dollar-based Excel model of expenses that had little correlation to all those cost centers and headcount slots. When I would ask managers about their headcount, they would point me to finance who would then tell me a dollar figure for the team’s expenses.

I did not intend to discuss headcount so deeply, but as I was listening to people tell me what was top of mind it literally drove me bonkers. All I wanted to do was make a list of what was planned and who was working on it, but all I could get back were big plans and open headcount. As it would turn out, this was one of the most visible signs that things could be improved and since I knew what to do it gave me a bit of hope when I needed it the most.

This might seem like the talk of a headcount tracking maniac. I am not. In fact, I spent almost no time on this topic until I moved to Windows. As the next sections will describe, we had a massive amount of remedial work to do on headcount management. I won’t skip to the end, but a bit of foreshadowing is that we will ultimately get more done, ship on time, and with vastly more clarity by spending hundreds of millions of dollars less (in direct costs) and completely removing the whole concept of budgets and headcount gymnastics from the team. It was a huge headache and had we failed to deliver good products then the effort would have been used as a causal factor for failure, but it positioned us enormously well for the financial crisis that would seemingly appear out of nowhere halfway through our first product cycle as a team.

The easy access to the headtrax system gave everyone a ready benchmark for how other groups were perceived as growing faster and bigger. In times of rapid growth, it was easy to find people who thought “Micro-dollars” were to be freely “invested.” Not in the back of my mind, but front and center, were my mentor Jeff Harbers’ words about spending and treating Microsoft money as the shareholders.

That’s the rant as to why the key lesson learned for me was that if you want to know what an organization is doing, then just count where the developers are and what they are working on. It really is that simple. Every financial control follows from the number of people actually working on the team. People love to say that building comes from small teams and of course there is truth to that. Building at scale, however, requires sizeable teams. The way to make a big team seem small-ish is to keep the teams focused on building and making the tradeoffs inherent in building and not on budget and headcount gymnastics.

In many ways, in a large company with many talented people and key product people in key roles, the unique and critical role of executive management is to decide and manage headcount so no one else ever even thinks about it and to drive the reallocations to get new things done, or adding headcount to be filled without the expectation or requirement to deliver in the current project. The only way to do that is by knowing what the headcount is actually building all the time.

Returning to the inventory of projects in the WWL organization, I counted 74 projects, each with about 13 developers on average for a total of 947 developers.  There were only about 780 testers which was far short of what Windows software generally required. Some of this shortcoming could be explained by Search, which was using more developer operations owing to the modern web architecture, but even Windows which I would argue needed more testers appeared short-staffed. There were 440 program managers which was shy of the 2 developers for 1 PM ratio I might have expected. There were, however, over 40 people managing the small teams of a dozen developers and most of those managers were serving as the lead program manager as well. I realize I am already falling into the trap of using Office as a baseline, but absent that there was no baseline, no plan or strategy, from which to work.

The key lesson learned for me was that if you want to know what an organization is doing then just count where the developers are and what they are working on. The largest project teams, over 25 developers, in this whole organization were (in order): Search, Print server/drivers, audio/video platform, audio/video codecs, modern interface (pen, ink, etc.), and media rights management. While there is never a perfect correlation between number of engineers and strategy, it was abundantly clear either the resource allocation was off or at the very least was not aligned with strategy. Looking to Windows for some examples, there were only 13 developers on DirectX the core graphics engine for Vista and there were only 25 developers on the rendering engine for Internet Explorer and they were primarily fixing security and compatibility bugs until the recent emergency plan to produce IE 7.0 for Vista. That came about because there was whole new, non-HTML, browser as part of Avalon which is no longer in the Vista plan. Avalon, which would later be known as WPF for Windows Presentation Foundation was a cornerstone of the Longhorn plan had a total of 46 developers. While the specifics of what code was where might not have been totally clear (and certainly isn’t today as I write this) the team was staffed inconsistently with respect to what seemed important.

Windows Live was organized as series of what seemed to be small projects relative to the overall scale. On the one hand, it might be easy to look at the allocation and think about each one as a cool startup inside a big company competing with a startup from Silicon Valley in a similar space. With that view, the teams were staffed well. Except Microsoft was not able to release things in a small way and grow them like a startup. Everything needed to work worldwide, include adequate accessibility, work across browsers (not just Firefox), and scale to all the users seeing the service on Microsoft.com one of the busiest sites on the internet. Microsoft’s online services were spread across 30 or so projects each with less than 10 developers, at least for the front ends (the backends were still in a separate organization).

The difference in org structure and composition relative to Office had already begun to clarify some of the questions I was receiving.

While those differences were stark to me, I quickly realized the obvious. Comparing what I was seeing in WWL to Office was not a merely non-starter, it was insulting my new team. No one in Windows wanted to hear anything relative to Office. Windows was not just different. It was vastly more complex as I was repeatedly told. It was also more difficult. For more than a decade I was used to being reminded directly (or more subtly) that Windows was technically deeper than Office, but now I was hearing that Windows was also a more complex management challenge. I wasn’t convinced but I was in active learning mode.

I had no other baseline. I knew Office. I knew development tools. I worked across the company for BillG. I’d studied tons of other companies As much as I knew I was biased in my thinking of Office, I also knew…it was just software. It could not be that different, I thought. I did not really believe Windows was either more technically challenging or more difficult to manage, but I had to resist the temptation to debate those points. 

There were bigger issues. As much as I was focused on addressing Windows challenges, I realized the pain and anguish the Vista product cycle had brought to the broad employee base.

To many product group employees, the stock price slump reflected the product execution, and Vista was taking the brunt of that blame. The challenges were much broader and deeper, however, and it would take time for employees and other executives to gain an appreciation for the difficulties the company was facing in products. There’s a tendency to view morale and employee issues (or broadly culture) as distinct from company execution and performance, but at least at this moment one thing was clear. The negative employee experiences were happening at the same time as customers were experiencing product issues and strategically the company seemed to be falling behind. It did not seem to me that one could fix the culture unless we built better products, executed more effectively, and transformed the business to be more competitive.

A favorite internal conversation for me was on a Tren Griffin (TGriffin) email discussion group, called LITEBULB. TGriffin was a former technology investor, Seattle-area native, and early friends with the Gates family. He was one of the strongest strategic thinkers at Microsoft. Long a student (and author of books) of investing, Tren frequently posted news stories or questions about competitive markets, Microsoft’s approaches, or other industry dynamics, and generated a rich discussion among a core group of contributors and a larger set of observers. Often the best discussions about Mini’s posts or other press articles about Microsoft could be found on the LITEBULB distribution list, or his external blog 25iq. (Above is an example of a thread from LITEBULB.)

After a couple of weeks of listening across these many forums, I started to gain a full picture of what was going on. It was deeply emotional for me—a mixture of opportunity, as I said in many team meetings, “to work on the other greatest business in the history of business” (a not-so-subtle reference to Office I could not resist), and deep angst, which I also shared in many meetings. “So much of what I’m hearing are things I’ve seen, heard, even experienced over the past 15 years but from afar . . . and now these are my problems, and by that, I mean our problems to solve together,” I would say.

I had moments of sheer terror. For a while, I tended to avoid people outside of the Windows team, especially my dear friends in Office, because they all wanted to know, “Are things really that bad?” I simply could not afford to be candid. Even going to yoga class or out to dinner resulted in sightings I wanted to avoid. Seattle was a one-company town back then.

Fifteen years earlier when Mike Maples (MikeMap) shared his description of two gardens, the Windows and Office gardens, I understood it intellectually from the experiences I had. Now I was experiencing the difference emotionally. Even to this day, I struggle to articulate just how different the cultures were, while both still achieved spectacular success. Somehow this came about all under one roof in a remarkable case of divergent evolution.

While I definitely experienced lonely moments leading Office, I was never as lonely as I was in the first six months of working on Windows.

I had to write to think. But I was not ready to write in public.

On to 085. The Memo (Part 1)

Welcome to Chapter XII, where Hardcore Software turns from Office and enterprise customers to Windows and consumers (and PC makers). For many readers, this will also be a bit more of their own lived experience. As such it is worth a reminder that I am sharing my experience and observations, not any sort of omniscient history (if such a thing even existed). Importantly, by waiting a decade to write, the history becomes much clearer and less influenced by the emotions or immediate reactions. That’s certainly been my experience so far in writing HCSW. These next four chapters (about 25 sections) will cover Windows 7 and Windows 8, with a decidedly different approach than the previous 11 chapters. We will see much more focus on organization, strategy, culture, real competition and disruption, and the challenges and opportunities seen in a big giant company.

Back to 082. Defying Conventional Wisdom to Finish Office

2006: The year was marked by cultural shifts. BillG announced he would step down as chief software architect, a transition that would take two years. I was given a new role and faced multiple corporate and culture challenges, and outside of Microsoft the tech landscape was changing too. And fast. “To google” was added to the dictionary.

By the start of March 2006 the Longhorn product cycle had been a chaotic five-plus years that included the security work for Windows XP, the release of Windows Tablet PC, Windows Media Center, Windows 64-bit, Server releases, and importantly, a major project change called the Longhorn Reset, essentially defining a new scaled-back product mid-flight based on the original Longhorn. The Windows team had been through a lot and was not finished. Longhorn had been receiving a lukewarm reception from users of a big Community Technology Preview release since the fall of 2005. The team, however, had started updating the product more frequently and momentum was indeed shifting by early 2006.

Windows Vista, as it was officially named, was still an unpredictable amount of time away from shipping. While not public at the time, a couple of weeks down the road, Microsoft would announce a final and just-decided delay to ship Vista for availability in January 2007. The team could not commit to making the release available in time for PCs to be sold for back-to-school or holidays 2006. Vista would eventually release to manufacturing in November.

Windows was still on fire with PC sales breaking through 200 million units in a single year for the first time, demonstrating extreme product-market fit. Both Servers and Tools were doing well, extremely well, except there was a nagging problem emerging from across Lake Washington called AWS, Amazon Web Services, a shift from companies buying Windows to run on their own server computers to renting storage and compute in the (or a) cloud. There was a good deal of tension between Windows team and the Server team. The Server org required the Windows org to contribute to shipping a new Server. This delayed a new Server product, slowing their release based on Longhorn until the next Windows release. The .NET framework and Visual Studio had become leaders for IT development within corporations, but the onslaught of Linux, Apache, MySQL, and PHP (later Perl/Python) continued to dominate the public internet and the university programs in computer science.

On the RedWest campus the investments in online services faced a myriad of revenue, cost, product, and usage problems that were not nearly as visible as the Windows challenges. Wall Street, however, was growing increasingly impatient with financial results, which seemed to punish SteveB for his transparency. There were dozens of Microsoft online services, some branded as MSN and others using a new umbrella name Windows Live, in every conceivable category from selling cars (MSN CarPoint) to chat (MSN Messenger) to finding Wi-Fi hotspots (MSN Wi-Fi Hotspots.) Microsoft seemed to be searching for a big win against Yahoo and a rapidly dominant Google in the world of internet advertising and consumer services.

Google was top of mind for many, not because so many groups across Microsoft competed with Google products but because of the aura the 2006 Google culture achieved. Google was fast. They were innovative. They were empowering. They had “20 percent time” when engineers could work on whatever they wanted one day a week. They had free gourmet food and a chef, all day long, compared to our grungy filtered water dispensers and subsidized airport food with limited availability. They had snacks and we still had noodles and one type of V8®. They had massages, while we had a multi-purpose sports field, but no towels (note, towels returned in the summer 2006.) We had individual offices and they had collaborative open plan cubicles (you read that correctly, Microsofties complained about having offices.) They had a modern, flat organization with 50 reports to a manager (yes you read that right too.) In the blink of an eye to me, everything we held near and dear and made Microsoft an icon of business culture, seemed to be old, tired, and either wrong or inadequate, like wearing khakis, loafers, and a button down to Burning Man.

Google Chrome was still almost three years from launching while Internet Explorer had 90% share. The last new release, however, was Internet Explorer 6.0 launched five years ago with Windows XP frustrating users, web developers, and the market. Gmail was about to turn two and it was crushing Microsoft Hotmail with its superior junk mail filter and massive free storage. Microsoft just started to build its own web search product which would launch in 2006 as Windows Live Search into a market where Google had already overtaken Yahoo and grown to half the market while gaining a half point of share every month.

As Vista was creeping along, albeit faster these days, toward shipping, there was a much deeper problem in Windows that was symptomatic of the broader malaise or even open hostility across the company, especially in engineering. Even though the company kept putting up blockbuster numbers, the morale across product groups had declined. Vista had contributed to that. Integrated Innovation had as well. Integrated Innovation was the expression at the CEO level of the desire and right to build integrated software, which continued to be challenged in the courts and among regulators. Internally, this was the opposite of what people wanted to hear because the feeling was Integrated Innovation, or synergy, was what had first gummed up Microsoft relative to Google. The yearly Microsoft Poll survey was a litany of complaints and issues from employees across most of the product groups.

In a semantic twist, the phrase was later morphed into Innovate then Integrate. That might not have helped. In reality the pressure for synergy had not relaxed at all as it was a cornerstone of Microsoft’s (and BillG’s) strategy and culture, even more so as the company became an enterprise company given how much enterprise customers and the enterprise ecosystem valued synergistic strategy, or maybe strategic synergy. Strategy was the anchor holding back Longhorn. A scathing cover story in the September 26, 2005, BusinessWeek, “Troubling Exits at Microsoft” painted a picture of employees departing, malaise, and the rise of Google. Even a longtime member of Microsoft Research’s Technical Advisory Board, Carnegie Mellon professor Raj Reddy, called for a company breakup to support more “nimble operations.”

But the biggest problem was that we felt like we were losing, and Wall Street felt that way too and the stock price reflected that lack of enthusiasm.

We were losing to Google. We were losing to Yahoo. We were losing to BlackBerry and Nokia. We were losing to Sony. We were losing to Oracle. We were losing to SAP. We didn’t have anything to compete with AWS. We were losing to Apple when it came to PC hardware. We had already lost to Apple’s iPod.

In the years ahead, we will see accelerating change in the software industry, as the computing needs of our customers start to move beyond the PC into a “PC-Plus” world.  The PC will undoubtedly remain at the heart of computing at home, work, and school, but it will be joined by numerous new intelligent devices and appliances, from handheld computers and auto PCs to Internet-enabled cellular phones.  More software will be delivered over the Internet, and the boundary between online services and software products will blur.  The Internet will continue to change everything by offering a level of connectivity that was unimaginable only a few years ago — and every home, business, and school will want to be hooked up to that incredible global database. —Annual Report, 1999

Our competition with Apple was becoming increasingly sharp compared to past years where our view was essentially to ignore them, going way back to the launch of Windows 95 and the “C:\ONGRTLNS.W95” full page advertisement in The Wall Street Journal. In 1999, BillG wrote an oped for Newsweek and a month later proclaimed in the 1999 Annual Report to Shareholders that the “PC-Plus” era was upon us. With this Bill was describing an era where PCs would continue to be central, but rather than part of every scenario they would be surrounded by devices that connect to a Windows PC.

This framing of the future became more visible and widely used across Microsoft communications as the temperature of the competition from all corners heated up.

The PC-Plus era is rooted in a response to what had been simmering among the tech press from as early as 1993 when Walt Mossberg first used the phrase “Post PC.” The first wave of connected devices began with the EO Communicator in early 1993 and then the Apple Newton available a bit later. In his review of the EO, Mossberg described the device as not “the kind of post-PC device that promoters of the PDA concept have promised: something with the price, size and battery life of a Sharp Wizard, but the smarts and communications ability of a good PC and an advanced phone.” Whereas in the review of the Newton he described it as “a post-PC device that streamlines data entry, links all of your information in intelligent ways and adapts to your handwriting and work habits over time.”

A few years later with the 1999 arrival of the Palm VII, the first truly connected and mobile-phone sized device, the punditry was running full throttle declaring the arrival of the Post PC era. The trade press was filled with editorial and widespread usage of the term, much to our dismay at Microsoft.

Bill Gates, Paul Otellini, and others in the PC industry went on a bit of a campaign defending the PC and declaring the PC-Plus era. They executed a series of OpEd pieces and other marketing efforts to thwart the notion that the PC was dead. In The Wall Street Journal in May 2006, just after I started working on Windows, they wrote an OpEd explaining why and how the PC will continue to thrive.

So, the next time you read about the end of the PC era, think about what you do when you get home from vacation and want to share the pictures on your digital camera with family and friends. Or where you go to download music and videos onto your iPod or MP3 player. Or how you synchronize the contacts, calendars and email on your handheld wireless devices. Or where you go when you want to find new music or search for that episode of "Lost" you missed last week.

You sit down at your PC, of course.

As this shows, the defensiveness around the PC became increasingly obvious and the technical justifications increasingly detached from where the industry was heading.

There was no shortage of problems on the Windows front, in contrast to Office which seemed on both solid footing and heading calmly to a new era. Despite the chaos, upheaval, corporate strife, and my own apprehension, I was about to run towards the fire.

Office Hours

I was sitting in the guest chair in SteveB’s office while he was standing, swinging his golf club. He stopped, finally, and said, “Thank you. Thank you.”

With great enthusiasm, those were his words as he shook my hand with all the vigor of a salesman closing a deal. A handshake between product group Microsofties was so unconventional that it added to my uneasy feeling.

Uncertain as I was, I accepted the role of leading Windows product development.

But it would not be so simple. That also meant managing the struggling Hotmail, the new Live Search, and the loved and popular, though shrinking MSN Messenger, along with several other online services. I would report to Kevin Johnson (KevinJo), who had joined Microsoft from IBM in the early 1990s and risen up the ranks by building out the company’s customer support arm and then to running the worldwide field organization (after Microsoft he went on to become the CEO of Juniper Networks and then Starbucks). Kevin would provide much needed stability across his enormous portfolio, which included all of Windows and Server, Tools, Servers, and online services. The big news was that Kevin was taking on a new and huge product development role, essentially everything except Office. The way I thought about Kevin’s job was he was on the hook to lead competing with Apple, Linux, Google, Yahoo, now Amazon, and the rest of the internet. The key thing for me was that one person oversaw every major customer segment at the company: consumers, PC makers (Microsoft’s largest source of revenue concentrated in about ten customers), developers (developers, developers), small business, enterprise IT, and now advertisers. It was kind of nuts for one person to be asked to manage all of that I thought. My job was to help him by making sure Windows was taken care of.

The Windows team had been divided into two big teams for quite some time. The core operating system was known as Core OS Division, COSD (pronounced “kahz-dee”). COSD led the parade at creating Windows, drove the engineering process and culture, and was staffed with first among equals. COSD owned the operating system kernel, device drivers, file system, networking, security, and in general the guts of Windows. The team was where the original Windows NT architects all worked. When Jim Allchin (JimAll) created the COSD organization he and I spoke about how we built the Office team (the original Office Product Unit a decade earlier) and COSD was somewhat mirrored after that, at least they thought so. About half the Windows resources were in COSD.

The other half of Windows was known as Windows Client and embodied the user side of Windows including the graphical interface, the explorer, start menu, control panel, printing, faxing, and all the experiences from tablets to media playback, to Windows Media Center, and importantly Internet Explorer. What COSD was to process and hardcore, Client was to “doing cool stuff.” A visit over to one of the Client buildings and you were likely to see displays of cool new media players, fancy gaming PCs, or the latest in wireless gadgets. There was always a cool demo to be had. Showing off COSD innovation was a lot more tricky.

There always seemed to be tension between COSD and Client. Whether it was about the schedule, testing, or different views of the engineering process. There was not a lot of love lost between them. This might seem weird to many. To outsiders, I am positive the early days of the Office Product Unit tension with Excel and Word would look identical.

For clarity, the Windows Server product worked closely with COSD but owned the product definition and the unique components differentiating Server from regular desktop Windows. Yes, it was a complex matrix.

Technically I was to manage Client. COSD was driving the Longhorn project even though Client was 100% engaged on that. No need to upset anyone with a new boss anyway. We would figure out the details of COSD at some future date closer to when Longhorn would ship. I also took on half of the Windows Live Services, which were also divided into two orgs as well (front end and back end.)

If this sounds a bit halfway, that would be a valid observation. It was certainly confusing to outsiders searching for the new boss of Windows, which JimAll was previously. In total fairness, very large reorgs are never finished before they start to roll out. There is always a balance between completeness and fighting the inevitable leaks that prove even more distracting. The press release from Microsoft tried to detail the organization but from the outset it was complex.

Was I up to this job? Was the team up to me in this job? Could a person with experience only in “boxed” software work in the modern world of online services? An Office guy running (half of) Windows? That seemed like a punchline to a bad reorg joke.

And what did we need to accomplish? Tackling the challenges faced by Windows seemed, well, perhaps too late to the party. They still hadn’t finished Vista after the Longhorn reset and it wasn’t clear when it would ship. Did I have to ship Vista first? What if Vista turned out fine and customers were happy? Or did Windows need to be reinvented? Brought back to life? Or both? And, if so, what level of urgency was even possible? What did the individuals on the team think were the problems?

I had never hemmed and hawed about a job change or negotiated any titles, terms, or conditions, and I didn’t for this one—just two weeks going back and forth, mostly with BillG to get a sense for his candid thoughts. My new role marked his last staffing efforts with SteveB—the last “Bill person” to move into the Windows job. Though I was not ever going to be a “Steve person” because of my lack of field experience, we both worked equally hard to see each other’s perspectives.

All the best choices I had ever made in life were counter to my exceedingly planful product execution, without strategizing, lists of pros and cons, or excessive deliberation. I just went for it. I was lucky in that regard having not really made a poor choice, yet.

But I was tired. I had been going nonstop since graduating 1987 and had, for all practical purposes, given my 20s and 30s to Microsoft. Was I about to turn over my 40s?

This opportunity was sure to be all consuming.

A management transition for Windows was a material corporate governance event, and thus a formal announcement needed to happen quickly to avoid the potential of leaks to Wall Street. Plus, there were many anxious people across the company who had both a need to know what was going on with Windows, and a need to influence what was going on (or believed those to be the case).

“Quickly” turned out to be an understatement.

The Vista team sent out a team-wide mail as well as communication to partners with an absolute RTM date of October 25, 2006, a slip from the previous August target. This was essentially external communication and would generate press. However, word already leaked to The Wall Street Journal about me moving over to Windows. The PR team began negotiating by trading verification of facts in an effort to delay the story. The story was going to run on March 22, 2006.

The clock was ticking to actually get an announcement done. The announcement scheduled for the morning of Thursday the 24th would not be moved even with the WSJ story.

Within minutes of accepting the job, I was informed that my first meeting was to be held immediately to go over the announcement tick-tock, an expression I had not seen used before inside Microsoft. I was also asked for my internal comms contact, my external comms contact, my human resources contact, my executive assistant, and my chief of staff. Time was short. There were almost 40 people on a mail thread summarizing the process.

I had no staff, so I replied, “Just ask me.” I suspect everyone on the mail thread had no idea what to do with my response, but it sure cut down on the email traffic as there was a bit of a culture of fear in Windows when it came to sending mail to an executive, especially a new boss and one they had not worked with.

I forwarded the mail to our executive assistant leader Collen Johnson (CollJ) and then immediately walked into her office. I shook my head as if to ask, “What did we get ourselves into?” I knew Colleen was already buffering a huge amount of noise, mostly people asking if I really meant for them to ask me directly.

I arrived at a conference room in building 34, the big executive building, to a room of what appeared to be a re-org war room. There were easily 30 people, standing room only, more people than I think I’d seen in a meeting since we signed off on Office 2003, all to plan the announcement of my new role. The big conference table was covered with handouts of org charts, talking points, and draft press releases and rude Q&A docs. I didn’t know most of the attendees. It was funny because this was not a restructuring or anything complex; it was news of a retiring executive JimAll, a new executive boss, Kevin Johnson, and then me. It seemed that every vice president involved in this announcement sent two or three people to the meeting but didn’t show up themselves. Questions quickly started mounting over messaging, email cascades, and heads up. The production values well exceeded the actual announcement being planned.

As much as I understood the importance of this announcement to the business world and to the team—after all, this was the retirement of legendary technologist and leader Jim Allchin and a material event for a public company—the craziness (and that’s what this was) around a single announcement represented a microcosm of the entire situation. I was no longer in the comfortable garden MikeMap had created for Office.

With a lot of effort, the room managed to get the information that everyone wanted to go into this announcement down into a single email response to the official press release and filing, which I wrote, which came from me, and had one small set of talking points for any press calls that PR would handle. There was to be no email cascade—a new word for me that meant a process where an email went out from the top to the organization, and then every level of management forwarded that email (that people had already received) to the team(s) they managed with their own words interpreting the org change for them. Since there were parts of the Windows team that were nine or even 10 levels deep, the amount of interpretation that went into these cascades was mind-boggling in the depth and breadth of potential misinterpretation.

Turns out, we needed none of that with this announcement. Why? There would be no outreach or interviews by anyone at this stage. Most of all, literally nothing would change until Vista shipped.

That was the only talking point that mattered.

I was not joining Windows with some sort of secret master plan nor did we want the announcement of my job to portray me as some sort of Vista savior. Still, it played out a little bit like that in the press. There was an uncomfortable 36 hours between that WSJ story and the official announcement. That’s what happens when things leak.

The Wall Street Journal said, “[Sinofsky] has a reputation as a meticulous manager who is adept at controlling large software projects.” Paying homage to MikeMap, the article said the Office team culture was created by “an executive recruited from International Business Machines Corp., the Office group adopted a more management-heavy, disciplined culture . . .” The headline read, “Microsoft delays Windows Vista debut again; consumer version to miss critical holiday season; unit shake-up is expected.”

The rest of the week saw much of the press derived from the WSJ and the announcement focused on my new role in fixing Windows. There was no way to avoid this. It was broken. I guess it was also the truth. Business 2.0 ran with a headline “The Man Who Could Fix Windows: Microsoft's new OS chief has to get Redmond to embrace a new model of programming, in which software is constantly being improved instead of updated every 5 years.”

Inside the tech industry, one of my longtime favorite foils in the press, Mary Jo Foley of ZDNet, said, “Sinofsky has the reputation of a strict, schedule-bound manager who keeps the trains running on time.” After all these years, and quite a bit of product innovation from the team, I was basically a strict project taskmaster. That stung, in a Spock-like way. But later the ZDNet editorial team added more, “The Sinofsky promotion (not sure we’d consider being named Windows Mr. Fix-It constitutes an upward career move) grabbed the most headlines.”

And finally, everyone’s favorite anonymous internet whistleblower, Mini-Microsoft, a widely read blog maintained by anonymous author calling themself Who da’Punk offered thoughts. To clarify the record once and for all, I was not the writer and have no idea who was though at least two reporters met the blogger in person verifying that fact. The post on March 23 had a headline that read:

“Sinofsky to the Rescue!. . . (?)”

The article said, “There’s a new sheriff in town, and he’s aimin’ to gun down any rootin’, tootin’ varmi[n]t that can’t deliver what he committed to. Maybe.”

It is probably important to detail Mini-Microsoft at this time because they were a fixture over everything that was going on at Microsoft, even if I chose to ignore them the rest of the Windows team and the company followed every word (and so did the press). Mini, as in “Did you see the latest Mini?” or “Well, that really pissed off Mini” wrote about all topics Microsoft though seemed especially focused on the plight of typical employees struggling to make sense of what was going on. Mini was especially critical of typical big company problems such as organizational bloat, excess hiring, lack of innovation, performance reviews, promotions, salary, and more. Mini was also critical of our technical strategy and challenges around Longhorn. Like many claiming informal whistleblower status, the challenge was always there for an executive to respond to critiques, but it was so difficult to do so knowing Mini did not always have the complete context.

It is difficult to parse today but when reading Mini’s posts one of the most interesting aspects is how they turn the phrases of Microsoft’s HR and leadership back on them. From accountability to synergy to integrated innovation and even “I love this company” which was classic SteveB. Beyond that I proved to be a subject, directly or not, over the next couple of years in many of his (eventually their gender was identified in the press) over 100 posts. Mini even got himself a profile in BusinessWeek, as part of the much larger negative story about the loss of talent at the company.

Share this post with a friend who remembers Mini :-)

I had no real direct reports at this point because everyone, including BillG, was finishing Vista. Still, I needed a way to quickly connect with a large number of people in a way that felt more . . . intimate.

To move forward, I chose a decidedly non-traditional path. The Microsoft way might have been a big all-hands meeting, a follow-up email with vague statements of support, or an immediate gathering of a staff meeting. Instead, given the need to both ship Vista and meet a lot of people I looked for a way to communicate broadly while connecting in-person with many, all while not getting in the way at all of Vista. This meant, for example, turning down all the escalations or crisis moments that people would bring to me. For example, in July AMD announced the intent to acquire ATI, the graphics card makers, which caused a brief panic in how to handle shipping ATI drivers in Vista. Given the future impact of this choice many tried to pull me into this crisis. This was a brilliant acquisition and noteworthy that Intel did not lead or follow up with acquiring then similarly-sized Nvidia.

I browsed over to the internal SharePoint site and created a new blog called Office Hours in an effort to signify openness and a risk-free place where ideas could be shared. Blogging the goings-on proved to be the best way to reach a team of approximately 10,000 people and, as I would learn, the rest of the company.

Over the course of six-and-a-half years, I wrote more than 400 posts amounting to nearly three quarters of a million words (1,700 pages), answering questions, discussing the how and why of all we were doing, not doing, or considering, and detailing almost every aspect of the business. I wrote something substantial most every week, sometimes twice. Posts covered product strategy, organization structures, people management, competition, features, culture, my personal management, and just about everything in between. I posted the trip reports I dutifully wrote after conferences, recruiting trips, and customer visits. Many of these posts were included in a book I co-authored with Marco Iansiti of Harvard Business School, One Strategy: Organization, Planning, and Decision Making (Wiley, 2009.)

I had one last meeting with the Office team. We gathered the Senior Managers, the most senior 120 or so people (the dev/test/pm triads as well as general management and discipline leaders across design, planning, localization, content, operations), in the big conference room where I shared the news that was about to break. Even to this day it was the most emotional day of my years at Microsoft. I looked out over the room and saw people I had all but grown up with professionally, many of whom I’d known for my entire time at Microsoft. Mostly I sensed they were worried about me—the look on their faces said no one goes over to Windows and lives to tell about it.

As I was packing up my office to move across the street to a temporary office in Building 50, a member of the team stopped by and delivered the most wonderful hand-made lightbox of Office logos and packaging over the past dozen years. It still sits on my shelf with the signed note. It means the world.

This was just my first couple of days. Even though for the time-being I had no direct reports, I still needed to figure out who and what would eventually be on my team. The team was incredibly anxious and clearly expected both a master plan and a reorg. I realized that many people had observed or become a fast study in how the Office team worked. Many were prepared with arguments as to why the way Office worked (at least their perception of that) would never work in Windows.

I had a sneaking suspicion that SteveB and BillG wanted a quicker “fix” than I might deliver.  Even though I had not only lived the Windows challenges for at least a decade and many of the people were well-known to me through countless meetings, offsites, email exchanges, and more, the one thing that is certain is that talking about fixing something is a lot easier that actually fixing something.

On to 084. Who’s On the Team, Exactly?

As we conclude the story of Office12 and the major redesign of the product, Microsoft of late 2005 to early 2006 is in a bit of a lull which for better or worse is good for the launch of Office. Longhorn continues to stretch out and the lack of clarity continues, which is putting a drag on everyone. There’s something very special, yet bittersweet, about this release of Office.

With the conclusion of this chapter, Hardcore Software, will start to get into Windows. I have about 30 stories planned. As my roles have changed so too have the stories. With Windows, we will see a lot more detail on organization, change management, strategy, and direct competition. If you are not a subscriber, please consider signing up. Audio will continue to be free and posts with all the graphics, artifacts, PDFs, and videos will be available to subscribers.

Back to 081. First Feedback and a Surprise

Nearly every country’s “Feedback to Corp” slide at the grueling field sales multiweek Mid-Year Reviews (MYRs) in January 2006 published the same bullet point:

🚩 Office “12” – Needs Classic Mode

What was this big, and clearly coordinated push for something called classic mode, and why now? We, of course, knew what it was but we did not know why this was happening now. It was very late in the schedule, post-beta testing. We were just months from scheduled completion as we just went through the final validation of the product—when the team is changing as few things as possible for the last few months, certainly not making any design changes.

A broad public beta went out to most enterprise customers as well as the technical press. More people enrolled in the beta than we expected or could even imagine. There was a great deal of interest in such a bold direction for Office.

As with the technical beta, the reactions came swiftly and clearly, often based on little more than the first few minutes with the product. Reactions from the press arrived in three waves—straightforward news of the release, first looks or reactions based on first experiences, and then, after a week or so, deeper dives into the product.

The first looks wrote themselves as we expected. Office12 was a sweeping change, and the obvious commentary or controversy questioned whether customers or the market were ready for it. Would it work? How difficult would it be to learn? Almost always the point of view of why the change was made was reflected, but the tone was skeptical. That was kind of annoying, but entirely expected.

For example, CNET’s Ina Fried who is always fair and balanced, said, “The radical revamp could help the company as it seeks to stave off competition from OpenOffice and others, but it also risks alienating those who like things the way they are.”

Computer Reseller News, the trade publication focused on small and medium business, went to great lengths to express concern. “While most users will welcome the additional features, Microsoft’s decision to teach its customers a new user interface for accessing commands and functions could be a risky proposition. Once the beta testers (and the bloggers) have registered their opinions, some Office 12 design points could be in for a course correction.”

A more detailed expression of concern came from CNET’s editors. “In the past, Microsoft has sabotaged itself by unrolling too many new features to Office too fast. We’re keeping a lookout for problems; after all, Office 12 was in its storyboard stages just a few months ago. If you’ve spent the past two years mastering Office 2003, prepare for a steep learning curve.”

These articles generated the MYR feedback. The enterprise account managers, essentially all our revenue except for Japan, were on the verge of freaking out. They saw the Ribbon as pure friction in the way of revenue and nothing less. They cited doubts expressed in the articles, reprinted in every language around the world, as evidence of deep concerns over the direction Office was taking. They did not want to spend energy selling Office where the assumption was we’d already won. They wanted to focus on selling the big server strategy, where we were losing to open source Linux and a host of smaller competitors. So why put up a barrier, they asked.

As if to highlight these enterprise customer concerns even more, in the spring of 2005 Office marketing rolled out worldwide a series of advertisements as a follow-on to the “Great Moments” campaign previously described. Attempting to inject humor into the extremely enterprise Office 2003 wave and to encourage customers to digitally enable knowledge workers, marketing developed a new advertising campaign affectionately called “Dinosaurs” though formally called “Evolve.” These ads featured humans in the office but with oversized, cartoonish dinosaur heads, implying those who have not yet embraced a digital workstyle including running Office 2003 were dinosaurs. In other words, we called nearly all our customers dinosaurs. At least the ads were popular in Japan, a market known to appreciate a good mascot, where the company distributed a large quantity of small plastic dinosaur heads.

Very quickly what felt like a magical release suddenly seemed to be worrisome to the sales force. That was not acceptable.

We obviously took on a significant risk in choosing a complete redesign of Office to address our “good enough” challenge. In hindsight sometimes I can hardly believe we did so. Now that we had 18 or more months of time to develop the product, we were genuinely confident.

Our previous attempts at addressing bloatware or the belief the product simply did too much each failed. These approaches were rooted in the conventional wisdom of different stakeholders:

* Reduce User Interface. From the earliest days of the product, the path to simplicity was to minimize the amount of interface visible on the screen. The conventional reaction to bloat was to proclaim less is more, as we often read about in reviews and analyst reports. We did our best to avoid removing features. Instead we twice tried a few design tricks, one was Intelligent Menus and the second was the technique of rafting toolbars.

* Office Lite. The business view looked at price points and wanted to meet good enough with a lower priced offering without upsetting the main revenue stream of course. The way to compete would be to have a stripped down, easy to use, easier to administer, lighter-weight version of Office, that cost less. We solved for this problem by changing the composition of SKUs to create lower price points, rather than chasing the low end as previously described.

* Customization. Customization was always the easy way out. If a customer or IT group didn’t like something in Office, they could just rearrange it. The tech enthusiast users and those early in the beta process said the would be fine with the Ribbon, so long as it enabled full customization by rearranging the tabs or contents of the interface. We addressed this with the customizable Quick Access Toolbar, complete keyboard support, and support for creating custom add-ins.

As we have seen, each conventional approach was fatally flawed and by and large amounted to half-steps to addressing the challenge of bloat or good enough.

Instead, Office12 would take the perceived liabilities of Office—the depth and breadth of features—and turn those into assets. The strategy was to make the product better by not just redesigning but reprogramming the user’s experience for a modern era.

Office12 could easily be viewed as taking the contrarian approach to conventional wisdom and feedback at each step. In early 2000s Microsoft, the idea of not “listening to customers” was decidedly counter-intuitive to put it nicely.

Most of our Office buyers were vocal and visible. Enterprise account managers regularly brought IT managers and executives to Redmond for briefings. Along with a direct line to SteveB, they were never far away, nor were their expressed concerns about products. As previously discussed, the growth areas of the Windows Server business hinged on directly listening to and acting on feedback from IT pro customers.

In the consumer business, Microsoft’s new online services were increasingly enamored with A/B testing and experimentation, substituting data for intuition (much more on that soon).

And here we were in Office being radical. To many it looked like we were either ignoring customers or not using data. We were just working the old way.

The MYR feedback added a new challenge. Customers, especially our prized enterprise customers, would simply demand we not ship the redesign at all. Even if we chose to there should be a way to easily revert to the previous design, at least for administrators.

Whether enterprise customers installed and tested the beta or not, this concern rapidly spread through the world of IT directly to our account managers. Budgets, dollars and headcount were reserved for back-end servers and data centers, for which we offered SharePoint and the full spectrum of Microsoft servers. In this environment, the resources that were allocated to PCs for individual knowledge workers were used almost entirely to keep PCs running, free of viruses and malware, and handle catastrophes such as breakdowns and stolen laptops. The budgets and resources for training materials, helpdesk, and even how-to courses all but vanished from the corporate world.

Given that context, any major change to Office was costly and unbudgeted. Even though customers were paying for years of Office, they had stopped factoring change into their IT budgets. For most in IT, Office was viewed as complete. Office was good enough. At the most extreme, a new version of Office would be fine if it added a few more menu items or commands, but mostly the best release of Office was one with no changes at all, but with better virus protection, reduced system requirements (Office already consumed the least amount of system resources of most anything running, even browsers), and even more administrative controls especially to turn off new features. Whatever lock-down we saw back in 1999 that first time visiting enterprise customers was now an ever-increasing new normal.

According to conventional wisdom among Microsoft followers, Classic Mode (CM) was the answer. CM was not part of Office12 and never was, but almost on cue the early punditry and enterprise teams assumed it would be in the product. The feedback or request was more of a Microsoft reflex. The term originated from Windows, referring to a switch or mode that flipped the new operating system to the look and feel of the old version. Windows had historically taken this to extremes. For example, in Windows 95 it was still entirely possible to run the old Program Manager and File Manager instead of using the new Start Menu and Explorer (in fact, those still run today on the 32-bit versions of Windows 11). Windows also included visual themes that emulated the old graphic design, which made the product look. . . old or comfortable. This provided a comfort for IT managers concerned about training. It was marketed as an option, but it was heavily documented in many deployment and IT-focused publications as an asset or even preferred way to use the product. Technically, CM meant Compatibility Mode in Windows, but it was referred to colloquially as Classic Mode because it referred to the old, and presumably loved version of Windows. These were thin veneers on very easy to use features, but customers were comforted by the gesture.

It was therefore entirely logical that these same IT managers (and the field sales managers) assumed Office12 came with a switch that turned Office12 into the standard or conventional user interface design—Classic Mode. Both Classic and Compatible are interesting word choices in that both imply the new product is less than a classic or not compatible.

The absence of classic mode was a surprise to, well, everyone including BillG and SteveB. While at one point super early on it was something we thought we might do, in hindsight, it was never more than a consideration with a placeholder specification.

Still, I had to be careful not to say that at MYR. I learned long ago not to drop hints or to be vague at MYR. My action item was dutifully recorded and in due time I would get back to the field staff with our plan.

We had so many reasons why CM was not possible let alone desirable. First and foremost, the requests for CM were based on the assumption that existing Office products were as easy to use as our marketing implied. While customers overwhelmingly associated ease of use with Office, in everyday usage, the product was complex, maddening, and fragile. Each day millions around the world had moments of dissatisfaction. The old products were familiar, but no one thought they were easy in any absolute sense. There was room for innovation to save untold hours of grief. No sane person would debate the maddening frustration that came at some point when using Office.

The user interface for a product that does as much as Office goes well beyond aesthetics. The design of Office 2003 was functional, and as a design the product was failing customers. Many people were squeaking by as long as they used the small set of capabilities they previously learned. And the tiny percentage of people who mastered the product would not credit design for their success, but rather their fortitude and investment in learning the product. A product designed for a single profession, like Adobe Photoshop or Autodesk AutoCAD, could remain mysterious to outside users because those in need learned it as part of their professional training. Office needed to be different. It was a tool used by hundreds of millions of people who learned with little to no formal training.

The goal of Office12 was to be more human and less computer. The design language for the PC era’s first two decades was primarily about utility and consistency—as in, making everything just function. We were at a point in time where we wanted to make the products work for people and to do so with a new sense of mastery and ease.

In early 2005, JensenH wrote The Office User Interface System, a document detailing the rationale and design for Office12. This document covered the motivations, problems being addressed, and the detailed philosophy behind each of the elements of the design. Even to this day, it amazes me that we had this document a year before release, and it still stands as an incredible accomplishment by the UEX team.

There was no looking back. CM was about looking back. As a practical matter, there were three major technical hurdles to classic mode.

First, there was literally no room left in the product. One could easily project out the future of Office as having hundreds of toolbars and task panes. Office would literally collapse in on itself into a giant black hole of buttons with little room left for content. The screenshots meant as jokes ten years ago were looking more like predictions or designs. Any new feature was like parking at the mall the day after Thanksgiving. Except instead of circling the parking lot in a car, program managers would be circling the hallways in search of an empty spot on a toolbar.

Second, and less obvious, was that the Ribbon design fostered a new and more modern interaction between user and features—live previews, extended text descriptions, galleries, contextual user interface, and high-level grouping of commands. New capabilities in Office were designed knowing they could be offered to users in this more modern experience. There was nowhere to do that in the old interface. That meant we would either not have those features or we would need to develop yet another mechanism to provide those new features in an old way, somehow.

Third, and most critically, everything we knew about customer behavior said that once a customer turned on CM, they would never turn it off. They would expect CM not just for Office12 but for every release after that. When one considers that Office is supposed to be compatible release over release, then it is obvious CM becomes part of a permanent compatibility story. CM would introduce a fork in the Office product where everything is done twice, once the new way and once the compatible way. An easy solution to this was to simply run the old release of Office forever. Microsoft had a way to make this possible as well.

The debate over CM, in my view, trivialized the design of the product. While I was of course extremely empathetic with the change that would be forced (as some would say) on to customers, I could not help but think back to the early days of the project. At the start we talked about all the places in life and technology that change. People are frustrated for a time then recover and move on. We were going through one of the greatest changes in the history of the world with the internet. Every internet site was constantly changing. Why did Office have to be static? Static equals dying.

Why were people so nervous about this change? I was puzzled for a while. Then I realized, almost no one in power positions in the industry had lived through a major change to Office. Since about 1990, or almost 15 years earlier, Office was unchanged. Office was a constant. It was as if no one ever expected Office to change. Almost no one recalled the early MS-DOS applications or the pre-Windows era. Most of our own development team only knew Windows or Macintosh. Out of almost 2,400 people on the Office product development team, only 58 of them even worked at Microsoft before Windows 3.1 shipped and only 7 were at Microsoft before Mac Excel shipped. Over 80% of the team joined since Windows 95 shipped. Even our own team never really lived through the graphical interface transition or the 8-bit to 16-bit transition, except while they were in grade school. Most were hired from college and the majority had much of their early computing experience on Macintosh. Our new hires during Office12 were the first generation of web-natives, having had the modern internet since high school.

JulieLar had a strong point of view on dealing with this, as someone who did live through the graphical transition as an early Macintosh app developer on PageMaker. She often noted, “When you believe in a design, go for it.” Some might interpret this as no compromise, but principled was a more appropriate way to put it. In many ways it was a new-to-Microsoft approach. The general manner Microsoft (and Office) approached change was to always support the old way, either with an option or to move on to a completely new product that solved the same problem differently, leaving the old product on the market. If you ever wondered why Microsoft had so many data access APIs or UI widgets or any other of a multiplicity of solutions for one problem, it is this latter approach. It is vastly easier to start from scratch than to reengineer something in place. The only problem is starting from scratch and creating a new product/technology rarely brought forward the myriad of tiny subtle details that existed in the original implementation. Complex products resulted from this approach. The products were either complex because everything had an option or alternate way to use it, or complex because multiple products claimed to solve the same problem but in non-overlapping ways. Teams often took the path easiest for their code base, defaulting to whatever had the least friction to adding new features.

It is worth noting how valuable customers found a high level, or perhaps perfect, level of compatibility. Today we joke about running Excel 2.2 on 32-bit Windows 10, but it does so 35 years later! Even early 1980s character mode MS-DOS applications continued to run through new Windows releases as late as 2010. This is decidedly different from compatibility at a user interface level. Whether one uses old Excel or old Multiplan, doing so doesn’t impact using Office 2003 or Adobe Photoshop as the compatibility is just bolted on the side. In the case of Office, the old features were intermixed with the new and that was an entirely different level of complexity, an unachievable level of complexity.

Because of this history, JulieLar and I wound up on the front lines, so to speak, engaging with hardcore fans over compatibility mode from the early days of beta testing. In the private MVP newsgroups, I once wrote a very long essay, almost, about why change is OK reinforcing the history and context of our industry, including that most customers had simply never seen any material change in Office (or Windows). I might not have convinced anyone at the time, but I did start to formulate the kind of arguments that would come in handy later in my journey. Quoting from the newsgroup post verbatim:

To believe that at any given time some technology is the the ultimate in productivity and nothing should change is of course absurd. While many people have a massive investment in analog recording of video and audio, few would argue that the change in technology is worth it if you want to stay a leader in the field. Photography magazines are filled with "move to digital discussions". There will always be a few people who remain convinced that the technology they invested in is the be all and end all of the field and that moving to a new technology is not perceived as being better, and in fact is worse. As with any technology shift, it is *never* 100% better -- digital audio does not sound as good to some people, digital photos are not as rich in quality or resolution as film, digital video looks different than film, etc. But new technologies have benefits that were not possible or not thought of at the time. So it is with the new user interface.

The idea that CM was a short-term fix crystalized our collective point of view for how wrong-headed such a capability was. If we learned one thing over the previous few years of Enterprise Agreements, it was that if customers were offered a way to freeze infrastructure, or avoid anything new, they would take it. Not only would they take it, but they would embrace it and stick with it. How did we know? Many customers continued to run Outlook 97 even though we had several new releases and they had no interest in touching email on the desktop or retraining users. Windows NT 4.0 was still a dominant server running many Exchange mail systems and it was released a decade earlier. In fact, the most critical initiative in the field was to upgrade NT 4.0 customers to Windows Server 2000 or later.

With the 10-year support lifecycle in place, CM would mean customers would assume they could run the new release the old way for another decade.

We had always tried to honor past products with immense levels of compatibility that went far beyond any of our competitors on the PC. The lessons from changing the file format in Office 97 were clear, but so were thousands of accommodations or compromises we made over the years. Now, however, the combination of Enterprise Agreements and the 10-year lifecycle proved to be a huge leverage point customers had with product groups. So much so that customers always assumed that any changes to a product would be optional. Their ideal new product release was one that was the old product, just faster and easier to deploy and manage, and the new features would be available on an as-wanted basis.

That was not our plan with Office12 and the Ribbon. Ever.

The Mid-Year Review (MYR) where we were swamped with compatibility mode requests provided the best evidence for the excitement surrounding Office12. Many countries used the new visualization features of Excel to enhance their revenue, budgets, market share, and expense numbers. Every grid of numbers used the new features to automatically color code red/yellow/green or included tiny sparklines for a great visual effect. This time I knew how to accept the MYR feedback gracefully by empathizing with a commitment to get back to the teams.

I must admit I already knew the answer. We decided at the earliest days of the project (May 2004 precisely). It would be a few months from then before anyone would even ask about it.

During the early demos of Office12 when BillG went from office to office to see a select set of features, one thing he mentioned to me that I wrote down was “classic mode”.  He wanted to hear why we didn’t show him CM. He thought doing so was “trivial” and was something we of course did, but maybe (as was almost always the case) we were going to add it later. He was prepared to make his case and we had to defend our choices. We had to do so knowing we had no backup plan. Any product changes would mean a product slip, but that was the least of the worries. Bill did not think in terms of product slips or schedules even, and often believed what he asked for would be easy to squeeze in. The scale of the projects was still something he was not entirely adjusted to.

JulieLar and her manager and leader of program management (and former leader of Office development) Antoine Leblond (Antoine) were the right people to go to follow up with BillG. In January, they walked him through the state of the design, how we would measure success, and what risks we saw. They answered his questions with the supporting data. They detailed specific scenarios that they repeatedly measured throughout the development process.

I wasn’t at the meeting, but they told me it went well. Julie shared one direct quote from BillG, later shared in a magazine story. At the end of the demo Bill said, “I can’t believe you convinced me to get rid of menus and toolbars.” It was also one of the last Office product meetings BillG would have as a full-time employee before he transitioned to part-time later in 2008. We were done talking about CM.

We hit Beta 2 and RTM only about 90 days off the original schedule of the two-year project. By our standards we became an execution engine, and with Office 2007, as it would be officially named, we also showed we could innovate in a big way.

There were many reviews, now many blogs, from the end of 2005 through 2006. Reviews focused on the major overhaul of the product as expected. Also as expected, each put the question out there asking if it would be too radical or too bold. Nearly every review was positive to glowing.

A smattering of reviews continued to complain about the lack of a bridge to ease into the Ribbon, compatibility mode, or a way to turn off the Ribbon, which they just assumed would be there. Of course, there were customers who told us they were not going to upgrade, but for any release only about one-third did anyway. That was another problem entirely, and all the Ribbon offered was a convenient excuse that went beyond budgets, IT strategy, something else.

Personally, this release was the confidence builder I needed after a challenging Office 2003. It felt great to build the hot or at least interesting and innovative product people were talking about. This came at a good time for Microsoft given the Longhorn chaos and the cloud over the company due to the regulatory settlement.

Anil Dash was early in popularizing blogging (today he would have been called an influencer). He authored a post I loved. It read, “Short and sweet, the Ribbon and new UI in Microsoft Office 2007 is **the ballsiest new feature in the history of computer software**.” [asterisks in the original]

He also captured the risk that we felt for the preceding two years:

Now, most of us who like to prognosticate and pontificate about software like to say things like “It’d be easy to just . . .” or “It’s trivial to add . . .” but the thing is, most of us aren’t betting our entire careers on the little tweaks and changes we’d like to make to our productivity applications. Try making a mistake that jeopardizes a business that makes $250 million a week.

But something else was on our collective minds.

What came after the Ribbon would not be more features in traditional desktop apps, but more internet scale services, more use of the browser and mobile, and more connections to data. We built the equivalent of the Cutty Sark, the best of wind-powered clipper ships. Steam-powered ships were coming, however, in the form of smartphones and mobile-cloud computing, as long-time industry analyst Benedict Evans would later write in an essay “The best is the last.”

The era of formatting documents was ending. The Ribbon was a new paradigm for desktop computing (what we called Win32 apps) in a world rapidly being overtaken by the web.

We were also approaching the end of an era of software reviews. We could sense that as we went out on press tours. There would not be another release where a magazine would devote dozens of printed pages to Office, or Barnes & Noble would have a shelf of Office books. One review mattered above all for me personally and that was by Walt Mossberg at The Wall Street Journal. It wasn’t just that he was the most influential reviewer, though he arguably was. Others would review every feature and have dozens of screenshots. Walt spoke for the typical customers, the non-techie, the person who just needed to get work done without futzing. Winning that review meant winning over that customer, at least by proxy.

No one expects a perfectly glowing review of any product from Walt because he makes a point of raising concerns that normal people will have from learning, to new file formats, and even the pricing. That said the headline alone was huge for us and it was a big enough deal that the WSJ placed it on the front of the business section with color screenshots— “Bold Redesign Improves Office 2007.” There was that word, bold, just like we aimed for at the start of the release. He went on to write:

So, when Microsoft makes significant changes to Office, it's a big deal. And the latest version of the software suite, called Office 2007, due out Jan. 30, is a radical revision, the most dramatic overhaul in a decade or more.

I don't use the word "radical" lightly. The entire user interface, the way you do things in these familiar old programs, has been thrown out and replaced with something new. In Word, Excel and PowerPoint, all of the menus are gone -- every one. None of the familiar toolbars have survived, either. In their place is a wide, tabbed band of icons at the top of the screen called the Ribbon. And there is no option to go back to the classic interface.

. . .

If you'd like to get more out of Office, especially in the area of how your documents look, Office 2007 is a big step forward and worth the steep learning curve it imposes.

Of course, I personally fixated on the places he was critical. For the team this was a huge, huge, win.

While we gave new life to Office with the redesign and we created a foundation to continue to evolve the product incrementally, the next wave of innovations would (and should) be entirely different products. We disrupted ourselves. We made the previous releases of Office look old and underpowered. OpenOffice would continue to chase the old design, and the soon to be released Google Docs would do the same.

The world was changing though, and we knew it. It wasn’t just the reviews going away or the rise of the web for consumption. In November 2005, just before the MYR process detailed in this section, I wrote the framing memo as I always did for what would be called Office14 (yes, we skipped Office13 though I was careful to note that 13 is unlucky only in some cultures). In Aligning for Office14, I described five “Big Bets”:

The big bets we will explore as we begin aligning the team for Office14 include:

* Moving Up the Value Stack

* Office Web Companions

* Internet (Web-Based) Services

* Building on Windows Live

* Office's Enterprise Content Management Platform

The first bet was about enterprise computing, as it should be. My heart was in the second bet, which was to build Office for the browser. I received immense pushback for suggesting such heresy. Often people used against me my own argument from years ago that the browser wouldn’t work for “real productivity.” The trajectory we were on was now clear and the time to start was now.

To ease people into the idea, I positioned (so cleverly, I believed) the idea of building Office for the browser as “companions” to Office and called them OWC, the Office Web Companions. As companions versus competitors or replacements they would not risk cannibalizing the real Office. The other challenge within Microsoft was the view that corporations would be running a Microsoft-centric “browser-based” platform using much more capable technologies that relied on proprietary Windows Server and Windows Longhorn such as successors to ActiveX. The broad consumer world would be running “web-based” solutions in a least-common denominator browser (a phrase always used when referring to HTML.) It was a subtle difference in wording with huge implications strategically. So I danced around both as I wrote and then evangelized the memo.

I was very excited to build on our 1990s strategies of embracing the web with HTML and then Office Web Server. I was already dreading what was sure to be a significant uphill battle across the company, not unlike what we had faced in building Office 2007 or using HTML or creating SharePoint. The company had a strategy and these bets seemed to run counter to it, but only at first glance. I thought a good deal about how Windows rose out of what was often branded internally as a side project, operating environment, or experiment.

It was going to be a journey to disrupt the desktop applications, but we needed to start.

My direct reports and our significant others gathered for a dinner at Assaggio Ristorante in Seattle to celebrate the final beta release. I hardly ever asked people on the team to do things outside of work hours, but this release was so special.

Months earlier in just a hallway conversation, Richard Wolf (RWolf), manager of PowerPoint and Visio, said that it was cool that the “last” release of Office was the one with a major UI redesign—it was almost poetic for him to say. Richard was the productivity philosopher among us, having worked at Lotus before Microsoft, a reflective person, and an early member of the academic community focused on productivity. He was right. There was no reason to think there would ever be another major redesign of Office that was necessary.

Innovation is like that. Microsoft was built on the idea of creating, grinding out improvements, then moving to a new platform to innovate. We were at that point. Everyone could see it. It was as if we each felt it in our own way. We had accomplished what we set out to do a decade and six major releases earlier.

We shared a toast (of a beverage of choice) to what the team accomplished. We were proud. And we were happy. We built the very best version of Office—a reinvention of the product—in a way that had never been done.

For most of the seasoned leadership team at this dinner, this was going to be their last release of Office. I think we each knew that.

Things were about to change for me too. As happy as it was at the time, it was also a bit sad. There was always a bit of a low after shipping. The grind of building suddenly stops. A sense of mission accomplished takes over. Also, I just turned 40.

Unbeknownst to me at the time, this would be my last release of Office. Something I never even considered.

That Office14 memo was my last work on Office.

On to 083. Living the Odd-Even Curse [Ch. XII]

We’d been working on Office12 for almost two years and the product had made enormous progress. The team was buzzing, and everyone was very excited. This product was different. We were building something we could all feel. It was a product that was good for individuals, not just organizations. Still, no one outside the company had seen it or knew of the monumental changes we were making. The user interface in Office was not just a user interface for the PC, for many many people for the past 15 years it had been the interface for the PC. We were quite confident. JulieLar was confident and prepared. This was a big moment, the first public showing and then the first feedback.

Back to 080. Progress from Vision to Beta

The first lesson of interface redesign: Do not unveil the design with static pictures.

The second lesson of interface redesign: Do not unveil the design with static pictures.

At the 2005 Professional Developers Conference (PDC), Chris Capossela (ChrisCap), Corporate VP of Information Worker Marketing, joined BillG on stage for a sweeping demonstration of Windows Longhorn along with the first public reveal of Office “12” (the quotes with a space became the official way of writing the name). ChrisCap and the marketing team zeroed in on the positioning of “Better results, faster,” while also pointing out that Office was “New, but feels familiar.” The demonstration zipped across Excel, Word, and PowerPoint, showing all the elements of the redesign and dozens of new features, along with many others previously undiscoverable. I was sitting anxiously in the very back of the room gauging how people reacted. I did not have to listen too carefully as during the demo someone shouted out to the stage, letting everyone know how they felt.

“Ship it!” they yelled.

We were still two months away from the first public beta, but this felt good. Only afterwards watching the tape did I realize we were being made fun of. Chris inadvertently missed a beat in the demo. His words describing what should happen did not match what was happening on screen. It looked like a bug and “ship it” was a classic Microsoft reference to shipping something with bugs. Nevertheless, the reception for the demo was quite positive.

The excitement spread through the industry.

Technorati, a tech news site that measured the important or high impact blogs on what was then called the blogosphere, was the place to be seen in the press. Our redesign made that home page, a first for plain old Office.

Despite the excitement of the moment, we learned a good lesson.

The video of the keynote was posted, but in 2005 not everyone was hip to consuming video. That meant that the still images (from Treo phones and the like), screenshots from the event, and JensenH’s later session made their way around the blogosphere. That proved to be a mistake. The spread of simple static screenshots for such a major change in user interface was not the way to communicate the redesign.

Almost immediately we were confronted with a wave of comments proclaiming the Ribbon to be too big and that it took up too much of the screen—assertions made by comparing screenshots to the current version of Office and making snap judgments. Attendees at the developer conference were counting pixels but not considering the full scope of the design or the experience. Besides, there really was the same amount of room for content—that was a key point of the design.

We did not anticipate this level of dissection, and that was a mistake. This immediately reminded us, especially JensenH, of his redesign of Outlook and the furor over the layout. Recall from the previous chapter that we had a spirited debate among early testers over whether the layout displayed fewer or more email messages. The question being asked was whether the ribbon took up more space than the toolbars and menus previously there.

We had some work to do.

Lost in all the comments about how big the Ribbon seemed to appear was the fact that we eliminated the row of menus entirely. Some comments and blogs slowly absorbed that reality over the course of the day as the magnitude of the design began to sink in. The Ribbon was not, as people thought by looking at a static screenshot, a big, fat, tabbed toolbar. It was so much more.

Also missing from this discussion were the differences between tech enthusiast or developer use of the product and typical users. We knew the typical user interface experience from instrumentation. Most users ended up with two rows of toolbars, the main menu, plus toolbars floating around the screen, and the side pane (that innovation from Office XP) each obscuring the document or squeezing in on the user’s work. By contrast, a very small number of tech enthusiasts prided themselves on purposely designing and maintaining a very select set of commands, often in a single floating tool palette (itself a very poor choice unless you have a giant screen, which many developers did). This was not the real world or even the base case, though we would eventually craft an answer for even this hyper-customized form of user interface.

In hindsight, letting the static shots out without video or animation was a rookie move that we corrected eventually. We were at the earliest days of real-time reactions to product launches.

Microsoft had recently begun using video as a means of connecting with the tech enthusiast community. The Developer Relations Group (DRG) created an online video site, Channel9, hosting videos with product leaders from across the company. JulieLar initiated the ground-level engagement as a companion to the PDC by recording a casual and friendly 40-minute discussion along with demos from her office. This video made a huge difference and began engaging the techie crowd with a good deal more information.

Simultaneously, JensenH began his new blog. Blogs were the rage among product leaders. Many of us maintained “external blogs”, or blogs that were visible to anyone, something that seemed risky for big companies at the time. Jensen shared his first Office12 posts after his PDC afternoon presentations. The blog was titled, Jensen Harris: An Office User Interface Blog. Portions of his blog can be found on a Microsoft site with a table of contents, but unfortunately Microsoft changed platforms and all the images have been lost. https://docs.microsoft.com/en-us/archive/blogs/jensenh/table-of-contents (individual posts can be found on archive.org).

JensenH had many talents beyond his obvious software skills and his regular performances with the Seattle Symphony. He was also a fantastic writer, a style he honed while writing a column in high school for USA Today. His posts detailing the Office12 redesign were not only incredibly well executed but ultimately served as a model for how a product could and should engage discussions on building software at scale. Through the course of the remainder of the release, and even today, these posts serve as reference materials for one of the most substantial redesigns Microsoft ever undertook (so far!). While obvious today, the press and reviewers were also following the posts carefully—something we took note of and proactively communicated with them. We never edited, cleared, or otherwise scripted posts. Jensen did this all on his own and under his own supervision, with the goal of detailing “why we’re changing the UI, not just how we’re changing it.”

Incidentally, this became another story of an Office process spreading virally across the company. I was often asked to point to the team in marketing that was doing our blogging and to the blogging strategy deck. It was one of those moments when I recognized parts of the company were scaling or growing up differently than Office. In other parts of the company, something like a blog would be a team, a budget, and a process with meetings and so on. We had none of that. It was just JensenH (and others) writing. We’d occasionally talk about topics to cover but otherwise it was an entirely organic effort. The key was that there was no strategy or oversight or overthinking, but just telling the actual story of the design and responding to the legitimate questions about it. Nevertheless, Gavin Shearer (GavinS) on the product planning team wrote up a blogging whitepaper so the rest of the company asking could see that we had some structure. Gavin met with several of the team’s bloggers to see how they worked and turned that into a guide for the future. It makes for an interesting historical record contrasting with today’s carefully crafted and managed communications. It served as a foundation for how we would later manage the larger task of writing about Windows (more on that soon).

Among JensenH’s first posts about the Ribbon were pixel-by-pixel discussions of the size, even discussing alternatives that had been suggested in other articles and comments. In a post called “Mythbusters” (the TV show with the same name was popular at the time) he helped readers to see why the Ribbon was far more than a fat toolbar or why the layout was organized by usage frequency and scenario, not implementation category. For each of the main areas of innovation in the design, Jensen walked through in detail the design in a calm and factual tone, along with humor, and colorful (and embarrassing) comparisons from past releases of Office. The posts were wildly popular and served as a model for much of the future blogs our team would author.

The two months from the PDC to the technical beta went by quickly—a good deal of product work was needed, but time flew by because of the incredible interest in what we were cooking up. Fairly low-key beta tests were the norm and only moderately interesting. Suddenly techies clamored for access to the release, which we limited because of our own views of quality and inability to support full-time usage of the product.

We got some early instrumentation on usage that started to confirm much of what we hypothesized with respect to the design (noting that these early users were intentionally trying out many parts of Office they might not routinely use). Those who got hold of the beta were clearly exercising a lot of the product and trying it out. It had been a long time since there was so much excitement about a pre-release version of Office.

In November, we released the technical beta, which was open to developers, enterprise customers, and the Microsoft MVP community, Most Valued Professionals, who played a key role in the beta process of the Office12 redesign. Most enterprise customers did not tend to pick up early technical releases for evaluation.

Who are these MVPs? We were briefly introduced to this group of supporters when they initiated something of a protest against the new Visual Basic .NET, referring to it as Visual Fred because of the lack of relationship and compatibility with their much loved Visual Basic. As we’ll see, compatibility and respect for the past are super important to MVPs who pride themselves on deep knowledge of Microsoft history and products.

The MVPs are an elite selection of consultants, educators, writers, and generally independent thinkers who are deeply committed to Microsoft products. Each of the major products has a group of MVPs from around the world assigned to it, with the MVP program managed by a central corporate team. Becoming an MVP involves a rigorous nomination and selection process along with reapplication when a term is up. MVPs take great pride in their role and commit significant effort, and often their livelihood, to Microsoft products. It is such a big deal that most readily identified their MVP status in email signatures, resumes, business cards, and today on LinkedIn profiles.

The MVPs are super important to the product once it is released. Many books, training videos, and courses on products are created by MVPs. Many command large audiences online and are the key creators of how-to content in many forms. While the program is centrally administered, including a yearly MVP conference, the product groups all have people assigned to serve as liaisons to their MVPs.

Over the years, the Office MVPs grew a little anxious in that they generally felt they did not receive enough insider information on planned features and ship date. My sessions with the MVPs sometimes had a bit of an edge because I did not use the forum as the first or earliest disclosure event. There was frequently some tension between the promises made by the managers of the MVP program and the product groups like Office in how they positioned the program relative to disclosure and influence on products. Office was perhaps unique in designing for a broad audience of many stakeholders. The most engaged MVPs were like the close-knit IT managers the Windows Server team managed with minimal risk to their IT-focused disclosure and business. I was always cautious of over-indexing on specific customers, especially when we knew they were a deviation or two from the typical user. One of the more challenging aspects of Office was how everyone tends to believe their use is widely representative of others, even software professionals who know this tendency but sometimes have trouble resisting the temptation to represent themselves.

I wanted to find a way to address this gap while also recognizing our responsibility to enterprise sales and customers. Regardless of the forum, I never wanted to be in the position of over-promising with a risk of under-delivering. I strongly believed sharing was committing and failing to deliver to customers had a high cost. Before the November beta, at the yearly gathering of MVPs in Redmond, we had a special session for the 50 or so Office and SharePoint MVPs.

They were invited but didn’t know it was special.

After JensenH did a never-before-seen talk on the Ribbon, I walked to the front of the large meeting room and sat on the speaker’s podium at the side of the stage.

“There’s a feature in Office that everyone has wanted forever and been asking about for as long as I could remember,” I said. It was a feature all our competitors provided, and some even claimed it to be a huge advantage over Office. I continued, “available in the public beta in a few weeks, Office12 would provide full support for saving files in Adobe PDF format.” We simply called this Save As PDF, exactly what everyone would have called it no matter what we named it.

The room went crazy.

I hopped up onto the stage and showed a click-through demo of the feature working exactly as expected. PDF was another file format option in the File Save As flow. I showed PDF in Publisher, Visio, and Word.

In today’s context this sounds supremely dumb. How could our best and most informed users get so excited over PDF? Today PDF is an utter commodity. Everyone uses PDF and no one thinks for a moment if it cost extra. Companies from DocuSign to Google and every institution from banks to hospitals and every government create PDFs and enable their customers to create PDFs. Every browser supports PDF. Every tool creates PDF. But in 2005, Microsoft alone was not in the PDF business yet the whole world was using Microsoft creation tools. It was a big deal, and the world was a silly place.

I then shared that the work was done by the Publisher team and they took on the work to implement it in all the Office applications. At the time, it was a remarkable maze (or thicket) of legal and regulatory challenges: a feature that our competitors supported, that utilized an open and published standard, and that was an entirely obvious customer need. We were receiving more than 30,000 comments per week on our own Office website requesting PDF support. The code was only half the battle. Would regulators view PDF as anticompetitive? Would implementing PDF in Office and not charging money for it be predatory pricing? What would Adobe think or even do? Would there be intellectual property challenges?

It was this last concern that kept us awake. A patent dispute claimed against Office got very expensive very quickly.

Adobe invented PDF more than a decade earlier. Recall, when I was working for BillG, the idea of creating viewable files was a key initiative passed on from my predecessor. Even before PDF, BillG did not want to do a file format that could not be edited and still did not. Adobe distributed a free PDF viewer on every computing platform, but to create PDF required a license, except on Steve Jobs’s NeXT operating system where it was built in (and thus eventually on Macintosh and iPhone too!). Over time, however, as the internet made PDF more useful, Adobe got pressure, especially in Europe, to make it possible for third parties to create PDF legally, for free. This was already happening, but technically such work risked violating the PDF license or intellectual property. Adobe, perhaps a bit too clever for its own good, published an open specification in a European standards body. We built our feature using only the open specification in a metaphorical clean room.

Adobe was extremely concerned by our support even though we relied exclusively on their open specification submitted to the European standards body.

Except we were Microsoft. Even our largest and soon to be most evil of competitors, Google, and our main Office competitor Sun, were using PDF to compete with us. In fact, the only way to print a document created with Writely, the browser-based word processor that would be acquired by Google, would be by outputting it to PDF which they announced shortly after this event. OpenOffice created PDF by a simple Save As command.

It was the peak period of fear and the assumption that everything we did had a potential for an evil twist, and as such the legal team was predisposed to capitulate to any regulatory skepticism by simply not shipping a feature. In fact, Save As PDF was completely benign and customer driven, but in the climate our motives were always questioned. Erich Andersen (ErichAnd), our fantastic head lawyer for Office, Alan Yates (AlanY) in marketing, and many others spent weeks briefing regulators, trade press, industry groups, standards bodies, and more, laying the groundwork for the feature. ErichAnd spent countless hours with his fellow Microsoft lawyers and those in the antitrust group convincing them we were on firm ground and delivering PDF was going to be OK when their reaction was to avoid regulatory scrutiny at all costs. Perhaps the biggest lesson from the regulatory era was that a company in a dominant position can’t always do the things that are perfectly acceptable with a lesser market position.

We were so worried that something might backfire in the antitrust or patent worlds that we designed the feature so we could easily remove it with a small update or reissue Office without the feature. If any party chose to litigate, it would not do so until after Office was commercially available to maximize the inconvenience for us and the damages owed to them.

Still nothing is ever easy, suddenly all those working hard to create or use our expanding XML file format were concerned we were sending a mixed signal to the market. XML was intended to support some of the scenarios PDF could, at least technically. The program managers working on XML authored a series of clarifying mails to be shared with the field on this topic. Under the hood, a key initiative for Office12 were the new XML-based file formats (the “x” in .docx, .pptx, .xlsx). These formats would eventually be published as open standards as well, a fact we also used to deflect any potentially conspiracy theories regarding our use of PDF.

One other wrinkle was that the Longhorn team was doing its own PDF competitor, called XPS (of course the X stood for XML in XML Paper Specification). We used the same code path we created for PDF to support also XPS. Peter Pathe (Blue) the VP leading the effort let the Windows team know we would support XPS, which they had previously pleaded with us to do. They were very excited to hear the news, but their excitement was considerably tempered by our additional support of PDF. Supporting both reinforced our claim as Office that we were trying to help customers by including multiple technologies.

We prepared an enormous package of briefing materials—all for a single feature. We had a whole media plan, Q&A with me on Microsoft’s main web site, a long set of RUDE FAQ especially over the Longhorn XPS format, and even a draft email to send to influential press and partners. It was a production.

Save As PDF was so popular that it quickly became part of the standard demo flow—a feature that exported a document out of Office, not into Office.

Save As PDF was very well done. We supported all the key features of PDF, such as accessibility, fonts, images, and more. Never had we done something so obvious and yet so difficult to release to market. The fact that the lightly resourced Publisher team delivered PDF was a special bonus, and development manager Ben Ross (BenR) did an amazing job. PDF support, through the work of people on the Publisher team like Cherie Ekholm (CherieE) in test and test manager Tammarrian Rogers (TRogers), also furthered Office efforts in accessibility and worldwide government standards.

We received emails extolling the virtues of Save As PDF from dozens of MVPs. It was so rare in a business of our scale to deliver something so immediately positive without cynicism or skepticism. The most elite members of the press from Walt Mossberg at the WSJ and Michael Miller at PC Magazine reached out to congratulate or mostly to thank us for adding support. PDF was crucially important to their workflows, and this made their lives simpler.

It is weird to think, but a feature that seems so dumb today was easily the most friction-free and joyous addition to a product I think I ever did, except maybe for the widget that counted compiled lines in Visual C++ that made everyone think the product was faster. Peter Pathe (Blue) our VP of Word and Publisher overseeing the work was equally happy, especially considering his own personal history in typography and publishing technologies, not to mention studying at the MIT Media Lab during the heyday of e-books.

A few weeks after the MVP conference, the Office technical beta was released. The MVPs received a lot of attention and were anxious and ready, and also feeling good about the insider scoop they received. This would be the first time anyone would have their hands on the code to use day in and day out—and the product was ready for that.

Once the Beta went out, we immediately began monitoring the private newsgroups (using the old NNTP protocol) the MVPs used to talk to each other—these newsgroups were the closed-door and NDA (non-disclosure agreement) meeting place for MVPs and part of what they valued most about the program. The product groups were on the hook to monitor the dialogs and respond to issues. The Beta proved to be the source of many emotional and heated discussions.

The good news was that these discussions were mostly the arguments we heard following the PDC. The MVPs were a slightly different crowd than the PDC developers. They were dedicating their careers to Office. They had a lot to discuss.

Almost immediately we were again (!) confronted with the feedback that the Ribbon took up too much of the screen. They were sending us screenshots of their customizations of Office—carefully removing much of the default user interface and relying heavily on keyboard shortcuts. To such a setup, the Ribbon was huge and wrong. Some showed us their dual monitor setups or how they arranged windows for multiple documents on a screen in skinny columns that did not work well for the Ribbon. Others had wide screens and sent us proposed renderings of the Ribbon oriented vertically on the screen to “save screen real estate.”

We recognized that many of these were personal preferences. We knew we were making a major change and major changes that undid knowledge of the most knowledgeable power users almost always received significant pushback. Through the course of this writing, I’ve shared several such stories such as the introduction of the new setup technology in Office 2000.

We filled our replies to the comments with data from our telemetry about how Office customers used the product: the screens they had, the number of toolbars and task panes that were routinely visible, and so on. At each juncture, the discussions devolved to a point that we were asked for options: options to move something around, hide something, or be able to change something. This was a normal reaction to change. Essentially, those resistant to change do not battle the change as much as request the ability to not experience it. . . to turn it off and go back to the old way.

Articulating that the redesign was a programmed user interface, like the cockpit of a plane, not a set of parts to be assembled, was our challenge—essentially rethinking the ancient design point of a customization-centric product. We changed the whole model and made it much more productive, and, in a real sense, moved the customer base (not only the hardcore technical users) to a higher level of expertise and mastery. We did this the very same way the graphical interface itself made software easier, by improving the abstractions. The graphical interface technology of pull-down menus with a mouse replaced arcane and seemingly arbitrary keyboard shortcuts of early character interfaces. The Ribbon replaced the user interface that essentially mapped every feature directly to an implementation and constant document debugging and futzing with higher-level abstractions that regular people could understand.

There was one raucous private newsgroup debate that came to symbolize the challenge of the thesis of operating at a higher level and even of the Ribbon itself. It started when one of the MVPs posted a message ranting, sorry raising the feedback, about “sub-second keyboard access.” The post explained that the reason the Ribbon wasn’t satisfactory was because it required the mouse, and what was needed was sub-second access to any command. MVPs often customized Office to provide unique and highly tuned access to commands. With the Ribbon this level of tuning was not (yet) possible. The MVP simply stated:

Advanced users have ***got*** [emphasis in original] to have convenient -- that is, sub-second keyboard access to all dialog boxes and many common commands. Without that capability, Excel 11 never will be uninstalled, because using it will be so much more efficient than using Excel 12.

As challenging (annoying, actually) as the comment could be interpreted, I resisted the temptation to immediately dive into the debate, as I was often impatient with this type of comment (threat) from insiders. I would forget to remind myself that while we had debated these very points for the past 18 months, the MVP was seeing everything for the first time. Instead, I commiserated down the hall with Billie Sue Chafins (BillieSC), one of the key program managers on Julie’s UEX team, reporting to JensenH. Billie Sue moved over to UEX from JeffO’s web services team where she was hired in the middle of the Office XP project. Like many (but not all by any stretch) program managers, she was a trained computer scientist, having put herself through school after moving from rural Kentucky, where she was born and raised. Unlike most program managers, Billie Sue was also a teacher, having been a university lecturer of computer science before heading to Microsoft. As a key member of the UEX PM team she was in a perfect spot to drive engagement with the MVPs who were extremely interested in the Ribbon. Billie Sue kept an eye out for hot issues and made sure the team was handling the traffic.

The “sub-second keyboard access” feedback stumped us. Once when I stopped by her office, we looked at each other trying to understand what that could possibly mean, because no one could type and execute commands that quickly. She knew debating the premise of his question would be futile. When forum participants smelled weakness, a pile-on followed. Suddenly, everyone needed “sub-second keyboard access.” Billie Sue drafted one of many responses on the thread and eventually provided enough data on usage, customization, and more to at least explain why the design worked.

The larger point she made was how the design committed to providing full keyboard access to all the commands, without having to customize the product to do so. In fact, part of the innovation of the Ribbon was to make sure everything was accessible via the keyboard. In addition, she pointed out that existing keyboard shortcuts remained compatible and customizable. This thread gave Billie Sue the opportunity to acknowledge the feedback and commit to improvements. We already planned on having full keyboard access. We just did not have it in the technical beta.

For every “sub-second” post, however, there were many threads not only defending the Ribbon and experience but calling it brilliant. Some of the more entertaining, if not parochial, comments asked if the Office team might go over and help the Vista team out. More on that later.

Customization continued to be a topic in the newsgroups simply because the MVPs were the people who customized the product the most. The data we offered showed how few people customized (or how often customization happened by accident and could not be easily undone), but there was no telling that to an (or the) audience of customizers. Experts always want customization options, but options have an enormously high cost in the short and long-term that impact customers as much as Microsoft. This is especially true when it comes to customization of user interface—something we were freshly experiencing as we worked to fully support the customizations that developers had become used to for creating custom applications hosted within Office. What doesn’t make the product too complex today, will certainly make the product more complex tomorrow when the combinatorics of all the various customizations conflict with each other. What always seems like a simple preference or switch turns into a testing and compatibility matrix from hell.

We were in the earliest stages of the design of what we thought of as a customization escape valve, a place for those strongly committed to customization or, frankly, where the usage model was so far from typical. The Quick Access Toolbar (QAT) was a row of buttons that could be turned into any command from anywhere in the product. The MVPs could have full customization control over this feature. I admit to forcing an expansion concept of the QAT on the team for the power user customization scenario. It was kind of ugly and broke the model, but it was also a life saver with a specific set of customers. The brilliance of how the team designed the original QAT was how minimal the impact was on the overall Ribbon model and design.

The QAT, which is the tiny little row of buttons at the top-left of the title bar (at least through Office in 2021), had buttons for Save (the classic disk icon), Undo (the back arrow), and Redo (the forward arrow). The QAT was meant to have the very top used commands always accessible regardless of what part of the Ribbon was visible. We were so worried about how dumb it might look for Save (of all things) not to be visible since it was from the first toolbar, that it was placed in the QAT. Much to the disappointment of HP, printing began its slow decline in the early 2000s and given the telemetry it was not on the QAT.

Surprisingly, none of the participants, so many well versed in history, drew the analogy to a feature in Macintosh Word called the Work menu (I believe going back to version 3.0 in 1987, the second Macintosh version), which was precisely the same idea—a menu that could be customized to contain any command in the system. Sometimes what is (very) old becomes new again and is even better when its reemergence goes unnoticed.

In the very early days of Excel, a command called “Set Print Area” was moved off the File menu and it immediately jumped to the top of the customer support call issues (today this command is mostly automatic, but also readily available in the Ribbon). Fast forward to 2007, JulieLar and I were invited to join with a Harvard Business School executive education session being taught a case study on the user-interface redesign. The students were asked to prepare their notes for class using brand new Office 2007, which none of them had yet been using given the pace of corporate deployments. As soon as class started a student/executive raised their hand and asked Julie “How do I print?” as the rest of the class groaned in support. The omission of a Print button on the initial QAT might have been the biggest oversight of the entire project. It was certainly an embarrassing moment.

The beta was solid enough that thousands were using it every day, and it was clear more of the product was getting used, quality was high, and we were on a path to finish. This, however, was the technical enthusiast audience.

Our next step was a broad release, including the core business users, specifically IT managers, who generally didn’t react well to change and could be very vocal about it. The press and reviewers would also be testing out Office12 and most of them used Word and Excel for hours every day.

On to 082. Defying Conventional Wisdom to Finish Office

This section tells the story of a plan coming together and the breadth of the release. We did have a bit of a speed bump early on. I was told to align schedules with Windows Longhorn (the next Windows release). The difficult reality of Longhorn had not yet sunk in. The new user interface for Office12 had surprising upsides. While we were confident, we did not know at the time just how positive the changes in Office12 would prove to be.

Back to 079. Competing Designs, Better Design

Organizationally, we had become a (relatively) well-oiled machine. Procedurally we knew how to work. We also knew what was required at the high level and individual teams knew how to fill in the details with plans. Writing this all down and communicating to the organization a product vision—the vision for Office12—was the next step.

Transitioning from Office 2003 to Office12 was happening across more than 2,500 engineers. In every respect we were building a coherent and collaborative plan with little dirt flying and no injuries, as the old MikeMap description of Office went.

By spring 2004 we had a complete product plan in addition to the user experience redesign described previously. Even with excellence of execution, this was not a lather, rinse, repeat release. Collectively, we learned some lessons from the previous releases. We learned more is not better, and that it was time to rethink, or, as we said in the vision, redefine the user experience. We learned that blindly following the enterprise path could lead to stasis, and in technology failing to innovate or standing still was equivalent to going backwards even when the best customers were telling us of the high costs of change. And finally, we had a firm grasp of how the product was going to evolve beyond document creation—the role of servers, services, email, and more were all important parts of Office12.

The question was not whether we had a good plan or even if we could execute, but would the results live up to our goals. . .finally. There was also a huge risk to making a big bet on changing the user interface of the product—an incalculable risk. It is the kind of risk you either accept and go for or don’t try at all. Many people inside the company, and even on the team, immediately saw the risk of such a big bet and absolutely wanted to know the risk mitigation plan. There wasn’t one. Any risk mitigation plan would only result in a compromise design, because at every step someone would be saying not to worry, we always have a fallback. Backup plans on big bets have a way of permeating the whole product development process and ultimately deny the resources required to achieve the goals, reduce the appetite for risk, and simultaneously dilute the efforts to achieve the bet itself.

From my perspective Office12 was all about that opening sentence of the vision document and a single slide shown at the team meeting for the vision. It read, “No More Good Enough,” with a big red circle slash. Surrounding that PowerPoint SmartArt on the slide were reviewer quotes about bloatware and competing with Sun’s free OpenOffice, along with some juicy analyst quotes about technologies that still weren’t going to pan out. It was not that we set out to compete with a free product that had yet to make inroads, but we needed to reset the narrative that Office was complete, old, boring, and, worst of all, bloated. We had to show that there was deep thinking in the product and the paradigm of document creation was ripe for innovation, and by doing that we could demonstrate to the market that productivity tools were not commodities.

In the conventional wisdom of the day, Office was ripe for disruption. There was a less capable product claiming to be a substitute for less money. We took the initiative, intent on doing the disrupting ourselves and not letting something like OpenOffice, or our old products, do it to us. Not to race ahead, but one thing they don’t tell you about in disruptive theory is that losing to a head-on competitor is almost never what happens. Head-on competitors end up, well, running head-on into the entrenched product and that is exactly what happened with OpenOffice. Google’s future suite would initially make this same mistake, but we were at least a decade before they would begin to address that false start, and three years before even their first release.

The redesign of the user experience was more than one part of the product or strategy. It was so visible and so potentially disruptive that we knew no other aspects of the release would rise above it, certainly in the initial product reception from beta through release. Managing the team and project knowing this reality was JulieLar’s mission.

The overarching importance and the inherent risk of the redesign was not lost on the team. We had become accustomed to working together and collaborating. This was the sixth major release of the product and we’d been executing as a single team, not siloes of app teams, for a decade. The team was not fighting the shared redesign effort as much as it was rallying around it. As teams saw the design make it into the product, rather than point out how it might not work and cause it fail to make the point, teams came together to make it better. It wasn’t everyone at first, but over time that was the case. Among thousands there would always be doubters and honest skeptics, but mostly there were legitimate concerns that required more work.

Success has many siblings and failure is an orphan as the saying goes. Time has certainly reduced the number of doubters across the team and company. Those working on the Ribbon have many stories of people across the rest of Office and Microsoft expressing extreme doubt and risk, but those too have softened over the years as people came to realize the different roles people play during a time of change. Suffice it to say, some of the doubters were hardcore and neither quiet nor necessarily even-handed in criticism. The same could be said of supporters. Anyone going through a big bet with massive downside would need to learn this lesson. It would come in handy for me.

The product vision process really came together. After the very rough start for Office 2000 followed by the over-correction in Office XP, and then again by another over-correction back to enterprise in Office 2003, we hit stride. The process very much became our culture and defined a new way of building Office. The output of the process, after just a few months of planning, included a robust vision document—the plan—over thirty-five pages containing details for all critical stakeholders. We covered the breadth of the 4 Ps of the marketing mix across product, price, place, and promotion. From a culture perspective we dove deep into the core tenets of the release, the non-debatable points meant to streamline discussion and reduce debate. We did so in a unique Office manner by offering tenets that themselves often contradicted each other. I had a favorite example of that. We had one tenet “Security trumps everything” followed immediately by a tenet “Privacy also trumps everything” which was a clear message to the team to be smart about resolving issues even when they contradict. The goal of the vision was to communicate the product but to also serve as a decision framework—it was not a detailed product specification, intentionally so. The full set of tenets is quoted below.

Security trumps everything. No feature will be important enough that it justifies exposing our users to malicious code.

Privacy also trumps everything. Office12 will not compromise our users’ privacy for anything.

OS and Hardware requirements remain the same. Office12 will target the same versions of the OS as Office 2003.

No new system components. Office12 will work with the Office 2003 level of system components and redistributables.

Instrumentation for all features. Any work that doesn’t include usage instrumentation will be considered incomplete.

Performance counts. Performance of key scenarios will not degrade with the new version of Office.

Flawless forward compatibility. Solutions, documents, and other content from Office 2003 will migrate to Office12 flawlessly.

Office12 is a true language-independent binary. No language-specific work will be built into the Office12 binaries.

Full accessibility. Office12 will comply with the current and future accessibility and privacy regulations flawlessly.

Watson throughout the lifecycle. We will be addressing Watson issues throughout the development of Office12.

The main themes of the release provide insight into the cross-organization nature of the plan. We worked hard to keep the plan from reflecting the org chart. While obviously different scenarios had a locus of technology in the organization, by and large everything important involved multiple teams across Office. One challenge this process always had, and Office12 showed this as well, was addressing scenarios broadly defined as database or data access. This deeply technical area had many strategic partners across the company, but also a unique relationship to Excel, which organizationally shared an executive within Office. Interestingly, we always struggled the same way most modern-day data-intensive applications struggle. All data eventually ends up being pasted or opened as a text file into Excel. Figuring out how to avoid that manual step eluded us just as often as it did for customers or third-party software.

As with previous releases the teams created sketches of the vision by each product pillar as will be described. These sketches serve several key purposes. First and foremost, they are a tool for the team that owns an area to commit to delivering what is shown. These are not aspirational or directional but are supposed to represent commitments. The rest of the company was swimming in prototypes with a lack of clarity over when or if they were planned products or simply documenting thoughts. Second, the sketches served to inform the team about what everyone was working on and to provide a holistic view of the product end-state. Finally, these sketches help us to see the product end-to-end in a way that helps us to evaluate the plan for each customer segment. Ideally the sketches are not far off the final release of the product, just as the mock press release we created should be close to the real thing at the launch. With all the changes to the user experience, we did not have the production bandwidth to make sure each sketch had the most current designs, making the sketches a bit uneven in this regard. When I reflect on this, I’m glad we never over-produced the vision and importantly did not delegate the production to a distinct group, but rather we kept the low production values and saved our energy for the product.

The new user experience encompassed two vision areas. The first was “Redefining the Office Experience” representing the mechanisms and mechanics of the interface design. The second, intentionally the second, was “21st Century Documents” which emphasized the customer facing benefit of the design and the kinds of cool and important new documents that could be created. Having two big, bold, and modern goals as the first two was an intentional effort to up the ante.

The next vision area brought together our collaboration efforts for teams and enterprises, mostly SharePoint. By this time, the business of SharePoint was still catching up to its strategic importance. We still had far more traction with sales, marketing, and partners than we did with deployment and usage, but that wasn’t going to slow down iterating. It usually takes three times to get something right, and this would be the third release of the product.

For brevity, the remaining items are quoted below, including investments around data access which encompassed XML (again) and connecting data in SharePoint to desktop tools.

Redefining the Office Experience. Office12 will redefine the experience of using our applications through a bold new UI, more streamlined tools, and a deeper integration with the shell for system and document-level tasks.

21st Century Documents. In Office12, documents will not only look dramatically better but will also integrate much more efficiently and dynamically with the systems and processes of which they are part.

Effective Teams and Organizations. Office12 will fulfill the promise of group productivity, making organizations more effective through enhanced collaboration tools, better access to corporate assets, and stronger integration with the desktop.

Manage Your Time, Work and Relationships in One Place. Office12 will bring together improved e-mail, calendar, task, and contact management tools, enabling our customers to manage their time, work and relationships in powerful new ways.

Unlock and Incorporate Business Information. Office12 will make it easy for customers to collect, find, view, and analyze relevant data, communicate their findings to others, work together to make decisions, and measure the results of their actions.

Breakthrough Quality and Satisfaction. Office12 will be the most trustworthy and easy to deploy version of Office ever, and will mark a leap forward in increasing the value of our digital connection with our customers.

The Office12 Vision from March 2004 (not formatted for printing originally)

The schedule started in May 2004 (after shipping Office 2003 in late summer / early fall 2003). We presented the vision in March, giving everyone about 8 more weeks to finalize the specific features and development schedule for each milestone. While we were anxious to begin, a big risk landed on us at the last minute. The primary reason for this would be our old friend Windows and Longhorn.

Days before releasing the project schedule for Office12—not a schedule I just made up in my Office or DonGa the Office development leader dreamed up, but a consensus across the leadership—there was a panic about Office missing the opportunity to align with Windows. JeffR, the executive vice president of Information Worker products, called me to his office to talk about the late-breaking issue. We just finished Office 2003 and at the start of that release there was a fire drill to align schedules between Windows Longhorn and Office 2003. Here we were again being asked to align around that same Windows release, with our next release of Office. The optimism Windows had in late 2000 now had a couple of years of work and it was abundantly clear the project was not where it needed to be. My head began to throb.

The elephant in the room was once again the Windows schedule only this time it was their alignment of the Windows desktop and Windows Server releases. The Server just finished a release in April 2003 and Windows XP SP2 was still about six months from completion (partially why Longhorn was adding risk as well). While the core operating system was the same code for both the desktop and Server, the differences and additions created a bottleneck to getting both done on the same schedule. As a result, Windows had to admit that getting both the desktop and Server products done at the same time—something highly desirable from efficiency and go to market perspectives—was not possible. They put together a schedule with Longhorn desktop finishing in the second half of 2005 and the server shipping 6-12 months later, or second half 2006. Since Office had both server and desktop code, trying to synchronize that presented an immediate problem, besides the reliability of a schedule with multiple 6-month ranges built in. This seemed to me to be a rather theoretical discussion given the history of Windows ship date ranges (versus actual ship dates).

The approach I took was to suggest releasing in sync with Server (aka Longhorn Server) which aligned with our proposed RTM date based on the detailed vision plan of May 2006. That seemed reasonable given the stated goal of alignment with both. Most everyone was really irritated with me for lack of flexibility, which seemed odd given the constraints. Much to my frustration this came across as a desire to ship above shipping the right thing, even given the realities of the situation. I just had to accept this characterization and let events play out.

Writing this I am sure some recall what ultimately happened, at least the headline. The Longhorn desktop project would go through a big “reset” (they called it the Longhorn Reset) and eventually shipped in late 2006 for an official street date of January 2007 for Windows Vista. The Server team became frustrated and chose to ship Windows Server 2003 R2 (comprised of a Server 2003 service pack and optional components) in December 2005. The full Longhorn Server released in February 2008. As for Office, our May 22, 2006, date turned out to be aggressive and we ended up shipping on August 15, 2006. We were 12 weeks late.

Looked at another way, from the start of planning releases after Office XP in May 2001 and Windows XP in August 2001, Office shipped both Office 2003 and Office12 (Office 2007) before another release of Windows or Windows Server shipped. It is not unfair to say I received a ton of grief at the time for putting us on both the Office 2003 and 2007 schedules, which I still think was unfair as it was abundantly clear at the time how the schedules would unfold. Nevertheless, there is no joy in being in the right when others ran into problems.

The most interesting aspect of this type of history is to consider an alternate scenario. What would have happened if Office just slipped along with Windows? Would it have mattered if we never shipped either of those releases and just eventually aligned around what became Windows Vista (Office Vista)? From a business perspective, it is almost certainly the case we would have continued just fine due to the compelling nature of product-market fit as described earlier. Office XP could have carried us for another ten years, just as Windows XP could have (and sort of did). From a product development perspective, however, I could easily make the case that it would have been disastrous for Microsoft. Technically, we would have lost out on the long-term investments in servers and services, and a host of other important architectural efforts (including alignment with Exchange Server and the browser-based apps) so incredibly key to the anchor of today’s Microsoft Office 365. The much deeper impact would have been to the lack of maturity we gained in the product development process to operate at scale. The team would have just been wrecked. I don’t think I’m being dramatic to put that out there.

Rather than point out that we read the landscape correctly, I wanted to share what it felt like to plan and execute in this environment. These challenges were one thing faced from my position in Office and little did I realize at the time how important this experience would become as I moved to Windows.

With our plan in place and the whole team charging ahead with a great deal of energy and excitement, what followed was night and day from Office 2003. Where Office 2003 felt like a slog, perhaps bloated like the product, Office12 seemed to cruise along. While there were daily debates over the ever-changing interface, the fact that the product was changing so dramatically was, for most on the team, incredibly energizing. It was also nerve-racking. There were exciting moments along the way such as seeing the first right-to-left Ribbon design, as we’d ship to Hebrew and Arabic speaking countries.

Two of the more substantial issues the first two vision areas had to work through were performance and exposing more features of the apps in a manner that truly tapped into the potential of the new user-interface.

In terms of performance, we were pushing the limits of what thought would work in our apps. For the history of Office, formatting and changing the appearance of documents happened one single command at a time. Developers worked super hard to optimize this to be as fast as possible, but the user would only perceive it in extreme cases (for example changing a chart type with hundreds of datapoints). Live previews, a feature of the Ribbon, proved to be an enormous engineering challenge—never before had the products computed so many alternatives while a user simply hovered a mouse over choices. With a live preview, the Ribbon showed dozens of potential outcomes of applying a command in a gallery, while also showing the results live in the document, to save users from endless loops of trying and undoing commands. There were many opportunities for the product to be slow and non-responsive. Some on the team said the design was too difficult and we should abandon the hope of delivering previews. It would have been easy to give up. From a pure engineering perspective, live previews were an incredible accomplishment. For the press and reviews, the feature brought the strategy of results-oriented front and center making it very easy to visualize the concept. End-users could experience a whole new level of trying out a look without the dreaded undo-redo command sequence. Features such as paragraph styles in Word or new graphics capabilities in PowerPoint were brought to life in a show-me-first manner never before available.

Releases always have surprises along the way. Usually, the surprise is that the release is taking longer than planned. Office12 was the kind of release where the surprises were how much better things were going to be than even we thought. The battles, and I’m using that word on purpose, between the UEX team and the Word, Excel, and PowerPoint teams over how much to use the new user interface and for what features were difficult and really stretched the teams. The longer debates raged the less we could get done, and if you’re looking to not do something then a delay tactic is a great way to get to a point of “would love to talk about this more but at this point the schedule is locked anyway”. That’s an awful “process win” we did not like. Each time a new aspect of the user interface came online in daily builds, internal friction was reduced a bit and some cross-group cooperation was unblocked.

BillG always complained about the fact that each Office “module” (he always called them modules and we called them apps) had some form of tables, with different features and substantially different user interfaces. The Ribbon gave us a chance to bring similarity to these while also showcasing the depth and capabilities latent in the product simply because the user interface was too complex or inaccessible. By latent, the features were unused because people could not find them or did not know they existed. The Ribbon gallery made it so simple, trivial even, to have a fancy table with colored rows and columns, even totals by columns (who knew Word had spreadsheet formulas?). These were also consistent across the applications as well. It was easy to change and customize. Since almost every document and deck had a table, it was easy to spot an Office12 document from across the room simply because of the cool table formatting made possible by the Ribbon. To eyes like Bill’s, it looked like we had more shared code and aligned the implementations.

Across Word, Excel, and PowerPoint, documents were dramatically cooler and more modern (that was the word we used, and overused). The process of creating documents was blazingly fast, mistake free, and easy to change. Not a day went by when we were not blown away by the new capabilities of Office.

The design had a fascinating effect on new features. As the Ribbon was implemented, many features simply got better because of the way the Ribbon could expose them. In using the product over many years, Excel users developed clever ways to make cells red, green, yellow, or some other coding, depending on the values (if sales growth was negative then color the cell red). The manual steps required were laborious and automating this mysterious at best. The Ribbon placed new conditional formats front and center—with clear, colorful labels showing exactly what could get done with the gallery. Suddenly everyone easily added color coding based on cell values with a single click. This only made the new features even better such as cells with small up/down/sideways arrows or miniature graphs of values.

Surprisingly, ancient features were given a new lease on life and brought front and center. Generations of writers had long been traumatized by the ritual of pasting a picture into Word and trying to understand how to wrap text around it, or not. The Ribbon exposed the existing features for images and using the gallery made it trivial to select a picture and then choose among the set of choices for flowing text. It only took 20 years, but finally everyone could easily paste pictures into Word and make the text wrap around or align with the image.

This Ribbon dividend significantly improved the ability to market the product as both new and improved as well as getting more out of what was viewed as underutilized.

The team also set out to quantify the results of the Ribbon. It would not be enough for us to simply feel good or just know. The usability team explored every aspect of the design in our test labs. Hundreds of tests were conducted at the most micro and macro levels.

TBriggs on the user research team repeated earlier eye-tracking studies over the course of development, revealing how much less tiresome it was to find features. The deep red blob of eye-tracking marks was replaced by a calm and ordered browse of the Ribbon. Subjects left tests talking of how much less stressed they were using Office12 compared to the previous releases and how much less time they felt they were blindly searching for what might work. In general, people expressed much more mastery of the product rather than confusion or frustration.

Any change comes with a cost. While we knew learning would take time, encouraging news emerged. After the one- to two-week learning curve that caused diminished productivity, there was a significant productivity increase. People created richer, more expressive (and more modern) documents in less time. The increased use of the product translated into better work outcomes and more success with the very work they intended to do. This went beyond fancier documents, too—people created documents for a reason: to persuade, deliver bad news, sell products, run projects, and more. Doing so more effectively was a huge benefit to the information worker, even if economists were not able to measure this for a generation of PC users.

We loved the Ribbon.

By the fall of 2005, about 18 months after Vision Day, we were ready to show the work to the world, or at least beta testers.

These early adopters would have some feedback for us. If we expected them to simply fall into line and cheerlead, we were mistaken.

On to 081. First Feedback and a Surprise

A common belief in big companies with resources to spare is that innovation works better when there is a competition between multiple efforts with the same goal. It is a luxury most companies don’t have. If you’ve lived through competing designs, then you also know this is a horrible way to innovate and it is odd that such a process persists. When we began work on the redesign of Office, we wanted to iterate over designs quickly while also making sure we had multiple perspectives. It was not competing designs per se, but it had many of the same tensions. It was only through careful management that we ended up with a better design because we had multiple efforts early on.

Back to 078. A Tour of “Ye Olde Museum Of Office Past”

Microsoft always maintained a competitive culture. It started at the top and flowed down from there. Any doubts, ask one of the early morning basketball leaguers who played against SteveB.

Generally, one place we did not compete was on products. That was wasteful. To be sure, cookie-licking had a way of making it seem like there was competition, but those involved knew the reality. We’d seen IBM intentionally set groups after each other and it was ugly. Back when I was technical assistant, I had a call with an IBM technical assistant (a very different job it turns out) who asked me about how the company managed competing groups “so effectively” he said, and I thought he was speaking a foreign language (later I would realize from his view he thought of OS/2 and Windows as competitive, but we didn’t quite see it that way).

While competition rarely occurred across groups by building the products that were addressing the same goal, at times it happened accidentally, such as when C# and .NET evolved to bump up against Visual Basic, or even NetDocs taking on email after starting from a word processor. There were also technology transitions resulting in a current and forward-looking product, such as Windows 95 and Windows NT, which was not resolved until Windows XP. Originally Windows NT was a server operating system, but over time it became abundantly clear it was the future general-purpose operating system.

The Windows competition was painful. It was not particularly secret, but once NT went from a side project to a real product and then to the strategy it is fair to say the competition was difficult on all involved. No one who went through that would ever think about having competitive groups on purpose. At least if we did, we gained lessons in how we might go about it. The resolution of this situation was painful for everyone.

Microsoft’s culture was to avoid being wasteful of resources or internal energy, and to focus on one solution, getting to market, and iterating to get something right (in three versions or so). As we’ve seen when confronted with intentional redundancy, we typically dealt with it before products got to market. If there was a competition, shipping first was one way to fix it.

Many companies, like IBM, famously maintained cultures of competition. Often these companies sent two or more groups off to build solutions to a specified problem, frequently unbeknownst to each other, hoping a clearly superior solution emerged. For an engineer, that was an immensely frustrating approach and rarely resulted in a clean win. Executives had a way of looking at competing projects and determining that the best path forward was to remove the negative attributes from both choices and use the good from each. That forced merger of two formerly competing groups usually marked the start of a long, friction-filled journey to market. Worse, tell me the boss of the new merged effort and I could tell you the winning technology. Such was another reason to dislike that approach (incidentally, one thing we got right with the Windows 9x/Windows NT era was in moving code from one to the other).

The task of redesigning Office to address the challenges described was so high risk and difficult that it seemed sensible to try a few different approaches despite the difficulties of doing so. The questions were how to quickly try multiple designs and if one team could sincerely experiment in an unbiased manner.

The user interface was one part of Office12. The next section will outline the full scope of the release.

Julie Larson-Green (JulieLar), leading the UEX (User EXperience) program management team reporting to Antoine Leblond (Antoine), settled on investigating two approaches in parallel. Julie knew she wanted to experiment but was acutely aware we did not have a year to wallow in design alternatives. We shipped Office 2003 at the end of the summer 2003. We needed a couple of months on the engineering side to release worldwide products, refit the engineering process with improvements, and to plan on the next release. The rough schedule called to start coding for Office12 in early spring 2004. Less than six months to have a firm feature list, a robust engineering plan, and above all a new cross-Office design framework for a product used by hundreds of millions of people over the past 15 years. That’s all.

Julie’s Office 2003 team began iterating with designs before the release finished early in the year. The second design came from members of the team that moved over from Outlook in the late spring 2003. Movement across teams between releases was encouraged and planful, with program management starting moves a couple of months before RTM. Our resource realignment or reorg process was routine at this point and began uneventfully with a memo from me in late May 2003.

The two groups shared the same hallway with knowledge and awareness of each other, like OneNote and Word previously. JulieLar’s leadership on this project across all of Office would prove immense. Her own evolution as an engineering and product leader set the stage for this project, starting from when we met at a C++ event at Microsoft Press more than a decade earlier, through her growth to leading the engineering team that created Visual Studio (an outgrowth of single-user Visual C++), then on Windows through the chaos of the browser wars, and back to Office to FrontPage and the incubation of SharePoint Team Services, and most recently to the shared user interface team for Office 2003 (then called UIS). While decidedly among the best product leaders at Microsoft, it was her natural skills at bringing teams and people in conflict together that would prove to be the magic behind this risky and complex challenge.

The two teams were each staffed by very solid product leaders with strong but differing views on the evolution of user interface. The teams started from different constraints or assumptions. Julie aimed to arrive at one clear choice, not a nonexistent mix of two options or a committee compromise. That way the designs and specs could be finalized in time to start coding.

Few outside of Office fully understood the scope of the product’s thousands of features—the prevailing view was neither could anyone nor did anyone care about all of the features. While we (in Office) could light-heartedly make fun of our 4,000 different commands across five main products, with very few exceptions there were no other products out there that had such a surface area. The only thing that came close was the Adobe suite of products and perhaps Visual Studio, but both of those were used by professionals who were specifically schooled in those products. Even big web sites on the internet were no more complex than the online help for Office. Recall during the most recent redesign of the Office user experience (the introduction of command bars for Office 2000) we had a full-time program manager just keeping track of all the commands, buttons, and keyboard shortcuts. This was a huge redesign, a jumbo-jet cockpit level design.

The world-wide web introduced an entirely new metaphor to the world with blue underlined hyperlinks, big buttons, and a good deal of text. It was a radical departure from overlapping windows, menus, dialogs, keyboard shortcuts, and all the other widgets described in the previous section. A key question for Julie was should the web influence the new user interface for a productivity tool as expansive as Office?

One team was heavily influenced by the early design directions of Longhorn, the next release of Windows, which was at that point two years into its somewhat interrupted schedule due to Trustworthy Computing. Longhorn was starting to feel a bit of mission creep. Working to extend the traditional Windows desktop to incorporate weblike metaphors, the Longhorn design wanted to achieve the feel of browsing web pages while launching programs and working with files and settings.

The resulting designs made extensive use of textual descriptions and a task-oriented interface. Rather than verbs such as Save or Bold, the experience was much more like shopping on the web with categories like Collaborate, Share, and Edit. There were even command favorites (favorite commands?) and history like a browser, as well as buttons and menus within a wheel of commands, sometimes called a radial menu. A radial menu, a favorite of designers (and in movies), seems to surface every 10 years or so even though it has a host of problems with scalability, discoverability, and general ease of use. It also happened to be quite popular with the fans of pen computing.

One of the consistent challenges the Windows team faced was designing a user interface paradigm for all apps developers without themselves really having an app to design. The desktop, managing files and folders, launching programs, and the control panel are interesting but relatively minimal in scope (says this apps person). As discussed in the Windows 3.0 era, Windows benefitted enormously from the Excel team’s input into what was required of Windows.

The first Office team’s design, called OfficeSpace, felt futuristic—graphically it looked like something from a movie. The name derived from the generalized notion of a command space from Longhorn and happened to (perhaps by no accident) reflect on the 1999 Mike Judge film Office Space that quickly achieved cult status among Gen-X. It aligned with a stated direction of Longhorn, which was quite appealing. Alignment between Windows and Office was always viewed positively, especially by enterprise customers, even if we didn’t always deliver on the details. In early 2000s, aligning with Windows was still a prime directive from BillG. We had just managed the impossible, which was to ship Office XP and Windows XP in rough proximity and the XP desktop would rival the 2000 desktop in excitement from field sales.

The OfficeSpace team created a high-fidelity interactive prototype called Strawman. It had a feel of Longhorn with a good deal of text in the interface describing commands in a command well that was like a taskpane. It also, however, featured traditional toolbars and menus. It was a strong design, but it felt additive to what we already had. The incremental addition of new affordances was described in the previous section and was how we ended up where we were in the first place.

The second team took a clean-slate approach. They started from the problems Office customers faced, rather than starting from a design language or set of abstract principles. The first thing they asked themselves was, “Why are things the way they are?” This simple question frequently proved liberating. Leading this questioning were Jensen Harris (JensenH) and Clay Satterfield (ClaySatt), both of whom joined Julie’s team from Outlook, fresh off its complete and successful redesign. JensenH insisted on trying something entirely different. Julie gave him that latitude. Jensen brought with him a depth of Office product knowledge that far exceeded his tenure at Microsoft, something that was an absolute requirement to making this project work.

Jensen and Clay asked themselves the “why and what for” of the top-level menus: File, Edit, View, Insert, Tools, Window, and Help, along with the many widgets. It became clear to them that product history was no longer relevant. A button that was a hot new feature a few releases back, or that a program manager insisted upon long ago, didn’t necessarily have a place in this version, nor did the widget that was added in an effort to make finding a command easier. Despite a deep understanding of what we aimed to do, those designs were rooted in the arbitrary history and evolution of the implementation of Office. This is why the history of Office as detailed in the previous section was such an important input to this design.

Taking a step back, as great product designers often did, the team concluded that features could be grouped in a much more systematic and logical way and, more importantly, by operations that were more familiar and easily labeled for human use. A reorganization was needed more than “pixel pushing,” as HeikkiK used to say. Imagine the level of boldness required to suggest moving not just a few but every command in Office. This sounded like “Who moved my cheese?” on a grand scale.

Julie let the process run for a bit more and then it was necessary to drive towards a single unified design. She was determined not to simply pick a winner herself but work a process so a shared winner would emerge. This was brave and not the norm for Microsoft. She essentially told both teams to lock themselves in a conference room and arrive at a shared result. There was a risk of compromise or design by committee, but she knew that going in and wasn’t going to let that become the result.

The teams hated this, as they should. It is exactly what no good product designer wants to do. As expected, there really wasn’t a compromise. This did in a sense force Julie’s hand. The purity of the latter design was great, while many questions remained about Longhorn’s text-heavy approach. At first Julie finessed the choice, but it is fair to say even years later that at that moment there were those that felt like they won and those that didn’t. Perhaps there really is no alternative with competing designs. The designs, however, gave us all much more confidence in the direction, having fully explored two radical alternatives.

Over the course of the next few months Jensen, Clay, and team created many visualizations. They created hundreds of prototypes. JensenH estimated that over 25,000 renderings were created. The teams used every level of fidelity from paper to PhotoShop to Flash (yes, that was still a thing).

Why did we have so much confidence though? Who makes such a huge change to such successful products? The user interface was the product and “who moved my cheese?” could result in an unmitigated nightmare for end-users and a disaster for the business.

Early in the process, Jensen’s team design centered on a small number of important concepts—concepts that provided an enduring framework for how the interface should be designed and evolve over time as the product expanded. Starting with PowerPoint, they sketched out a design that reflected their set of principles. Envisioning a design where each app had a dominant color consistent with the app’s existing icon, the sketch of PowerPoint had a ripe red tone, and so they dubbed the initial design language Tomatoey (tom-ah-tooey), because it was a tomato-ish user interface. Get it?

The original renderings were compelling, albeit a bit too colorful. The work was unbelievably impressive. I often stopped by their offices in our shared hallway to see the designs evolve and hear what they were up to, especially in the evenings when they seemed to work best. Jensen was still new to the team, and young, and he was a little leery of my walk-bys, but he and Clay were both often working in the late afternoon or early evenings, the best time to chat and see updates. These discussions continue today except they happen over text and we’re talking about the WWDC or latest hardware. I can say without hesitation that I had not had more interesting late-night conversations about technology since my days of AFX and talking to RickP about the early code in Excel and Windows. To be honest, given the risk of the overall effort, these conversations and talking to Julie and Antoine almost every day were part of my own risk mitigation therapy.

Tomatoey was the kind of design that people tried to poke holes in and find problems with but just couldn’t. It was not just a rendering or a rearranging of the commands—it was an entire system and framework for how the product could exist and evolve. We were still very early. When you listened to Jensen and Clay go through the thinking and when they showed demos it was abundantly clear they were onto something. Normally when a design is early and one asks questions, the answers can be vague or bring on a feeling of unease. In this case, it wasn’t just that answers exuded confidence, but the answers were often more thoughtful than the questions.

Too often the graphical aspect of software designs over-shadow the key tenets of functionality. We see this today in how designs so often start with or are communicated via graphics, or widgets, versus the problems solved or functional aspects of the solution. Even the names chosen for designs too often reflect graphical or aesthetic choices in the work such as Aero or Luna.   

I asked Jensen how serious they were about this design and he said, “Very serious. . . . We really went whole hog.”

Everything had a place, and there was a place for everything.

Even at this early stage there were a set of widgets or controls as the operating system called them. It would be easy to define the design by these mechanisms, but that would be incomplete and miss the whole point.

As with any great design, there were a small number of concepts reused with a clear set of rules. From the earliest days of the design, Jensen and Clay had a full framework and rationale for every choice, across every Office application. Early on the choice was to focus on the three main document creation apps, Word, Excel, and PowerPoint. The omission of Outlook proved to be frustrating for reviewers and those measuring us on consistency. Other document applications were pleading to get the new interface, but the need to focus was paramount.

The design was sweeping and all-encompassing. Considering the scope of the design this was an incredible accomplishment. Almost every system redesign I can think of started from a single dimension or metaphor—transparency, control palettes, a new command hierarchy, or our own command bar idea. The very notion of the first principles of Tomatoey was itself incredibly significant. As a reminder, the scope of this design was 4000 commands across three major products each used by hundreds of millions of people for some of the most critical work of their professional lives.

Jensen referred to this as a results-oriented design. The crux of the design was to pivot from thinking about individual commands and where they should go to planning the results of the document creation process. The design presented aggregates of commands at a higher level. The original bullets and numbering toolbar button in Word 6.0 was an early preview of this sort of approach, synthesizing a feature out of many commands that already exist in the code. Features are illustrated by results they obtain, not by a name. Instead of a Chart Wizard, illustrate the charts that can be created and do so using galleries. Users are far more likely to get the end-result they want by getting to an approximation quickly and then using visual choices to further customize it.

While the interaction design was one aspect of this work, and in general we tell stories about Office from the user to the feature choice and design then to engineering and quality contributors, I would hate for readers to think that I am failing to account for the immense impact of software engineering and testing to this work. As talented as JensenH and the whole PM and product design teams were, they had their match in equally talented engineering counterparts. They worked side-by-side at every step of the project—there was no handoff, but a crazy amount of iteration every day of the project. JulieLar’s peer in development Dave Buchthal (DaveBu) led the development team. He started at Microsoft in 1992 and was an early member of the Office Shared team. Igor Zaika (IgorZ) was a development lead reporting to Dave and an informal tech lead for the project who also had more than a decade of Office development experience. Sean Oldridge (SeanO) led the testing and quality team, putting his decade of experience to work. The engineering, not just on the code to implement the design but the high performance and backward compatibility across Word, Excel, and PowerPoint, represented the most intense re-engineering efforts the entire Office team ever attempted, even to this day. I hope all the design and feature discussion doesn’t take away from the engineering and quality aspects of this project.

The purpose of this section is not to be a tutorial on the design, as much as I would like. There is a 2006-era blog (this will be described in a future section) as well as videos from JensenH’s various conference presentations that are available online. Many are linked to at jensenharris.com.

When it comes to saying why the early design seemed so good, I would say was it a new reality where the Office user interface engaged users in a much more captivating way and users could see their work coming to life versus debugging the document. Capabilities existed in only one place and never moved around—and at the same time every feature was accessible by an equivalent (to Office 2003) or less (!) amount of command distance. Gone were the days of tunneling into dialogs or playing hide-and-seek. Embracing web paradigms, the design took advantage of longer, more conventional text labels (longer than tooltips) and a livelier interface that showed the results of a command even before choosing it, enabling users to pick from choices like a modern sketch artist. The design even took up less space and worked on a wider range of screens consistently. The focus was on features and results. Going back to our cockpit analogy, the design essentially programmed the capabilities of Office rather than just putting a bunch of mechanisms out there to find commands. It was radical. It also worked extremely well.

They called the design the “Ribbon.” The team described the design as visual, tactile, and responsive.

The Ribbon seemed not only to solve Office’s bloat challenges but to create an interface paradigm that would be the best, and most enduring, design for the desktop era. While we were normally optimistic before we began coding, it was rare to have this level of enthusiasm so early in a project. There was something special about what was transpiring, even with a list of issues that continued to grow.

Still, we only had the early design for the Ribbon. We needed to finalize that and an entire release of Office to be built by a few thousand people.

On to 080. Progress From Vision to Beta

The previous section detailed the release of the Windows 8 platform, WinRT, for building Metro-style apps. In the reimagining of Windows from the chipset to the experience, we’ve covered all the major efforts. In this section, we will describe the latest in PCs that will contribute to Windows 8, which Intel called Ultrabook™ PCs We will also introduce the Windows Store where developers could distribute apps. The really big news will be the Consumer Preview or beta test for Windows 8 where millions will experience the product for the first time. It might surprise readers, just as with the Developer Preview, that the reaction to the product across many audiences was quite positive. Just how positive? And what in the world could the professional press and reviewers actually liked? And what did Apple’s Tim Cook have to say about all this?

Back to 104. //build It and They Will Come (Hopefully)

Following the //build conference we were feeling quite good. Not to belabor the point, but I recognize how challenging it is to take such feelings at face value given where the product ended up. In writing this and helping people experience the steps we went through at the time in sequence, my hope is that what comes to light is that we were not bonkers and in fact much of the industry was excited by Windows 8 as it emerged. Of course, there were skeptics and doubters, even haters, but as veterans of dozens of major products we’d seen this before and the volume for Windows 8 was not disproportionate. If anything, the excitement and optimism were higher. So where did things take a decidedly different direction? It was when after product emerged from the Developer Preview and a series of events including the widely distributed Consumer Preview, or beta, when millions of people would experience the product. The leadup to the Consumer Preview in March 2012 included some important steps in the process as well.

New Ultrabooks

On the heels of the //build conference in September 2011 Intel began kicking off an effort to reenergize the PC industry with a response to Apple, finally. Intel developed a series of specifications, financial incentives in the form of marketing and pricing actions, as well as supply chain activation to deliver on a new class of laptop. Intel called these Ultrabooks. We called them a blessing.

Intel was best positioned to drive this type of advance. It was always difficult for Microsoft simply providing the operating system to dramatically alter the hardware platform, even though many thought by virtue of building Windows we held significant sway. We certainly had influence, but ultimately Windows was a wide-open platform which meant hardware to support any scenario was under PC maker control. The few times we had tried to tightly control hardware specifications, such as with Tablet PC and Media Center PC, did not go well at all. Worse, such controls angered not just PC makers but our fans as well who always wanted to build PCs on their own and experiment with hardware components.

Unlike Microsoft, Intel had a unique ability to influence hardware specifications and their influence increased over time compared to Microsoft’s which waned over the years. Intel rallied the industry around Netbooks. While that was a failure, it provided a playbook that Intel could later follow. Before the Netbook, Intel almost single-handedly drove a consistent level of support for Wi-Fi with the Centrino line of chips, which bought both lower-power consumption and Wi-Fi to the standard business laptop. In these cases, and many others such as USB, SATA storage, integrated graphics, and more, Intel took on a broader role in determining components and building software drivers for Windows (and Linux) while making it easier for OEMs to adopt a complete platform.

The efforts were not pure altruism. Intel would use these complete component platforms to steer OEMs to specific price points for chips as well as unit volume commitments. With those in hand, Intel could broadly advertise the platform using their massive Intel Inside advertising budget. These financial incentives were eagerly embraced by OEMs and a key part of their margin. Intel maximized its own margins as well by careful choice of CPUs in these platforms and enabling OEMs to upsell to even higher margin chips as appropriate.

This dynamic is why competing with the new Apple MacBook Air starting in 2008 followed by subsequent models and then Intel-based MacBook Pros proved elusive. Conspiracy theorists would believe that Intel was slow-rolling competitive PCs just to keep Apple and Steve Jobs happy. I never saw any indication of such a dynamic. Rather, it just seemed like PC makers were basically fat and happy in their share battle with each other. They had little worry about the 3-5% of share Apple had especially because they viewed Apple laptops and their customers as high-end, expensive, and premium. The PC business was all about good price and great volume. Being a pound heavier, an inch thicker, and plastic made little difference. As Apple share among influential customers, especially in the US, increased, the urgency from Intel and PC makers changed.

At the 2011 Intel Developer Forum (IDF) in Taiwan and in parallel with the //build Conference, Intel unveiled a new concept PC, the Ultrabook™. An Ultrabook wasn’t an actual PC from Intel, but a series of specifications or requirements for a PC to inherit the Ultrabook label, and thus the CPU pricing and broad co-advertising that came with it.

Unlike Netbooks and Centrino, Ultrabook specifications were rather detailed and covered a broad set of criteria beyond even the components Intel provided. The tagline Intel chose was “Thin, Responsive, and Secure” which would be used quite broadly. Among the requirements to be part of this program, new PCs had to include:

* Battery. A good deal of the platform effort was a new type of battery that was not yet used broadly on Windows PCs. Ultrabook PCs required non-removable Li-Poly batteries of 36-41WHr designed to fit around components and a minimum of 5 hours of runtime.

* Storage and Responsiveness. While not required precisely, there was a strong recommendation to use solid state disk drives, SSDs, in Ultrabook PCs which would significantly improve performance. SSDs also made it possible to strongly recommend a wake from standby time of just 7 seconds, which for Windows PCs would be excellent at the time.

* Chassis Design. For the first time, Intel specified what amounted to innovative chassis design. For laptops with 14” or larger screens, the chassis needed to be under 21mm and for smaller screens 18mm.

* Screen. The Ultrabook specification included guidelines and requirements covering display selection as well, including detailed values for thickness, bezel size, viewing angles, pixel density, and power requirements. At IDF, Intel showed off displays from a number of display makers who were ready and able to supply screens.

* Keyboards. Even keyboards, far from Intel’s expertise, received attention. Back-lights, spill resistant layers, key-travel and key shape were all specified in Ultrabook design. This was a significant departure for Intel and the requirements created the need for keyboard redesign for all laptops.

* Sensors and devices. Intel even included recommendations for devices usually seen far off the motherboard including: 720p webcam, accelerometer, GPS, ambient light sensor and more.

Intel really geared up the supply chain. This was crucially important during the huge ramp up happening with mobile phones where many suppliers were thinking of moving on from PCs. As it would turn out, Ultrabooks were the last gasp for innovative PCs.

Ultrabook laptops would turn out to be the ultimate devices for the road warrior running Office. These even led to the standardization of HDMI connectors in conference rooms after decades of VGA/RGB connectors. Windows 7 had introduced the command Window+P to make it easy to switch thus ending the need for degaussing and rebooting PCs to project…mostly. The stellar work at the device and OS kernel level to reduce power consumption, improve boot time, and even the unique features for SSD storage all contributed greatly to a fantastic experience for this new form factor.

Ultrabooks brought Windows hardware to the 21st century and were far more competitive with Apple laptops than we might have expected after waiting so long. In fact, Ultrabook PCs were downright cheap compared to Apple products. While most would retail for the magic number of $1,495 many could be had for the other magic number of $999. This compared to nearly twice as much for the similarly configured Apple laptops. All in all, this was a huge win for the Windows PC. Every PC laptop today owes its existence to this excellent work by Intel and the supply chain. A small benefit for tech enthusiasts and IT administrators was that the wave of Ultrabook standardization also made it possible to install Windows without requiring additional drivers to be downloaded from PC maker sites.

Ultrabook PCs rapidly diffused across the ecosystem from the board room to executive teams to consultants and eventually to students. I remember a 2011 recruiting visit to MIT and Harvard and while I saw a lot (perhaps majority) of MacBooks, the PCs I saw were all newly purchased Ultrabook PCs with their sleek, un-PC-like aluminum cases.

Many believed Ultrabooks would put a dent in iPad momentum. Once again, it is worth a reminder that Apple’s iPad was absolutely top of mind for the industry. The iPad was the holiday gift for 2011. Apple sold over 32 million iPads in 2011 and the tablet redefined the baseline requirements for a road warrior productivity computing. Apple, hoping to sell every Apple customer on an iPhone, MacBook, and a new iPad remained relentless in the distinct use case for iPad while also continuing to tout the iPad as the future of computing.

It was this spike in demand for iPads that drove the difficult conversations with the Microsoft Office team about the role of Office on Windows 8, specifically Windows 8 on ARM processors, including the ARM device we were developing in-house that was quite secret at the time.

Old Office

We always knew going into Windows 8 planning that developing a new platform and new API meant also enlisting the support of the Office team. This was not some innovative thinking on our part, but literally the Microsoft playbook from the founding of the company.

A platform cold start requires a huge leap of faith from the consumers of the platform. The best way to seed interest in the platform is to have flagship applications that can be demonstrated to other developers to get the flywheel going. Cool apps on a platform attract more app developers which lead to cooler apps. Sometimes this is even labeled “killer application” though I think that is a bit dramatic since it doesn’t kill but brings life to the platform. Having Lotus 1-2-3 on MS-DOS, Microsoft Excel, Aldus PageMaker, and also Microsoft Word on Macintosh cemented that platform. Excel and Word were crucial to validating Windows and even to Microsoft’s ability to complete building Windows for significant applications. Ultimately Office on Windows 3.0 proved to be a tipping point for Windows. In a turn of fate, Windows also proved to be critical to the success of Office as a productivity suite. Microsoft not only came to define this virtuous platform cycle but benefitted itself with Office.

Platform shifts offer a unique moment when all bets are off, and the new leaders can emerge. It is why Bill Gates was so tuned in to creating and betting on platform shifts and why Silicon Valley always seems to be seeking out these moments. Recall from the earlier section 011. Strategy for the 90s: Windows, that platform shifts can be so dramatic that even within a company people decide to quit over them. My first manager and programming legend Doug Klunder (DougK) famously left Microsoft in the early 1980s over the strategy change to build a Macintosh spreadsheet rather than ship the MS-DOS spreadsheet that he had built and was certain would beat Lotus 1-2-3. That spreadsheet and Doug’s recalc invention (minimal recalc) formed a core part of Microsoft going forward and Doug later returned.

As discussed previously, many describe nefarious means to the rise of Office on Windows compared to Lotus 1-2-3 and WordPerfect among other leading MS-DOS productivity tools. Within the leaders of MS-DOS applications, none prioritized Windows above all other platforms. Instead choosing to nurture their existing MS-DOS successes and character-mode user experiences. Microsoft uniquely bet on Macintosh and then Windows, perhaps because it lacked the mega-successful MS-DOS applications business the others possessed.  Nevertheless, Microsoft bet and bet big and bet early. The rest is history.

Little did I and the other leaders on Windows 8, all of whom had previously worked on and led Office, realize how the tables would turn. Here we were at the start of Windows 8 knowing that we would be introducing a new platform and fully aware of Microsoft’s own playbook. We knew it would take convincing but at least for me I failed to fully internalize just how difficult it would be for Microsoft to collectively make a bet on a new platform.

At the Windows 8 Vision Meeting, I sat next to Steve Ballmer and the guests from across the company, including the leaders of Office. We showed Office running in the prototype sketches just as we showed Office running in January 2011 on ARM at the CES show and then later at //build. The Office everyone knew and loved running in the desktop. It was right then at the Vision meeting that SteveB leaned over to ask me about Office for tablets and the new platform.

I said, definitively, that we had a huge chance to build a new kind of Office application for this new world of mobility, tablets, touch, and more. It wouldn’t be like the current Office, and it wouldn’t be like browser Office—the project started back when I was in Office. We had a chance to define the new user interface paradigm for this new style of productivity, much as how Office came to define the user interface paradigm for mouse and keyboard.

We had many conversations with the Office team throughout building Windows 8. Our goal was simple—convince the team to build a new kind of app for the new Windows 8 platform. We did not want to port the existing apps to Windows 8 any more than we wanted any ISV to do that. Microsoft’s own experience with the first version of Word for Windows, a legendary mishap caused by trying to port code from one platform to another, was enough of a lesson to create institutional knowledge of the risks of doing that. Even the early releases of PowerPoint on Windows suffered from the difficulties of trying to port from Macintosh. Many might remember the difficulties Microsoft had with Word 6.0 for Macintosh which did not fully embrace the look and feel of Mac and disappointed.

The world changed a great deal with iPad and web browsers. The historical strengths of Office focused on fine grained document control for printing gave way to multi-player (a recent nomenclature for multi-user) collaboration, sharing, and online consumption, and considerably less demand for formatting. There would be ample opportunity for a new type of application. Perhaps if we collectively developed that, we thought, we could avoid the pressure to provide Office per se for Windows 8, which we knew would be a massive undertaking for a new platform, even futile.

Office was eager to experiment with OneNote, which was supporting mobile, browser, and more and was widely praised for an innovative experience in an important scenario. Doing something more significant was proving a challenge and a bit frustrating for us. In order to understand the situation, it is important to recognize the situation Office found itself in in 2010 and what really drove strategic choices.

Historically, the biggest factor in weighing choices for Office has been the maintenance of the value of the overall bundle (Word, Excel, PowerPoint, Outlook, and the Access database) and with that the pricing. Key to maintaining that value was compatibility with “full Office” meaning the complete feature-set of desktop Office. In other words, when sales and marketing were confronted with either a lower-priced or less-featured variant of Office the response was to focus on backward compatibility for dealing with old files and email attachments from anywhere, on the familiarity with the user interface, aka the Ribbon, and on the value of the bundle.  By 2010, the Office brand came to represent the Ribbon user interface, the full Office feature set, and support for documents and custom Visual Basic solutions that existed across thousands of enterprise customers.

Office continued to face somewhat acute challenges to the business from Google Apps (previously Google Apps for Your Domain, often colloquially called Google Docs, more recently G Suite, today known as Google Workspace.) Google pushed Google Apps relentlessly through the incredibly successful Gmail launch, something we would do with Windows Live and the Office browser-based applications. Google Apps was making real progress in the academic market, where the product was usually free. Small business was also adopting Google Apps owing to the push via Gmail and the easy use of the apps after registering an email domain with Google. Most importantly, enterprise customers under budget pressures following the Global Financial Crisis also began to consider Google Apps. Use of a difficult economy to put price pressure on Microsoft was something I’d experienced through every downturn since the Gulf War. Customers not only had the option of Google Apps, but they could also maintain full compatibility with Office by simply sticking with the Office they already owned and not upgrading, putting the Enterprise Agreement renewal in jeopardy. Losing even a single deal had the appearance of a “share shift” and a series of 3 deals would likely be followed by industry analyst quotes or even press releases from Google, and suddenly there was a trend.

The presence of this competitive threat made offering anything at all new seem risky. A new product would call into question the value of “full Office” and certainly anything priced at app store level pricing would draw attention to the nearly $200 per year Office was receiving in enterprise agreements, which today could be over $40 per month for Office 365. With a few thousand Enterprise Agreement customers, taking on this kind of product challenge was a level of risk that the Office team was not going to be comfortable with all that easily.

Office for Mac, long mostly out of sight and out of mind, had become a lot more interesting of late. Back when I was in Office and following the release of Mac Office 4.x and Windows Office 95, the legendary deal between Steve Jobs and Bill Gates was struck. Most recall this deal through the lens of antitrust and Microsoft throwing Apple a life preserver just as Steve Jobs returned to a company on the brink of bankruptcy. Microsoft indeed paid apple $150 million in exchange for patent rights which would ensure the end of litigation between the companies. In exchange, Apple also received a commitment to Macintosh and that Office would continue to support the platform. It was then we (in Office) created the Macintosh Business Unit (MacBU) staffed at 100 engineers to start. The goal for us was to stop kidding ourselves about doing a great job of cross-platform support and let the Mac team focus on Mac and the Windows team focus on Windows, with judicious code sharing as the MacBU, staffed with Office engineers, deemed necessary. From that time forward, August 1997, the Mac team went merrily on its way as did Windows.

Each of the subsequent leaders of MacBU were deeply connected to Apple, and discretely so. The business relationship required that. Most of Mac Office was sold not through Microsoft’s typical enterprise accounts but direct to individual customers. As Apple’s new retail stores scaled, the sales of Mac Office through that channel quickly became the primary means for Apple customers to acquire Office. MacBU found itself somewhat beholden to Apple for distribution, price support, and even launch PR. In exchange, MacBU dedicated its efforts to being a fantastic client of the Mac OS as it evolved. Such support had become increasingly difficult as Windows and Mac diverged and then as Mac became a diminishingly small part of the overall business, unlike the 1980s when it was more than half the business. The deal created a win-win for Apple and Microsoft, not to mention Apple customers.

Part of the relationship between MacBU and Apple included early access to Apple technologies under development, exactly as Microsoft had done for Windows with leading vendors. By offering this, Apple hoped to garner MacBU support for the latest platform technologies. The transitions Apple made to the new OS X and then later to Intel processors all but required Office to be present from the first days of availability. Apple knew this. MacBU knew this. Our industry knew this. It was the way platforms worked.

As part of this work, MacBU also began to migrate the Office code base from the older Macintosh operating system APIs to the new OS X APIs called Cocoa. As previously mentioned, Apple had a different way of evolving the OS compared to Microsoft. Apple not only strongly encouraged ISVs to move to new APIs, but it also obsoleted APIs thus requiring ISVs to move. Sometimes with their big code bases, the important ISVs would slow roll these moves. Adobe was (and remains) legendary for its slow pace of adoption. MacBU tended to be nimble, due at least in part to the ever-present connection in the Apple retail stores. Plus using the latest was a pretty cool thing to do in the Mac community.

As Apple’s new tablet came into existence, MacBU had to decide what to do to support it long before the general public or anyone else at Microsoft was aware of the project. To its credit, MacBU guarded Apple trade secrets just as Apple would have hoped. No one outside MacBU was aware of this project. Apple lobbied the team to make Office for iPad. Part of the promise was that the new iPad APIs were reasonably close to the OS X APIs and the work would not be crazy, taking advantage of the migration to Cocoa.

Of note, this was decidedly not an approach taken by Windows 8. Apple had already spent a generation modernizing the APIs for the iPhone and pushing ISVs to adopt more modern approaches for Mac. In other words, they were way ahead of Microsoft.

It was not quite so simple though. Apple threw a few wrinkles in the mix. First, Apple had put a good deal of effort into its own suite of Mac apps, called iWork, which were direct competitors to Office. This proved frustrating for Microsoft and also provided leverage for Apple. If MacBU didn’t follow an Apple strategy, Apple would for its own iWork.

Second, iWork was cheap. At the early days, iWork cost $79, substantially less than Office which usually sold for $150 but up to $280 with Mac Outlook. MacBU was no happier about a low-priced competitor than Windows Office was, but this was especially problematic because of the first-party nature of this competition. Whatever MacBU offered for the future tablet was going to need to be price competitive or face a real uphill battle.

Related to this, the iPhone app store already demonstrated that pricing for apps would be much lower and much less favorable (to ISVs) than selling boxes of software at retail. Few apps sold for more than $9.99 and all had a perpetual license for as many devices as someone owned. That was not close to the level of pricing (and margin) to support the MacBU R&D commitment, especially without significantly more volume.

Third, the iPhone OS and by extension this future tablet would not initially support “full Office” for all the same reasons that Windows 8 would not be able to. The security model, the user experience, and even the setup and distribution tools all were substantially less functional or at least different enough. Simply porting Office to the tablet was no more possible for MacBU than it was for Windows Office supporting Windows 8. Maintaining the complete meaning of the Office brand—and the name—along with the price point would be impossible. 

The concerns over pricing, cannibalization, and the Office brand on the new Apple tablet mirrored those of the Windows Office team. Still, unlike the Windows team, the Mac team began investing in the new tablet and by the time we were deep in discussions about Office and Windows 8 there was substantial progress on Apple’s new tablet OS. I did not know this at the time, but once the iPad was announced I was made aware.

This created an awkward situation. If there was indeed a new, or a port, of Office for iPad but not an equivalent product for Windows 8, Microsoft would look confused at best or dumb at worst. MacBU was caught between its own business needs and the strategic needs of Apple while the Windows Office team was caught between its business needs and the strategic needs of Microsoft overall.

Meanwhile the Windows Office team was doing great work retargeting Intel-based Office to run on ARM processors. This was not trivial or zero work but was super well-understood. Much like Windows NT, Office had for a long time been insulated from the specifics of chipsets and instruction sets. So long as the compiler could generate the right code and the Win32 APIs were available the effort was straight-forward. Going as far back as the January 2011 CES meeting, Office had native builds of Word, Excel, and PowerPoint for ARM using Win32 and these were important to our demonstrations of SoC support.

Our plans, however, did not include making the Win32 API available to third parties on ARM. As described previously, the Win32 API for apps presented many challenges on ARM including power management, security including viruses and malware, and full integration with the Metro user experience such as contracts for sharing information. Outlook was particularly problematic when it came to its power usage due to all the background processing. After a decade of fine tuning, the power profile for Word, Excel, and PowerPoint were excellent, far better than most all Windows software.

We intended to provide the desktop for working with files in Windows Explorer along with the traditional control panel for settings. Admittedly, this would prove to be the source of more confusion than convenience. Still the situation was not unlike that of the MS-DOS command box on Windows to some degree, especially on the non-Intel versions of Windows NT.

The bigger problem would be how an ARM device would require a keyboard and mouse to use desktop versions of Win32 Office apps as well as the Windows desktop itself. While all ARM devices would support a keyboard and mouse, not all would have one readily available as some would be pure tablets like the iPad. The Office team introduced some user interface redesign to better support touch, but at a fundamental level Office required a mouse and keyboard for any sort of robust usage.

After a series of difficult conversations culminating in an executive staff discussion we arrived at an end-state where we would ship Win32 desktop versions of Word, Excel, and PowerPoint and Metro-style OneNote. It is not without irony that I reflected on the fact that OneNote exists because we (in Office, me and others) made a bet on the Tablet PC edition of Windows when the team building the OS failed to demonstrate user interface mechanisms or scenarios for how or when a pen could be used for word processing or spreadsheets. Not only did we feel we had ample user interface metaphors we also believed we articulated the type of platform changes around touch, cloud, and mobile that could be incorporated to build a new and unique productivity tool.

When it came down to it, the Office team did not want to invest in a subset of Office, reduce the brand value proposition for the apps because they would lack support for Visual Basic and other enterprise features, or take on the risk of developing something entirely new. The biggest challenge for Office on iPad would prove to be the same as many other existing ISVs faced, the iPad app pricing and licensing model. Office was early moving customers to Office 365 and on Mac the business was still the $150 perpetual license. There was no way to charge that much for apps on iPad at the time, especially with Apple apps priced at $9.95. The App Store rules would prove complicated for Microsoft as well, who would not want to cede subscription revenue to Apple. I’m sure there were many discussions with Apple that I was not part of.

Ultimately, the Microsoft Office team had the same choice to make for the iPad as it did for Windows 8 but chose one way for the iPad and the other way for Windows 8. It was the same type of platform choice faced 30 years earlier when the Microsoft Apps team faced building a spreadsheet for MS-DOS or for Macintosh and then Windows.

I obviously understood all these reasons deeply from my own first party experience. At the same time, the company’s choice felt to me like the most conservative approach we could take at a time when we needed to be taking on more risk. The company was going through a difficult period and was getting beaten up for the risks it was taking by investing across search, gaming, web, and because of the inability to get ahead on smartphones and browsing. Reducing risk to Office at a time like this is what can happen when a company sees defending the existing business as the top priority over what could viewed as innovation or new opportunity. Platform shifts are extremely difficult for the existing leaders, and Office was a leader on both Mac and Windows.

On ARM devices the lack of Metro-style Office (also called Office for WinRT) would prove even more confusing to the market because it would appear as though we were holding back key platform capabilities by not making it so simple to port applications to the desktop. We knew there would be little interest in providing native ARM applications from third parties who would have to go through all the effort to port and support when there were plenty of Intel-based systems out there for their customers to use. Most desktop applications for sale that were under active development were also the kind of tools that required high-end PCs and were not optimized even for laptops, applications such as those from Adobe, AutoDesk, Dassault, and the like.

Apple provided iWork for the iPad from the initial launch of the iPad in 2010. They used the iPad as an opportunity to purpose-build tablet apps. By 2017, iWork was free across all platforms. Apple had nothing to defend and only benefitted from the effort to support the platform, so I suspect this was all relatively easy for them to do.

During that executive staff meeting we had the difficult discussion about the existing iPad apps for Office as well. In this case, the same concerns expressed about Office for WinRT existed for Office for iPad. The only difference was that Office for iPad was well on its to being done by late 2011. The team was concerned about what to call the apps, the lack of Outlook for iPad as they had only built Word, Excel, and PowerPoint, and the feature differences between the apps on iPad and Windows. Outlook would follow many years later, based on an acquisition of a Silicon Valley startup. Office settled on a business model where the apps were free for existing 365 subscribers or a $99 in-app purchase. Non-subscribers could use the apps to view, but not edit, documents. It would be messy and frustrating for customers who were searching the Apple App Store for “Word” and “Excel” in huge volumes and finding nothing from Microsoft.

Collectively we agreed that it would be embarrassing for Microsoft to have tablet apps first on iPad and then never on a Windows PC. The subset of Office apps would be released for iPad in March 2014. In 2021, Microsoft released an all-in-one app called Office, which supported each of the apps in a single download as well as Microsoft’s cloud storage, OneDrive.

The world was waiting for validation from Office for the new Windows 8 platform and would only see that through OneNote, which was a nice addition but not the killer app that platforms require. While I am certain there is no one aspect to Windows 8 that contributed more than any other to the market reception, the lack of Office designed for Windows 8 was a top issue.

Big Windows 8 Consumer Preview

The march of external Windows 8 milestones continued.

After the //build conference that was so energizing we held an event highlighting the app store that would be part of Windows 8. We held the event in San Francisco and ran through the economics of the store and the opportunity for developers. Antoine Leblond (Antoine) led the entire event as he’d also led the team building the store from scratch.

The Windows Store was another part of the whole of Windows 8 that went from a blank slate to complete offering in the span of the release. By the end of 2011, just months after the //build conference we already had the store up and running and soon developers were able to exercise the app submission and approval process. As with the WinRT API we had the process and tooling well-documented. There were no major hiccups, and the store did what we needed it to do and did so gracefully.

From the time of the Store event through the broad beta test, the marketing and evangelism teams worked tirelessly to onboard developers of all sizes and get their apps into the store. Going from 17 sample apps from interns and the apps built by the Windows team (Mail, Photos, Calendar, Contacts, and more) to hundreds of apps available just after beta including many first-tier consumer apps was a huge accomplishment.

The final major event for all of Windows 8 was to release the broad beta test. Normally we would not have a special event for a beta but given the huge change and major effort involved in releasing a new platform we chose to use the massive mobile telephony industry meeting, Mobile World Congress (MWC), in Barcelona, Spain to announce and make available the Windows 8 Consumer Preview. This would be a downloadable release available to anyone right after our press event on February 29, 2012.

MWC was also the big event for Windows Phone and usually where there were big announcements. The 2012 show was between phone releases, with Windows Phone 7.5 already in market and Windows Phone 8 still under wraps for an end-of-year launch coincident with Windows 8 for PCs.

Therefore, the big news for Microsoft would be the broad beta test for Windows 8. We were excited. So far, while there were questions and certainly challenges, primarily bootstrapping the new platform, we’d seen positive results from developers, launched the Windows Store, and the product was solid. The Consumer Preview was a refinement of the Developer Preview, with no major strategic changes from the release less than six months earlier.

The event was only for press held in a jam-packed tent of about 200 people. We were feeling pretty good about the planned presentations. While there was no strategic news, we had made over 100,000 product changes since the developer preview.

Our primary message was the complete Windows 8 story: the operating system, apps, the Windows Store, and PCs and peripherals that would shine on Windows 8. While the world was fixated and obsessed about tablets, we continued to emphasize our message that computing devices were converging. Mobile platforms were rapidly gaining capabilities and in many ways such as power management and sensors surpassing Intel-based PCs. On the other hand, Intel-based PCs had a quality resurgence with Ultrabook specs and Windows 8 would bring touch capabilities and proper apps to Intel PCs with touch screens. I would always emphasize that we expected traditional laptops to incorporate touch screens and remind people that at some near future all their screens would have fingerprints.

Julie Larson-Green (JulieLar) and Antoine Leblond had a series of demonstrations including the Windows 8 experience and many apps that had been submitted by developers to the store. The progress in just a few months on the Windows Store and third-party apps was a positive sign for the platform overall.

Mike Angiulo (MikeAng) and I showed off a very exciting and broad range of Windows 8 PCs from small tablets through a giant Perceptive Pixel 82” touch screen, the kind used on CNN for election night. The emphasis was on how Windows scales across the form factors and price points all with a single operating system.

Following the conclusion of the event a press release went out detailing the availability of the Consumer Preview for download. Within less than a day, the release was downloaded a million times. The Windows team back in Redmond was more ready than we were at the Windows 7 beta, standing by for the download traffic. Everything went smoothly.

The press coverage of the event and importantly the reviews for the release were quite good. I know as you read this, you must be wondering if I had too much Cava in Barcelona. How could professional tech reviewers possible like Windows 8? They did. I swear. In the first couple of days, we had over 250 first looks and reviews. Nearly 70% of them scored over 110 on the PRIME score measuring overall tone, where 100 is neutral. There were 4 perfect scores at 200. Only 13% were scored 90 or less, and this is during an era where Microsoft typically averaged 90 on most product launches.

Like the Developer Preview, across mainstream media, tech enthusiast press, and even broadcast we received an incredible volume of positive to effusive comments. I sit here today writing this and I know readers must think there is either highly selective editing on my part or some sort of conspiracy to rewrite the past. I can assure you it is neither. In writing Hardcore Software, I made it a point of researching and rereading much of the contemporary press for every product, even Windows 8 product reviews.

We spent two weeks on the road with the press doing briefings and dozens of outlets received the Samsung tablet from //build and the near final Consumer Preview release. Unlike most previous Windows releases we did not run into technical problems, but rather I received quite a bit of private communication expressing positive impressions and almost a surprise at the combination of radical and yet comfortable the Windows 8 experience seemed to be. Once the release was available, reporters started to comment in their reviews, blogs, and even tweets:

“Brace yourself, Windows users. Microsoft’s operating system is poised for stunning, dramatic change.” —Christina Bonnington of Wired

“By the time the final version ships later this year, it’s clear that Windows 8 is going to be a remarkable, daring update to the venerable OS. It is a departure from nearly everything we've known Windows to be. You will love it, or hate it. I love it.” —Mat Honan of Gizmodo

“In short, Windows 8 is elegant, dynamic and beautifully created.” —Jeremy Kaplan of FoxNews.com

“It’s an interface that’s girding itself to compete with the iPad as much as the Mac, even though it’s not an iPad knockoff.” —Harry McCracken of TIME

“Windows 8 is evidence that the old tech company is quite capable of bold moves and impressive innovation.” —Michael Muchmore of PC Magazine

“One thing is knowable now: With Windows 8, Microsoft has sweated the details, embraced beauty and simplicity, and created something new and delightful. Get psyched.” —David Pogue of The New York Times

“Don’t confuse the friendly interface with superficiality. This is Windows and can do all the things we’ve come to expect on a Windows PC.” — Wilson Rothman of MSNBC.com

“The first beta of the next-gen operating system is eminently touchable, definitely social, and maybe just a bit sexy.” — Seth Rosenblatt of CNET

“Overall, I’m extremely impressed with the next version of Windows – the features, the new ways of interacting with a tablet, and the potential of it all.” —Joanna Stern of ABCNews.com

Even the first apps available in the Windows Store were receiving positive feedback. The quality of the apps available in the store was quite good. This was very early in the mobile apps era. This makes it difficult for most to think back to how relatively basic the software was at the time. Android apps were notoriously flakey and while there were huge numbers of iOS apps, most did not do very much. In evaluating the first apps from the Windows Store, Joanna Stern of ABC News (a new beat after moving from The Verge) tweeted “First impression: the apps I see for Win 8 are already 100x better than the ones for Honeycomb or ICS [Ice Cream Sandwich, the code name for the next Android release]. Very exciting.”

Techmeme and Google News (which was the new cool place to look for headlines) were filled with coverage and positive headlines. Google News registered over 9,200 stories from the sources it crawls. This was our first Twitter-centric release and Windows 8 had almost 200,000 tweets in the first 24 hours, at peak there 20,000 per hour. It might not seem like a lot, but the Twitter-verse was relatively small in 2012, at just over 100M.

One of our perfect score reviews, a 200 PRIME and 5 on message pickup, came from David Pogue at the New York Times. Pogue was no fan of Windows and was super well-known as an author and expert on Apple products. He wrote books on all the major systems and devices but was always a bit grouchy when it came to Windows. I had flown down to San Francisco to meet with him and pre-brief on Windows 8. He gave me an earful and I was quite concerned about the pending review. I wanted to share a bit of what the review had to say:

It’s a huge radical rethinking of Windows — and one that’s beautiful, logical and simple. In essence, it brings the attractive, useful concept of Start-screen tiles, currently available on Windows Phone 7 phones, to laptops, desktop PC’s and tablets.

I’ve been using Windows 8 for about a week on a prototype Samsung tablet. And I have got to tell you, I’m excited.

For two reasons. First, because Windows 8 works fluidly and briskly on touch screens; it’s a natural fit. And second, it attains that success through a design that’s all Microsoft’s own. This business of the tiles is not at all what Apple designed for iOS, or that Google copied in Android.

. . .

Swipe from the right edge to open the Start menu (with Search, Share, Devices and Settings buttons). Swipe from the left to switch apps. Swipe in and back out again to open the app switcher. Swipe down to open the browser address bar.

If you have a mouse, you can click screen corners, or hit keystrokes, to perform these same functions.

These swipes take about one minute to learn. On a tablet, I can’t begin to tell you how much fun it is. It’s evident that Microsoft has sweated over every decision — where things are, how prominent they are, how easy they are to access. (If you have the time, watch the videos to see all of this in action.)

. . .

But one thing is knowable now: With Windows 8, Microsoft has sweated the details, embraced beauty and simplicity, and created something new and delightful. Get psyched.

I want to be sure to capture both the grief he gave me in person and what he wrote in the review. Many reviews indicated that there could be potential for some to have difficulty using the product or even wanting to make a change, though the reviewers themselves did not express the difficulty. When it came to expressing the weaknesses of the Consumer Preview, Pogue said:

The only huge design failure is that Microsoft couldn’t just abandon “real” Windows completely — desktop, folders, taskbar and all those thousands of programs. So on a PC, hiding behind this new Start screen is what looks almost exactly like the old Windows 7, with all of its complexity.

In other words, Windows 8 seems to favor tablets and phones. On a nontouch computer like a laptop or desktop PC, the beauty and grace of Metro feels like a facade that’s covering up the old Windows. It’s two operating systems to learn instead of one.

. . .

Look, it’s obvious that PC’s aren’t the center of our universe anymore. Apple maintains that you still need two operating systems — related, but different — for touch devices and computers. Microsoft is asserting that, no, you can have one single operating system on every machine, always familiar.

The company has a point: already, the lines between computers, tablets and phones are blurring. They’re all picking up features from each other — laptops with flash memory instead of hard drives, tablets with mice and keyboards. With Windows 8, Microsoft plans to be ready for this Grand Unification Theory.

It’s impossible to know how successful that theory will turn out to be. Windows 8 is a home run on tablets, but of course it has lost years to the iPad. (The Zune music player software was also beautiful — it was, in fact, the forerunner to Windows 8 — but it never did manage to close the iPod’s four-year head start.)

This is as perfect as a review can get. As a note, the scoring of reviews is done by a separate research and data team at the PR agency and it as scientific as one could be at the time. Like an Olympic sport they do not like to give out perfect scores as it makes their job more difficult down the road.

Even Wall Street got in on the positive sentiment. Normally I would not have paid any attention at all to a financial analyst view on product design, but the analyst community had become part of the cycle around an ever-expanding Apple and an ever-shrinking Microsoft. Citi research department reported the following on March 11, 2012, in a report I received:

We continue to view windows 8 as a positive catalyst - Inputs since the Feb 29th Community Preview (beta) have continued to be positive with developer and IS momentum appearing to pick up. We continue to expect general availability of win 8 devices around Sept / Oct with ARM devices likely later (although MST and OEM goal remains coincident). Given long-term secular concerns, share gains in tablets or renewed momentum in the PC market in 2H should be positive catalysts for shares. We acknowledge that the stock has a tendency to "fade" post release and thus we believe stock performance beyond that depends on tangible success of release.

What about the negative stories? There were some, just not that many. In fact, most of the truly negative stories were about specific features in the release. For example, one reviewer noted that ARM Windows 8 would not include Outlook, another bemoaned the lack of support for old-style enterprise management tools instead opting for modern mobile device management, and another was concerned about a keyboard change to the diagnostic boot sequence.

When there were negative stories, they did indeed carry the themes alluded to in the Pogue review. For example, Dan Acerman at CNET wrote in a review titled “Does Windows 8 diss the PC?”:

According to NPD Group, PCs are still the largest category for U.S. consumer technology hardware, selling $28 billion worth of desktops and laptops in 2011 (a 3-percent drop from 2010). Tablets and e-readers nearly doubled from the previous year, to $15 billion, but that was mostly on the continued strength of Apple's iPad. If you take iPad (and Android) out of the equation, interest in Windows tablets is still tiny. It will no doubt grow under Windows 8, but mostly because it has nowhere to go but up.

So just remember, while watching everyone pinching, swiping, and tapping their Metro interface tablets and convertible laptops over the next several months in product demos, the real work is, and will continue to be, done on traditional laptops (and, yes, desktops) for a long time to come.

From our perspective this notion of “two in one” was quite similar to the review of Windows originally in how it was first used as a way to simply run MS-DOS applications in character mode. The two decades of seamless Windows compatibility across 16-bit, 32-bit, and 64-bit perhaps created an expectation that compatibility was always essentially transparent.

Over the course of the Consumer Preview millions of people would download and test the product. Many would write blogs, tweets, and record YouTube videos about their experience. Almost immediately, developers began to hack away at Windows and introduce utilities to bring back their favorite look and feel from past releases. All of this was perfectly normal. We’d seen this before in every release of Windows.  

One competitor took time during their own earnings call to comment on Windows 8, which frankly was quite surprising. What he had to say would definitely become a meme for the record books. In the call, a financial analyst asked the following question of Apple’s Tim Cook:

I was wondering if you can talk about how you think about the markets for tablet and PC devices going forward. I think you've been fairly clear about saying that you believe that tablets will eclipse PCs in volume at some point. And I think you've also said they're somewhat discrete markets. There seems to be a lot of work, particularly on PC-based platforms, towards trying to combine the PC and tablet experience going forward in part because Windows 8 will be able to -- is a touch-based operating system as well. Can you comment about why you don't believe the PC or the Ultrabook and tablet markets or your MacBook Air and tablet markets won't converge? Isn't it realistic to think in a couple of years we're going to have a device that's under 2 pounds with great battery life that we can all carry around and open as a notebook or close up in a clever way and use as a tablet? Can you comment on why you don't think that product might not come or why you believe these markets are separate? (Tony Sacconaghi - Sanford C. Bernstein & Co., LLC., Research Division)

Tim replied as follows:

I think, Tony, anything can be forced to converge. But the problem is that products are about trade-offs, and you begin to make trade-offs to the point where what you have left at the end of the day doesn't please anyone. You can converge a toaster to a refrigerator, but those things are probably not going to be pleasing to the user. And so our view is that the tablet market is huge. And we've said that since day one. We didn't wait until we had a lot of results. We were using them here, and it was already clear to us that there was so much you could do and that the reasons that people would use those would be so broad. . . . I also believe that there is a very good market for the MacBook Air, and we continue to innovate in that product. And -- but I do think that it appeals to [somewhat --] someone that has a little bit different requirements. And you wouldn't want to put these things together because you wind up compromising in both and not pleasing either user. Some people will prefer to own both, and that's great, too. But I think to make the compromises of convergence, so -- we're not going to that party. Others might. Others might from a defensive point of view, particularly. But we're going to play in both.

This was aimed squarely at our positioning of devices converging. It would be several more years before Apple would add a keyboard and a trackpad to the iPad Pro. Apple would then iterate over several releases trying to add different types of advanced app launching and window management, while continuing to add support for devices such as external storage, third-party microphones, etc. These were all supported on Windows in all form factors, including on ARM devices. Still, as all the reviews noted, Apple had a giant head start on the incredibly successful iPad, while Microsoft and Windows had the PC all but locked up. At least for the time being.

If I were to be a bit delusional, I might think that Windows 8 had Apple a bit concerned. That would be crazy since in all the years I worked and competed with Apple I never knew them to care very much at all what Microsoft did outside of supporting the Mac. Instead, I would definitely give Apple credit to sticking with their narrative and strategy. They stood to benefit enormously if they could at once convince their Mac customer base that they also needed an iPad while also convincing the world that the iPad was the future of productivity computing.

As it would turn out, Apple digging in along this line would prove to be extremely good marketing as well. By continuing to define tablets as a separate category and the future while they had a two-year head start, they made our attempt to message a different narrative extremely difficult. Many of the difficulties discussed in the next section relate to Apple’s success at defining the iPad as both distinct from PCs and also the future. That left us little room to have a device that was able to do both. The toaster-refrigerator metaphor only made that clearer.

If we fast-forward, we can see how Apple stuck with this positioning while also making things very difficult for themselves. Given the chaos surrounding iPadOS 16.1 when it came to advancing software and the complexity of the iPad line, including the add-on keyboards, a strong case could be made that Apple has so far mismanaged the opportunity they created. Unit sales remain spectacular but perhaps less as a mainstream computer and more as a specialized device. Time will tell.

During the first week of the release, we had over 1.6M activated testers and easily surpassed what we saw with the incredibly successful Windows 7 beta test. The Windows Store and WinRT notification platform were seeing numbers in the millions as well. We were receiving usage data from these users and were able to analyze what they were experiencing in terms of quality, reliability, and feature usage. This was an incredibly successful wide-scale beta test.

We had months of decelerating bug fixing and a giant matrix of hardware and software compatibility to test. But that paled in comparison to the dramatic change in tone and tenor we faced, suddenly and almost out of the blue.

Where do we start?

On to 106. The Missing Start Menu

Welcome to “Ye Olde Museum Of Office Past.” This section is one of the more deeply product-focused of Hardcore Software. I hope to make it fun. In this section, I will go through the history and evolution of the Office user interface. While there were numerous innovative user interface systems and approaches across the industry, what we developed in Office by virtue of the breadth of usage and position of influence was viewed by many as a standard to be followed. Many readers have experienced the innovations discussed here. By stepping through over 20 years of user interface designs for Microsoft’s word processing applications, we can see the dedication to solving problems. We can also see the creeping introduction of bloat.

Back to 077. What Is Software Bloat, Really?

How did we get to Office 2003 with a menu bar, toolbars, context menus, keyboard shortcuts, task panes, dialog boxes (with tabs), widgets, buttons, and pop-up commands?

We got here by solving customer problems. We got here by making the product easier to use. We got here by listening to the market. We got here by winning reviews. It was that simple.

Or was it?

It is easy to see what happened in hindsight. We added new features, one after another. To make features easier to discover and use, we added additional user interface. Layer after layer, or solution after solution, we built up an array of user interface elements that when looked at in totality created bloat. But it is just so easy to say that in hindsight.

One simple observation was that to win in the market when Microsoft started making applications, we had to win reviews. These reviews meant everything in a world with many competitors, retail distribution, and little word of mouth (and no internet). Reviews were giant checklists of features. For example, Software Digest compiled yearly reviews of all products in market. The 1984/5 edition of their 200-page book on just word processors had a 4-page fold-out checklist of 50 features and a dozen abstract criteria. Fail any of those and the overall score sank. A losing score meant no ability to advertise winning, no recommendations from salespeople, and then the next release and review started in a hole. So, for a decade we made sure to always have those features. There was no choice other than to win reviews. And we did.

When should we have stopped and taken a first principles approach? When would the upside have exceeded the potential downside? When would the market and reviews have tolerated a big change? What if the market rejected a solution we tried? We would have reverted to the old way and delayed addressing bloat for how long, another decade? It drove me bonkers when people thought bloat was obviously caused by too many features. It also drove me bonkers when those that should know better would so quickly conclude that we were making things worse by winning reviews.

There is no easy answer to asking when the right time is to make a wholesale change in approach. Anyone in product development saying it is obvious hasn’t really lived through the risk of making a bad choice or is simply applying hindsight.

Innovator’s dilemma and disruption make it seem so easy to identify and act at the right moment. They also make it so easy to make fun of the leaders who are terrified, I mean literally shaking scared, to make a dramatic change to a product. No one ever gets fired right away for not making a big change. Many people get fired right away for making a big change at the wrong time. The worst part? So many big changes are eventually proven correct over time.

In the case of evolving Office, we were going so fast cranking out releases no one stopped to ask anything big. Customers were buying our product as fast as we could press new CDROMs, so to speak. We were winning reviews. Our biggest competitor was ourselves. We were so ubiquitous that we were punchlines on everything from David Letterman to Saturday Night Live to Dilbert.

Then suddenly, we were boring, bloated, and not particularly interesting. So much so that a buggy, poorly implemented, sort-of clone became a symbol of everything we had apparently done wrong. The world was saying that StarOffice was good enough. Ugh. Our sales, however, were not dented even the slightest. But could they be? We did lose that deal in one city in Germany. StarOffice was a German company so maybe it wasn’t so bad. Then there was a medium-sized US government agency loss. When do you panic when something like this happens? There’s no playbook.

Hemingway wrote in The Sun Also Rises:

"How did you go bankrupt?" Bill asked. "Two ways," Mike said. "Gradually and then suddenly."

We became bloated gradually, and then suddenly it was too much. The product was collapsing under its own weight.

It was time to revisit from first principles everything we’d done and ask why. And to come up with a better approach, a wholesale reinvention.

The aim of this section is to briefly cover the history of those innovations that got us here so that we have the necessary context in the next sections on the design of Office12. When it came to telling the story of Office12 once he showed it to customers, Jensen Harris (JensenH) dubbed this his tour of “Ye Olde Museum of Office Past.” Please join us on a tour.

Comparing a typical command in Office from the time it was introduced to a release decades later is a great lesson in the compounding complexity of products. Making text bold debuted in Microsoft Word 1.0 for MS-DOS in 1983. Text was made bold simply by selecting the text (actually, it wasn’t simple at all since few had a mouse, but I digress), hitting the escape key, the letter F for format, the letter C for character, and finally the letter B for bold. For those with a fancy monitor, which not everyone had at the time, the text became bold on the screen. Choices at each step were limited to approximately five.

Commands also had keyboard shortcuts from before the mouse as an affordance for touch typists. Early keyboard shortcuts were simple, like using INS(ert) key to copy text from the scrap (clipboard). WordPerfect, and other early MS-DOS apps, devised schemes that were nearly impossible to memorize. Most people had some sort of cheat sheet nearby or keyboard overlay to help remind them of keyboard sequences. Lotus 1-2-3 had a highly structured command architecture known as slash commands as navigating the character-based menus began by striking the forward-slash key (for example, to open a file /WFR for slash, (W)orksheet menu, (F)ile menu, (R)etrieve command). Competitively, the two behemoths in productivity software of the MS-DOS era, WordPerfect and Lotus, arguably clung to their keyboard methods while the industry shifted to the graphical interface, even maintaining compatibility with those keystrokes during the rise of the mouse and standardized menus.

Macintosh, with menus and a mouse (and later Windows), aimed to simplify all this. In Microsoft’s Word 1.0 for Macintosh, text was selected with a mouse and Bold was chosen from the Character menu, like what Apple did in their MacWrite 1.0. MacWrite had about 35 menu commands in total. Menus were mostly a direct mapping of the features to the product code. The whole product could be described by showing screenshots of all the menus in a two-page magazine spread as Popular Computing did in 1984 when Macintosh was launched.

Over time more and more formatting options were added: subscript, superscript, underline, different fonts, color, and so on. Excel was even more complicated because it supported formatting cells as dates or currencies, plus single underline, double underline, accounting underline, and more. This was great—we listened to customers, observed what they were trying to do in the real world, took advantage of new hardware, such as laser printers, color ink-jet printers, and fancy screens, and were adding features like mad. Soon, though, the menus got too long for even basic formatting.

Microsoft’s early Macintosh applications introduced dialog boxes, which were windows that popped up and showed all the formatting options. This was inconvenient for routine formats, so the menus had a mixture of common commands like Bold and Italic, and then a menu to “bring up that complicated dialog box.” This was the start of hide-and-seek with features.

Excel realized these challenges about the same time Microsoft Publisher did and created toolbars. (There’s a history of debate over toolbars—what is considered one, and which team or even company invented them. Many on the Excel team were hardcore about their version of the story.) Toolbars were used for common commands, like Bold and Italic, as well as Print, Save, and Copy. In 1990, the front of the Excel 3.0 box and associated advertising displayed giant toolbar with buttons for Bold and Italic. Toolbars they were such a big deal. Eventually, toolbars were so popular everyone wanted their favorite commands on them, so we created more toolbars and made it easy to rearrange the buttons and hide/show different toolbars.

Under development at the same time as Excel 3.0 was Word for Windows 1.0, Microsoft’s first word processor for Windows (I’m omitting the venerable Microsoft Write included with Windows, which by the standards of MacWrite was every bit a word processor). Word for Windows also had toolbars, two of them, and a graphical ribbon which was the defining user interface element in word processors, owing to the skeuomorphic interpretation of the margin scale of a Selectric typewriter. Word 1.0 also fit on a screen 85% the size of today’s HD television.

Word 2.0 released in 1991 nearly doubled the number of buttons on the toolbars but maintained the same layout and screen dimensions. While each iteration showed substantial gains, the transition from Word 1.0 to 2.0 marked a move from character to paragraph and document-level operations in the main user interface. There were now buttons for inserting tables, columns, charts, and graphics/shapes. The addition of inserting charts, for example, represented the rise of Office-wide technology connecting the applications which was strategically important even if not every customer used the features. Each of these features represented more than single attributes on a character. For example, adding a numbered list encompassed indenting the paragraph, an automatic number, hanging indent for multiple lines, and spacing after the list. These steps could have been executed manually but getting them right each time was error prone, assuming one could get it right the first time. As each of these features were more complex, Word introduced dialog boxes that had buttons on them to summon further dialog boxes, or nested dialogs. This really led to the creation of “where is that?” within the user interface. Designers and program managers worked enormously hard to position choices and options within these nested dialogs, but no user maintained this level of conceptual knowledge of the product. What was the problem we were solving? There was literally nowhere to put all the new features. Menus and toolbars were constrained by working on screen resolutions typified by 15” CRT monitors or first-generation laptops.

By Word 6.0 the race was on (the version number skipped from 2.0 to align with the ongoing MS-DOS version of Word which accelerated its version number to align with share leader WordPerfect—yes that’s how the industry worked). Word 6.0 was a breakthrough product, even more so when brought together with Excel 5.0 and PowerPoint 4.0 as Office 4 in 1994. At that time, Office 4 was a monster of a product as no company had competitive products in all the major categories. Within the categories each Office application was at least tied with the nearest competitor. Office 4 was the last release entirely designed for individuals as the product was quickly becoming a standard business purchase.

That said from a design perspective, the relative heft was obvious. Word 6.0 added 6 additional toolbars and a host of new user interface affordances for accessing commands, while also increasing the baseline screen size by 25%. Word (and Excel and PowerPoint) added right-click contextual menus, tooltips, tabbed dialog boxes (a refinement of the nested dialog boxes), toolbars on bottom of screen, and wizards. What was already a difficult to master set of commands accessible by one action (point and click) became acts of hunting and discovery. Tooltips, helpful text explaining what a graphical toolbar button did, popped up when the mouse was hovered over a button. Some toolbars only appeared when invoking certain features (though they didn’t always go away).

Right-click context menus are worthy of some historic context. Paul Allen (PaulA) Microsoft’s co-founder was a huge fan of the right-click, drawing his inspiration from the original Xerox SmallTalk when he created the first Microsoft Mouse with two buttons. Steve Jobs rejected two buttons in favor of a simpler Macintosh mouse, and for years bemoaned the use of the secret Ctrl+click added to Office applications, simulating right click. Windows had not entirely caught up with its use of right-click but with Office 4, Apps added right-click with abandon. With right-click, relevant commands for a character, a selection, a picture or even a paragraph appeared by right-clicking the selected object. The laudable goal of these commands was that by carefully curating the user-interface the right commands would be available and there would be no need to cruise around the product to figure out what might work. The menus were called context menus for this reason. The feature was marketed heavily, so it was no surprise that sometimes we snuck commands in the context menu that were important strategically, though not always the most likely to be used.

We had our early usage telemetry for Word 6 that came from a specially coded version and data collection via floppy. I vividly recall the data coming back about context menus showing they were frequently used. I shared this data with PaulA who was active on the board still. It was quite a vindication of the two-buttons. The more fascinating datapoint was that for a typical command such as copy/paste the usage of the menu, toolbar, keyboard shortcut, and now context menus were split roughly evenly. A given user did not exclusively stick to one affordance. We learned early on that adding secondary and tertiary affordances to commands was a convenience picked up by a set of users, not a replacement for the old ways. Importantly, and reviews showed this, technical users heavily bought into the notion that user-interface should be available multiple ways for maximal efficiency. While we curated and designed the context menus, it was no surprise that these same technical users wanted to customize context menus because they had their own ideas for what might make sense. The popularity of context menus put pressure to add even more commands over time, eventually obscuring content or forcing awkward positioning on small screens.

It was always the case that menu items that were not applicable at a given time were disabled or greyed out. As commands and buttons began to encompass high-level abstractions, disabled commands started to become a mystery. Why couldn’t I insert a table inside a table? Why didn’t bold work on a chart? And so on. This proved even more frustrating than hide-and-seek. These “greyed out” commands aways seemed to be needed just when they didn’t work. People had no idea why a command was greyed out. Even today searches for “Word menu item greyed out” have hundreds of millions of results.

Recall that the design of Word 95 (technically Word 7.0 for Windows 95) required we not change the file formats. This significantly constrained what features could be done since most formatting and document commands would result in a file format change. Word 95 innovations were mostly focused on IntelliSense, features that just worked with little if any user interface. We previously discussed background spelling and AutoCorrect as examples of these features. While the product did not gain bloat by way of pixels, the sense of product mastery was reduced. IntelliSense features introduced us all to “what just happened” when using the product. Typing a few dashes across the screen and pressing return yielded a clean horizontal line. Pressing backspace was a clever way to undo that so long as that was the next key pressed. This loss of control or as we now know an inability to fully master a product came about by the introduction of features specifically designed to be useful without having to learn a command. Hundreds of hours went into designing interactions such as how to begin and end a bulleted list (using an asterisk or hyphen at the start of a paragraph to begin, and a second return to end a list). Even with a dedicated effort, we could not be right 100% of the time. We began to consider the hypothesis that automatic features might need to be so perfect that they worked 100% of the time, and if we guessed wrong just 1 time out of 100 then to the user the feature was always wrong. Think about this in the context of today’s iPhone AutoCorrect.

Word 97 was the first release using shared code across all of Office for deep architectural features. One of those features discussed earlier was command bars, our first shared code for this critical user interface affordance. The availability of shared code and ample time to develop new features led to an explosion of command surface area in the product. Thanks to 32-bit computing and Windows 95, the base screen resolution expanded to 1024x768, three times bigger than our original target for Word 1.0. An explosion in user interface correlated to the product being labeled a winner, a juggernaut, and competitively overwhelming. But it was not bloatware, yet. Just by toolbar count, the product was twice as big, jumping to 18 toolbars (and each one had more buttons because of the screen size). For completeness the list of new user interface widgets included: toolbars on every side of the screen and floating, menu bar that can be docked on any side of the screen or floating, drag and drop any command anywhere, hierarchical and multi-level menus and context menus, icons on menus and context menus (the preceding all came as part of the new shared code), Office Assistant ("Clippit"), green-squiggle grammar checking, even more IntelliSense (including on-the-fly spell correction), along with more wizards and more multi-function commands on toolbars.

IntelliSense in Office 97 was as much a point of view as it was code in the product. Some of what was designed as IntelliSense was trying to do the right thing with the user interface elements that routinely appeared. We would try to anticipate needing some functionality and pop up the user interface. Often this puzzled the user, and they would quickly move it out of the way. The obvious addition was a check box “Never show this to me again.” The significant problem with this option is figuring out when to show that user interface in the future. If we guessed and showed it again, we were ignoring the user choice. Absent that, the chances of a user finding where to uncheck the checkbox they just checked were slim. The chance of even knowing that is what was required was probably zero. In other words, whatever we popped up was effectively gone forever. This type of intelligence in the design proved to be incredibly frustrating. I’d offer a tip for readers that are designing products: a checkbox offering to never show something again is always a bad idea (GDPR inclusive). Showing it in the first place was the problem.

Word 97 was both our last release aimed squarely at the retail consumer and technology enthusiast and our first release with an eye towards the volume purchasing business customer. It was also the last release that was done without thinking deeply about the impact of complexity on corporate customers. In hindsight it is probably right to look at this release as the start of an overwhelming Office but only because customers would soon be pointing to Office 97 as bloatware. At the same time, by today’s standard the set of features and capabilities were not at all overwhelming, just ahead of the curve for most people. For example, PowerPoint dramatically added photo, drawing, and graphics capabilities which also appeared for charts in Excel and drawings in Word. It is entirely clear these are representative of mainstream scenarios today.

Hearing the early concerns of complexity and bloat from our new enterprise customers deploying Office 97, we looked to a cosmetic/graphic design approach to reducing bloat. Along with the enterprise feature set in Office 2000 we employed the use of the doctrine of “make it simple by hiding it.” We used our command bar infrastructure to implement the personalized menus, where commands were hidden by default in both menus and toolbars. This was detailed in Chapter VIII (Alleviating Bloatware, First Attempt). The feature proved a failure and would be an important part of informing our design for Office12.

In another visual trick, we used the space made available by hiding toolbar buttons by default to place the two main toolbars adjacent to each other rather than on top of each other, called rafting. The contextual toolbars introduced in Office 97 described above were further tuned so they would hide and show automatically in the hopes of returning some control to the user.

I’d offer another tip for readers that are designing products: invisible and hidden commands are in no way at all simpler or more streamlined, though they are frustrating.

The Windows team encouraged us to change our apps to have one distinct window for every open document, with each window showing up on the Windows taskbar at the bottom of the screen, a design long-standard on Macintosh. Previously only the application showed up on the taskbar and multiple documents for the same application were available as separate windows only through the application’s Window menu. This was deemed complicated and not consistent with the direction of Windows. The result especially for Outlook was a ballooning in the number of windows on the taskbar each with ever-decreasing amount of text showing the title as they were cramped together. In other words, a change meant to make things easier turned out to scale particularly poorly when applied to real-world application usage.

By the time we shipped, Word 2000 added five new toolbars.

Office 2002 (aka Office XP) aimed to vector some efforts back to delivering end-user features. With the failure of the Office Assistant and Clippy’s retirement due at the time we shipped, we introduced two features aimed at offering ease of use surface areas. In hindsight, both were poor choices, one of which continues even today (after being removed from Office12).

The first relatively minor change was to make our new internet-connected help system available all the time with a simple “type your question here” box at the top of every screen on the same level as the menus. This rather innocuous addition set a precedent of cluttering the menu bar for additional commands. The awkwardness of the affordance as a place to type questions made it a particularly poor choice. Typing in the menu bar is just weird.

The task pane described in Chapter IX allowed us to greatly expand the surface area of the user interface. The design choice was rooted in the rise of the web. Unlike menus and toolbars which are concise word-length command descriptions, the web evolved with sentences describing the steps, such as “After selecting your dates of travel click here for the best fares.” Many on the design team favored moving Office to a more descriptive user interface as a way of reducing complexity and explaining actions in context. The task pane started as an experiment for a few key long-standing problems. The “New Document” task pane finally gave us more room for the user to choose from a list of previously opened files, document templates, and more. The “Reveal Formatting” task pane was an advanced feature long favored by technical users which showed all the formatting applied to a given selection of text (historically this was also a feature to compete with WordPerfect).

The task pane would prove to be a frustrating experience for customers, especially on small screens where it took over a good chunk of the side of the screen. It is worth noting that laptops had started to switch to wide-screen format (16:9 aspect ratio)—screens remained about the same height but were wider to accommodate a standardized HD (720p) and Full HD (1080p) resolution being used for video. Theoretically the wider screens would offer more space for user interface arranged vertically. Tech enthusiasts became enamored with the idea of stacking the Windows taskbar on the side for this reason. Feedback was mixed. At the very least a large portion of our enterprise customers were still using standard 4:3 aspect ratio screens.

In total, Word 2002 created eight task panes and added another seven toolbars, bringing the total number of toolbars to 30. Task panes were a key part of marketing Office XP, exceeded only by Clippy’s retirement.

Office 2003 as described in the last chapter was characterized by heft. We delivered more new “programs” than in any prior releases, plus services and servers—the entire Office System. The expansion of the user interface continued as well.

The task pane from Office XP proved extremely popular, even considering the feedback from Office XP. We believed that the continued standardization of wide screens would show that using the task pane for user interface was a good use of the extra width. We added 11 (yes, 11) new task panes bringing the total number of task panes to 19. The task panes received a technology improvement adding support for more user interface elements and richer display. The task panes themselves were essentially mini-web sites within the product.

We didn’t stop there. We added a second window aligned on the side for showing online help which would cause a jarring realignment of the whole application shifting everything to the side to make room.

Looking back at each of these releases one other point is worth noting. Each product cycle as we aimed to make things easier, some commands moved around and to users the changes in the interface felt as though the whole product moved around a bit. These small moves were designed to make the product a little bit better, but to users it was often the case that the product was more than a little bit different. Small changes have just as much of a negative impact on the feeling of product mastery as big changes, but a minimal effect on ease of use.

With Office 2003 we reached a point that the was envisioned in David Pogue’s 1994 column as “Word 15.0, due to ship in 2004”, give or take. A mock-up of such a future version of Word illustrates the article showing an enormous number of toolbar buttons filling the screen, leaving little room for editing any document.

Two more escape valves in the design of Office proved to be sources of bloat as well, even as they served to solve problems for our own designs and customers: customization and program settings or options.

In the early days of the products, we added the ability to customize most of the choices we made. End-users or system administrators could move commands to customize the product for their unique use. Over the years we continued to improve the ability to customize. By Office 2003, we had the capability of placing any command anywhere along with the ability to create as many toolbars and menus as required. This customization was embraced by those creating custom programs running within Office applications using Visual Basic.

Many tech enthusiasts took great pride in having a perfect toolbar for themselves or their business. One customer I visited, a big consumer product goods company in the Midwest, spent months planning the rollout of Office such that there were specialized arrangements of the menus and toolbars depending on an employee’s job function. A lawyer, marketer, salesperson, or finance person saw different customizations. This might have seemed nifty, but it also meant the company needed to rewrite the documentation and help for the product, leaving employees with existing product knowledge or those who were using how-to books lost. We invested significantly in making it even easier to customize the product, believing that if more people could customize the user interface maybe it would be easier. We really needed to stop digging.

No discussion of bloat would be complete without mentioning “Tools Options” the settings for an application. These settings would increase every release. A “setting” is most often a choice somewhere in the code that we made in designing a feature, but for some reason we anticipated that customers would make a different choice. Some choices might be preferences or user information, such as default fonts or initials to use in marking document revisions. Others were often obscure compatibility choices such as the most famous of all, operating as though 1900 is a leap year or not. This is an option because the first versions of Multiplan and Excel (Microsoft’s products) and Lotus 1-2-3 incorrectly coded 1900 as a leap year (not to nitpick, but Lotus was incorrect and Multiplan then Excel maintained the error for compatibility with industry leader 1-2-3).

Tools Options was also a place to cover the sins of indecision among program managers. When Excel pioneered the wheel on the mouse in Excel 97, between Word and Excel we could not agree on whether the wheel was meant for zooming or scrolling. To compensate for our own inability to agree we added a checkbox to change the default.

The Tools Options dialog, much like the control panel in Windows or system settings on Macintosh, is often the first stop for reviewers or techies. With over 200 choices there was plenty to keep an eye on. The presence of choices is empowering. At some point, however, empowerment turns into bloat. We reached that point.

Sure, the choices were overwhelming, and people were finding them difficult. But we were also speaking an entirely different language than customers, one they weren’t interested in learning. They had work to do. They knew what they wanted when they saw it but describing what they wanted or even spending time exploring the product was time wasted. We used to joke that if we did a usability test to English speakers using the German version of Office and asked them to do something complicated, they were no more efficient in their native language simply because the words on the menus weren’t words at all. What is “Mail Merge” or “Pivot Table”?

During the design of Office12 we conducted many usability tests where we asked subjects to pick where a command should go in the existing menu structure or to locate where a specific command might reside. Some of our menus had become almost dumping grounds for commands that didn’t obviously fit somewhere. The problem with such a design is that if we don’t know where a command should go how in the world would a normal person guess where it should go? Or even if they got lucky once would they remember it the next time?

Returning to how we became bloated, it was two ways. First slowly, then suddenly.

I hoped to make the case that at each generation of Office we were considered in where those features went. The thousands of hours we spent deliberating the names, entry points, and visualizations for every new feature were symbolic of our commitment to getting this right. We were proud of each the default user interface experience of product cycle. Screen shots were our currency, and we were always happy to see the new screen shots in the press. One thing we noticed was that even with all we added and improved, the ability for customers and the press to identify the new product versus the old from screen shots was rather limited. The product was so overwhelming most people could not tell the difference. We had a design language consisting of a lot of stuff on the screen, but to most people it looked like a bunch of buttons and computer stuff surrounding their work.

An analogy we often used was key to understanding a way forward for us. From crime and police dramas, most are familiar with the role of the sketch artist—the detective who takes a verbal description of a suspect and turns into a drawing that is used on the streets. It is difficult to describe another person as most of us lack a vocabulary for facial features necessary to reconstruct a face. That is why creating such sketches is a highly expert art. Over the years, the use of software to show options to a witness has become the standard for constructing a sketch. People do a much better job describing something from examples than they do from a blank sheet.

Office needed the equivalent of a library of choices rather than an overwhelming vocabulary of features they did not understand.

But how?

Hardcore Software by Steven Sinofsky is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

On to 079. Competing Designs, Better Design

In this and the next five sections, the story of Office12 (Office 2007) unfolds. This is really the story of the development of the new user interface for Office, which became known as the Ribbon. To many readers, this will seem much smaller today than it was at the time, and that is understandable. I hope to put this work in the context of the day so readers can see just how big a deal this was. The graphical interface was the paradigm of computing. The menu bar was the manifestation of that. The addition of graphical buttons or toolbars was a significant advance and clearly the biggest addition to the WIMP paradigm.

One of the realities about a common toolset is that over time all applications get commoditized or at least appear the same. Everything looked like a big collection of buttons. That means two tools in the same category (two spreadsheets) will converge in how they look, and to the market they will be perceived as interchangeable. This perceived commoditization is one half of the story of Office12. The other half is figuring out how to make our extremely sophisticated products usable to hundreds of millions of people, something without precedent. A car typically has a dozen controls one needs to know to use it. Microwaves, televisions, thermostats, and so on are usually less than that.

Regardless of the reason, Office has thousands of commands. Making sense of those is an impossible customer task. So, what did we do? This section is an overview of the specifics of bloat. The next section presents some history, and then the design over the remaining sections.

Back to 076. Chasing The Low-End Product [Ch. XI. Betting Big to Fend Off Commoditization]

In 2001, Jon Stewart, the legendary host of The Daily Show on Comedy Central, performed a hilarious and brutal takedown of a redesign of CNN’s Headline News show. In the segment, he took to task the departure from the traditional talking head, as epitomized by Walter Cronkite and the evening news (and Jon Stewart). He mocked Generation Y (eventually called Millennials) for favoring a seeming onslaught of disparate information at once rather than one camera and a single story at a time. Stewart referred to a new look that “ . . . offers a great way to find out everything without the pressure of retaining anything.”

The punchline, almost 20 years later, is that the redesign Stewart mocked became standard across every medium, web, broadcast, cable, Bloomberg, YouTube, and today’s phone apps. We can bemoan such a change or accept the fact that people prefer consuming information differently than they did a generation earlier. The reality back in 2001 was that people were leaving TV news in droves in favor of on-demand, concise, and always available internet-based news displayed on crowded home pages.

Around the same time, the TV show 24 was considered both a breakthrough and critically panned for a similar departure from the tradition. The show was fast paced, had a complex narrative, and featured dozens of characters moving in and out of each other’s story lines. Critics said the narrative was overly complex. The same generational change was afoot, and the MTV Generation was raised on fast-paced video, clipped dialog, and rapid cutting between scenes. To this new audience, 24 seemed entirely consumable. The single-camera sitcom was in its twilight.

Design, whether functional or aesthetic, is a product of the context of the times. When contexts change—meaning the people and their needs and the available tools and technologies—designs need to change as well.

File, Edit, View, Insert, Tools, Window, Help.

Like the catchy lyrics to a well-worn pop song, in Office we knew the top-level menus appearing consistently in each of the applications. We spent almost 10 years convincing, cajoling, and aligning each other around these words as though they were carved in stone. In fact, these words were the product of compromise—first a compromise between Microsoft and Apple on the original Macintosh applications and then a compromise between our new Windows applications and Macintosh versions. Finally, there was a compromise across Office to reach consistency. As with many compromises, no one was particularly happy with the result and there were plenty of exceptions, but nobody was all that unhappy either.

It wasn’t perfect, but it was our menu structure and our customers liked it. So much so, it was widely emulated across the industry. That made it carved in stone. It was like so many arbitrary design choices that somehow develop a lore of great design, like QWERTY keyboards or P-R-N-D in a car.

While rather adaptable creatures, humans tend to react poorly to change imposed upon them—a new stoplight, a new layout for a website, or the most heinous of all modern changes, a new software user interface for an existing product. Unexpected or imposed changes are viewed at best as arbitrary and at worst as bad (incredibly bad). It is exceedingly rare in the world of software to see existing users embrace major changes to mature products.

Consider something that most of us would today think of as rather benign, a change in the layout and typography of a print-based magazine. Magazines would devote a few pages explaining the design and rationale or perhaps even TV commercials as The Economist did with their 2001 redesign. Such “bold” (they always called them bold) redesigns would often become the subject of weeks of letters to the editor complaining about the failings of the effort and calling for a return to the old design, followed by the inevitable subscription cancellations.

Even if a product makes it through a big change, there often remains an undercurrent harkening back to the good old days for a long time. Whether it is simply conservatism or as some express a true loss of efficiency or effectiveness with a product, change is hardly ever free of controversy.

Yet, we live in a constant state of change. What is it that separates the changes that cause an uproar from the changes that happen with little notice? Technology is changing all around. Consumer behavior and work norms are regularly evolving. Competitors with new perspectives arise frequently. Often competitors with a fancy new design might even compete directly with a small portion of a larger established product with a tired design. Perhaps the new product even garners outsized attention because of that new design, less so than the features it brings. Failing to change remains the biggest mistake technology companies can make.

And as I’d soon learn, failing to change correctly is the second biggest mistake technology companies make. There are no rule books or guidelines that govern how much a product can change and when. There are many books telling you if you don’t change, you’re doomed. There are also a lot of books telling stories of changes going haywire. (Note to readers, this work is both of those).

Office became a bit like the old evening news, not so much Cronkite’s CBS but more like CNN. It was ubiquitous. It was reliable and predictable. It did not draw much attention to itself. Younger people knew about it but didn’t talk about it the way older people did. It was comfortable.

Still, each release was more successful financially than the previous and rated higher in customer satisfaction. Our customer base grew, and they continued to be happier with each release. The Office brand anchored several important traits of Microsoft representing “easy to use” and “professional.”

But comments about bloat continued unabated. Was it insider talk? Were people overall happy and the beltway of tech journalism was searching for something, anything at all, to criticize in the face of success? How could customers be so satisfied, and the business be growing if we were making increasingly bloated products? We theorized that analysts, reviewers, and reporters, those most typically calling out bloat, were users of a small subset of Office compared to typical knowledge workers. One reviewer of a major national outlet would not review Excel because of the view that most people didn’t need a spreadsheet.

As we discussed in creating Office Lite, a pervasive view existed that the product suffered in usability and quality because it had too many features. Specifically, there were too many features for how any individual said they used the product. Too many features lead to a complex experience and bugs, so went the theory.

Another theory was that PCs, not just Office, were becoming increasingly fragile and flaky. Bloat might be a PC problem and the ubiquity of Office simply an easy way to express the problem.

Three factors contributed to a feeling of a declining PC experience—sort of like a car that needed a tune-up to get rid of the engine noises, reduce the squishiness in the ride, and improve performance.

First, PCs were decreasingly interesting to purchase. The newest and best PCs lacked the excitement, and budget, that made consumers want to rush out to buy a new one. The pace of improvement in hardware arguably slowed, but so did the pace of software. By 2004, we were three years into Windows XP with no new release of Windows in sight. Longhorn was perennially under development. Without a new Windows, the need for a new PC was minimal and certainly not worth the pain of moving files and programs to a new computer. It is important to note that buying a new PC was the fastest way to reset the PC experience, cleaning out all the gunk. Without a PC purchase, such a spring cleaning was technically impossible.

Second, the rise of the internet turned everyone into a software downloader. Every first Tuesday of the month Microsoft sent updates to hundreds of millions of PCs to keep them secure—product changes that closed holes that could be exploited by malware and viruses. The creation of Patch Tuesday, as it was called colloquially, was rooted in Trustworthy Computing and was a major innovation in system security and reliability. The seemingly constant stream of product updates only served to emphasize the fragility of the PC. The required and poorly timed reboots wasted time or worse and left a bad impression of PC reliability while also providing great explanations for a PC slowing down or failing to restart.

Users were downloading software constantly as well. It wasn’t only the next version of a browser that remained interesting but the latest media player software, software to control the newest device to plug into a PC, utilities making the aging Windows XP easier to use, and more. From Napster to BitTorrent to Adobe Acrobat, plus an onslaught of games, there was an endless stream of software to download. Software installed on Windows had free reign over the system. Installed software could interfere with performance, memory usage, battery life, or even conflict with other previously installed programs causing all sorts of mysterious problems.

Tech enthusiasts had names for these problems. DLL hell referenced programs that failed to run if the wrong version of a file known as a DLL existed on the PC. Bit rot was the slow decay of the overall system. My favorite was registry corruption which was a mostly meaningless term referring to the slowing performance and potential fragility of a specific part of the operating system due to adding too many programs with too many settings. These conditions led to a new class of software designed to clean PCs, freshen them up, and recondition them. But these utilities only further exacerbated any problems and served to reinforce and accelerate the problems that PCs faced over time.

Finally, PCs in the enterprise were locked down by system administrators with an arsenal of software to secure the machines. These included firewalls, antivirus, virtual private networking (VPN), not to mention intrusive scans and analyses of the PC, slowing down every work session, especially just logging on. The fragility and risk to typical users on PCs created the need for more software, ever more invasive software, to mitigate those risks.

 A typical office worker faced a choice of a lethargic PC at work with disabled capabilities or a PC at home that became increasingly flaky as members of a household continued to pile on an assortment of downloaded software.

As real as all of these were, none were relevant to Office which by and large was well-behaved. We needed to dig deeper. Bloat was our biggest competitive problem. Office still lacked a major competitor, but increasingly the cost and heft of Office were viewed as liabilities or targets. StarOffice was free and continued to be an annoyance. Piracy of older Office was far more of a competitor, and by virtue of its age was more fragile and prone to viruses and security problems thus worsening the perception of Office.

Startups were beginning to experiment with the latest browsers and the technology pioneered by Microsoft known as AJAX—a style of programming web pages so they behaved more like a typical Windows program with interactivity but with all the benefits of simply being a web page in a browser. Across the web there were startups building simple word processors and drawing programs this way, and even a few spreadsheets and presentation programs. Intuit (makers of Quicken) shipped a browser-based database to compete with Microsoft Access called QuickBase that won an editor’s choice for workgroup software. Microsoft invented AJAX for Outlook Web Access, but the depth of features made it useful for only occasional mail not the all-day transaction processing style of usage in Outlook. AJAX seemed far off for building a full-fledged productivity tool. Nevertheless, Office was investing heavily in making portions of the product browser-native, such as pivot tables in Excel and databases in Access, in addition to Word and PowerPoint documents.

The question in the air and among tech elites was chilling: Was Office finished and were the alternatives to Office good enough? This phrase good enough drove me crazy. It was as though there was something about productivity software that people should just settle for what gets enough of the job done today. Like a middle-aged person fighting off what seemed to be inevitable weight-gain was it slowing metabolism or was there actually a change in behavior? I used to ask rhetorically, “is Word (fill in the version) the peak achievement for humankind when it comes to writing?”

The snide comments about bloat were getting old.

The internet only served to magnify what used to only surface in a review. Along with terms like MicroSloth, Micro$oft, and Windoze, every time a tech writer mentioned Office, positive or not, a chorus of bloatware filled the comments section or as we saw old fashioned letters to the editor.

Bloat was an amorphous concept with numerous manifestations. We needed to get to some actionable definition if we were to make progress—the heart and soul of the brand was at stake.

In spite of bloat, we heard endless requests for new features. At one point we compiled the most recent requests and something like 90% of them were features already in the product. Ouch.

What really got under our collective skin was the constant whine that Office had too many features, most of them unused. We worked hard on all those features and every one of them was traced to solving some problem customers asked about. At least that is what we’d tell ourselves.

This bugged us because the data was entirely conclusive: Most of Office was used. But no one person used the entire product. As if to emphasize this point, most people didn’t know or care what buttons they clicked on or menus they chose so long as it was working for them—and that meant when asked, “Did you use X?” most people couldn’t recall. To a skeptical press or IT manager (and they all were) that meant unused features.

We measured usage for a decade, first with the laborious and entirely manual process of the instrumented version described earlier. With the arrival of the internet and Watson technology, we extended the instrumented product to every Office customer, everywhere. Enabling the telemetry of the product was via opt-in only, totally anonymous, and no identifiable information was collected. Several data points were recorded: what commands were used; if a command was invoked by a keyboard shortcut, menu, or toolbar; how long an operation took; and, importantly, what sequences of commands were executed. Things we guessed at 15 years earlier were knowable in what could be called a census of usage. While some people didn’t opt in, a large enough majority of users (meaning an unbiased and large sample of the population) provided us with data upon which to decide how to evolve the product.

We called the extensions of Watson (previously used for crashes and system hangs) to usage data Software Quality Monitoring (SQM), or “skwim.” SQM was the buzz of the hallway and became the linqua franca of the program management team. SQM was how we settled debates over who used what, how much, and what was most important. The insights gained from SQM were as exhaustive as the volumes of charts, tables, and graphs that filled our collective inboxes.

Decades later, the idea of using data to design products is a well-understood approach. At the turn of the millennium, it was new and radical, and a strategic advantage. We focused on using data to figure out how to get things done faster and with fewer clicks. Web sites were using data to figure out how to get people to buy more online, read certain articles, or to click on advertisements. Here we were using data to help people use the product less.

What we were learning with SQM, however, was that people were futzing a great deal with Office. While the most common commands were the obvious (Print, Save, Copy, Paste, Bold, and a few others), with astonishing frequency users were hitting Undo, Redo, Undo sequences trying to figure out how something might work. Seemingly common operations like creating a chart in Excel or a table in Word were tiresome and endless sequences of trial and error. A trivial task in PowerPoint, such as aligning two shapes in a drawing, was done by nudging with arrow keys and eyeing the result, rather than using the built-in alignment tools that were a few (too many) clicks away.

We called the futzing document debugging, and it created a frustration that the product was powerful yet overwhelming. People believed a specific result was achievable but getting from point A to B seemed impossible or unlearnable. The idea that documents were being debugged mirrored the complex dialog boxes for adjusting formatting. These user interface elements had incredible series of buttons, measurements, and options available with no indication of what to use when. The picture positioning dialog in Word featured a dizzying array of horizonal and vertical alignments with many options always greyed out, and no simple way to indicate a desire to stop moving everything around so much.

There were routine offenders like trying to fix the spacing between paragraphs or position an image in Word, or the impossibility of altering a chart in Excel. The mere mention of bullets and numbering would be followed invariably by a groan. Arguably, the worst offenders were the infrequently used idioms: creating labels used for holiday cards or the one time when a table called for alternating bands of shading in rows or columns. Inevitably, a person sat there looking at the screen trying to recall how they did it the year before.

None of this was new. A decade earlier, I was taking notes at a planning offsite with the Systems team. The laptop I was using was connected to a projector so everyone on the team could see the notes. In a quick sequence of keys, I created a blank page, a heading, and then followed that with subcategories and bullets. I didn’t leave the keyboard. My breakout group watching me insisted on knowing what sorcery I conjured to create an outline in such a way. That was typical for anyone skilled in Office.

Every plane trip was a usability test opportunity for Office. Watching a seatmate analyze sales in Excel while simultaneously using a calculator was typical—and spectacularly difficult to watch. The daily work of using Office to create great-looking documents was filled with moments of, “If I could only figure out how.” A common task for many, something like a product description page with a photo with text flowing, was impossibly confounding.

The specific user interface for these and other scenarios were an array of options, terms, and choices that are meaningless at best and destructive at worst. Even finding the right place to make a change was a leap in logic for typical users who did not have the benefit of software design expertise or the constraint of just trying to figure out where to squeeze it into the product. Offenders such as the paragraph formatting or picture layout in Word or the Excel cell format options appear to most people to have the same level of complexity seen in the cockpit of an airplane.

It was as painful for us as it was for customers. We sincerely believed we made things easier over the years. We had come a long way since the first reviews of Word 1.0 for MS-DOS that called it “difficult to use.” We came to realize that after a decade, our user interface mapped directly to the implementation of the product—literally the data structures and structure of the code—and not to the results that a person was aiming to achieve. This was incredibly important for us to internalize.

It was not as though we were the first people to stumble upon the idea of making computers easy to use. It was more that after a good run of nearly two decades of trying to make products using a graphical interface easier, we needed a new approach. The irony was that the graphical interface itself, with its friendly mouse and menus, was supposed to finally make computers easier to use. Instead, more features and capabilities went underutilized and over time no one was around to remember just how impossible to use early software really was.

The earliest days of the graphical interface and the pioneering belief of Office was that consistency was the fastest path to easy. This was especially the case because Office was rooted in a collection of historically different applications. If a customer invested the time in learning one module of Office, then consistency made it easier to learn the next, and the one after that. An entire generation of reviews and industry analysis (and even my competitive analysis of Lotus SmartSuite) dove deep into consistency as a positive benefit. When computers were new to the world, it might have been that consistency felt safe and easy. Even IBM documented a consistent interface for the OS/2 operating system called common user access (CUA) that was to span mainframes to PCs, with a rack of design books for developers to follow (they did not).

The internet changed this for everyone by being wildly inconsistent. The web quickly evolved to a cacophony of user interfaces. The text and pictures, with blue links to navigate to the web, transformed into an environment as diverse as a stack of Gen-X magazines. The important lesson for us was that people didn’t notice. Yes, there were sites that were difficult and sites that were easy, but people adapted to adapting. No powers were calling for a standard interface for the internet. As the essayist Ralph Waldo Emerson said, a “foolish consistency is the hobgoblin of little minds.” This saying was used in an influential academic paper on the pros and cons of user interface consistency that appeared in 1989. Several times as a program manager I made copies of this paper and distributed it.

While the Office Assistant was the last major attempt and failure to make software easier, by Office 2003 the product was filled with a series of widgets and affordances designed to surface features in a more helpful manner. Office became a stage for every designer and program manager idea to make things easier at a micro-level, one addition at a time. What started off as something simple, like keyboard shortcuts and dialog boxes, ballooned into context menus, wizards, panes, and toolbars, all customizable, floating, docking, and resizable. The next section will detail some of this history.

Bloat wasn’t that products did too much. The marginal cost—in dollars, memory, disk space, or vague notions of complexity—was not bloat. We tried reducing bloat by hiding features as discussed previously, but that only added to the mystery of the product. Mac, Windows, and Office all went through periods of “simple means fewer” and tried mechanisms such as short menus, simple mode, or adaptive toolbars. But that frustrated or confused people. No one really wanted to use a simple mode and there was always one command missing that was needed, so simple mode became a complicated way to do that one thing that made someone’s work unique.

We began to consider that bloat was the inability to feel mastery of a product, knowing that the product was capable of something while seemingly impossible to figure out how to make it do that something.

Two important lessons from the product planning and research team solidified our collective view of bloat and formed the foundation of designs.

The first lesson emerged from sifting through usage data. Cameron Turner (CameronT) and others studied the depth and breadth of usage of PCs (how many programs, how often) and also features within Office (what features were used). CameronT was an early PowerPoint program manager hired from Stanford who later left Microsoft to start a company focused on analyzing software usage (long before data science was a hot topic).

Watson crash reports trained the team well to work with the 80/20 rule, and Cameron applied this same analysis to features and commands used across Office programs. Looking at features used by everyone (those who opted-in to anonymous telemetry), 80 percent of the users shared only two commands, Copy and Paste. Said a different way, Copy and Paste were the only commands used by 80 percent of users. In other words, even at the most basic level people used the products in different ways, which was counterintuitive for most observers. At the same time, there were many commands that most people used such as Copy, Paste, Save, and Print. Even then, some commands were not used by even a majority of users, such as Open from the File menu, indicating that a good deal of work happened by opening email attachments or from folders on the desktop. When critics generalized about feature usage in Office, we learned they were almost always wrong.

Importantly, and also counterintuitively, nearly all the commands in the product were used by at least someone somewhere. There was not a lot of dead weight in the product, even accounting for accidental usage or the random case where it was clear a given customer was trying every single thing.

The histogram of usage was steep. There was a small set of commands that represented 80 percent or more clicks and a long Pareto tail for the thousands of other commands.

This second point was obvious to those on the front lines with customers—technical account managers, customer support, and our own sustained engineering teams. Routinely we saw what most would call esoteric use.

The breadth of usage was a major selling point of the product as well. At the high level, while someone might not create a spreadsheet model, that same person might receive one in email. At a deeper level, most in a company might not use a feature such as Track Changes (or Redlining) in Word. But their lawyer would. And contracts or legal letters might arrive via email for review. Rarely used features became part of the work of others. This network of usage was a key advantage of Office and a significant reason behind our ability to win corporate-wide enterprise agreements.

Just as the crash data became an obsession with development and testing, the SQM usage data became an obsession with the designers of our products. In fact, developers also loved SQM data. It gave them a way to push back on program management when they thought spending energy on a feature was a low-yield effort.

The second lesson was about how an individual experienced Office. In parallel, Tim Briggs (TBriggs) was one of the early user researchers to join the Office research team. He began to employ (then) sophisticated eye-tracking studies with volunteer test subjects in our labs. In eye-tracking studies, the test subjects sat in front of a PC and performed a series of typical scenarios. Special cameras were trained on their eyes monitoring where on the screen they looked. A program manager or designer watching the test saw a typical PC screen with Word or Excel running and a little dot flying around the screen representing the subject’s eye focus. The test software drew tracking lines, like a route across the screen, and compiled statistics on the amount of movement, total gaze time, or even how much a subject seemed to look around trying to find something—rocket science at the time.

The results of this technique on Office 2003 were shocking. For basic tasks, if people did not know what to do, they scanned the entire screen in a seemingly random pattern, often for many seconds. They played hide-and-seek with menus and toolbars as they searched for something. The test software generated a heat map, a color-coded view of the computer screen showing where the subject looked most frequently—deep red for the hot areas looked at the most all the way to blue where subjects looked the least. The Office 2003 screen looked like a sea of solid red across the main toolbars and menus. Our test subjects looked everywhere for a long time.

The user interface carefully crafted over a decade was in no way helpful. It was bloated.

Ages ago in ancient Microsoft history there was a debate on the original apps team about what it means for something to be a bug. Is it a crash? Is it data loss? Is it a typo in an error message and so on? Out of that was created a notion of bug severity, a measure for how serious a bug might be from losing all data all the way to simple cosmetic issues. However, when it came to talking about bugs with product support or ultimately customers the definition of a bug was very simple “a bug is any time the software does not do what a customer expects”. This definition created a discipline of documenting everything reported about the product and always making sure every issue was looked at, even if a code change did not result. The key lesson was how helpful an expansive definition was.

In past experiences with bloat, we only focused on two measures. First, we tried to reduce the user interface surface area by simply hiding commands behind context menus or full/short menus or even toolbars to some degree. Second, we spent countless cycles reducing the amount of disk space and memory consumed by Office to reduce the notion that Office was big or slow.

These are both bloat but that is a narrow and technical definition, one that is engineering focused and not particularly useful to customers. It didn’t really matter if the product used too much memory or disk space, as those seemed like symptoms of the whole computing experience.

In the eyes of customers in practice, bloat comes from the fact (using that word on purpose) that Office does so many things that customers just assume the product can do whatever they need it to do. Despite that fact, customers have no idea how to make the product do what they need. This feeling of helplessness that leads to frustration is what it means to deliver a bloated product. It did not matter how many ease-of-use features we added, all that did was compound the problem of too many placers to click. What good is a new wizard or task pane if a person has no idea how to access that or if accessing it will yield the desired result.

Bloat is owning a product that you cannot master. No one felt they could master Office.

How is it that Office managed to get to this point and when did it become a problem?

On to 078. A Tour of “Ye Olde Museum Of Office Past”

Welcome to a new chapter. As we approached the launch of the massive Microsoft Office System 2003, it was time to plan a new release and that started by drawing a proverbial line, at least I felt so. We pivoted way too much to enterprise and clearly lost the “personal” in “personal productivity.” It was not that we needed to go back to just building features for individual users editing documents, but our entire product was just too enterprise focused. While the product group owns responsibility, the whole company focus on enterprise meant that no matter what we did, as the product filtered through marketing to global sales to subsidiaries it became even more enterprise (as we saw with XML rising to the top of the release positioning, for example).

As I later told a Microsoft Board Director, betting on enterprise customers is a Faustian bargain—done right and the business is fantastic, but when you do it right products become rigid, complex, and diverge from the end-user. This next release of Office, Office “12” or Office12, was a chance to rethink the complexity and refocus on end-users.

This necessitated a new approach based on riskier innovation, not more disconnected features in the apps, or a design refresh. Our plan was to combat the notion that productivity tools were “bloated” and “commoditized” with an innovative complete rethink of how users interacted with the product. This was going to be much more than user-experience tweaks or “skinning” as it was called. We set out to invent a new paradigm that built on the classical WIMP (Windows, Icons, Menu, Pointer) taking it to a new level of abstraction more appropriate for modern computing—the use of “modern” would become a big part of everything we did.

As part of Office12, we introduced browser-based versions of many core components of Office in addition to Outlook, added many new features, and dramatically improve the quality and security of the product. As amazing as those would be, the new innovative experience was a “bet the farm” innovation that would dominate all the other features, whether we got it right or not. It wasn’t enough to invent, design, and build the product, but customers had to accept it. Fresh off the success of Outlook’s redesign we were emboldened and confident.

Back to 075. Scaling and Transitions

In 1999, Steve Wildstrom, a widely respected BusinessWeek technology journalist, wrote a series of columns postulating a product called “Office Lite.” The first appeared June 13, 1999 “Office Lite: Less Would Be More.” He wrote one brief column based on a discussion I had with him that spawned a second column and a bit of a letter-writing campaign from readers. It was a classic populist move in the world of tech to solicit readers for their wishes, though usually reserved for the annual “what would be the perfect laptop” column most writers did at the year end.

BusinessWeek printed a few letters but took advantage of the relatively new web site and shared dozens more online. In just about every way the letters showed passion for the concept of a smaller, lighter-weight, more tailored version of Office. What could be better than an Office that was easier to use, consumed fewer system resources, and performed better. . .and cost less?

Readers of the column in addition to Wildstrom chimed in with what features of Office to remove. Word has no need to support complex page layouts. No need to support embedding spreadsheets in word processor or videos in a presentation. Remove Visual Basic from the apps as that is really for corporates and even if it isn’t used it adds complexity no one needs.

One reader provided details on the product in the form of a specification “(1) creating, formatting, saving, and printing a document (2) Creating, formatting, saving, and printing a worksheet and a graph (3) Inserting a graph and an image within a document (4) Creating tables within a document using a worksheet and/or a database (5) Creating and updating a database, and generating a report.”

Also important were what features to keep. There should be a full suite of a word processor, spreadsheet, and PowerPoint (much to Wildstrom’s surprise). Each of those were deemed essential. The file formats should be compatible with “big” Office. One reader insisted Lite include “free spell/grammar checkers in multiple languages for those of us in Europe who still write occasionally in French, Spanish, and German.” And another pointed out “why did you leave Access out of you [sic] suggested suite? I think Access is equally as important to a home user as PowerPoint or Excel.”

Also, it should be cheaper. Wildstrom suggested it cost less than $499, though noted the availability of less expensive Office suites.

A common point expressed was who would benefit from Office Lite. Sometimes readers pointed out they would not use it, but they thought it would be better for their kids or retired people, or just non-technical users. We previously discussed the challenge of feedback when it offers an idea that is good for others, but not for the person offering the feedback. That’s gracious but almost always a sign that the product is heading for poor reviews. Coincidently Wildstrom wrote in his positive review of Office 97 that the Office Assistant, Clippy, would be great for other people, just not him.

This column caused quite stir within the Office team especially in marketing. Honestly, it hit a nerve. For many individuals Office had become too much software. It also touched on the fact that the PC itself had become too complicated, too fragile, and too hard to keep working. Many readers used the word “bloat” to describe Office, a word that appeared a half dozen times across the stories and letters. In the next section we will develop a more complete definition, but suffice it to say between too many features, slow, fragile, complicated, and difficult there is an answer to be found. Customers expressing the concept of bloat was hardly new to us. Our own concerns go as far back as the earliest Macintosh applications when we added “Full Menus” and “Short Menus” to reduce the product’s perceived overhead.

Reading the letters in detail, one could see they made just about every argument as to why such a product didn’t stand a chance in the market. Every person writing in had a different idea of what features should be in such a product and why their features uniquely made sense. Wildstrom included what I shared with him about the use of features in the product relaying "that most people use only a fraction of the features in a program such as Word. But everyone uses a different fraction, so there's no way to design a simplified program with broad appeal.” His readers made that very point in their own way.

In my numerous discussions with Wildstrom over these columns (and basically at every meeting) I would point out that we already had “Office Lite”—called Microsoft Works. That was my refrain for years when it came to the need for a low-priced, slimmed down version of Office. In the mass of letters to BusinessWeek someone else, someone with an informed opinion, agreed with me in their letter:

We'll [sic], you're right to be championing "Office Lite," but you're wrong to be dismissing Microsoft Works for the job. Sure it has many inadequacies, but saying it needs features X, Y, and Z to warrant your recommendation is to set your steps in the direction that led to Office 2000 bloatware.

Peter NortonLos AngelesNorton is a pioneer PC programmer and author of numerous books on PC software.

We offered Works at about $100 and Office SKUs at different price points ranging from about $149 to $499, including Student & Teacher, Small Business, Standard, Professional, Developer, and Enterprise. By most definitions in pricing architectures, we were meeting customers at low, medium, high, and very high prices with products offering different value propositions. It should be apparent, however, there was hardly a consensus among the press and its readers on what an alternative price and value structure might look like.

Microsoft Works was an early success, a genuine hit product for the company. Version 1.0 was released in 1987 and joined the ranks of the wildly popular category called all-in-one or integrated software. The category aimed to take the popular modules of productivity and bundle them into a single, easy-to-use, and low-priced product, usually including a word processor, spreadsheet, and database (Works included a communication module as well).

The basic assertion was, and keep in mind how early in the PC era this takes place, that the full-priced products were too expensive and did too many things (had too many features) and most people needed only a fraction of the product. This was bloat even in the earliest days of computing. Works sold for about half of what a single full-priced product cost and ran on very basic PCs with merely 384K of memory. Works was hugely popular outside the US and was localized into dozens of languages, often a tricky proposition in the days of MS-DOS software. Works was a marvel of engineering built with great passion by a small team, and thus extremely profitable.

In 1991, Microsoft released the first Windows version of Works, for Windows 3.0. Again, this product proved popular, though not as much globally where Windows was a slow burn due to hardware requirements. Works for Windows, or WinWorks as we called it, introduced some of the early toolbars and wizards. It was developed in the Consumer Division, home of those inventions and to product teams entirely focused on the home and student markets. WinWorks also supported OLE (Object Linking and Embedding), the enormously complex to implement capability to include data from other applications inside of documents and even included an early Microsoft drawing program to show off that capability. Microsoft made works available for less than $200 at retail and often for only $10 to PC makers looking to include basic software with a new PC. By 2003, Works included a broad range of software for the home user in addition to the all-in-one product including personal finance, maps of the world and major cities, an encyclopedia, a sophisticated photo editing program (PhotoDraw), and somewhat surprisingly the full and current version of Microsoft Word.

On the surface Microsoft had addressed the classic marketing problem of low-end and high-end with price support at the low-end. We could sell Works to price-sensitive customers and Office to everyone else. With the PC manufacturing channel, we could even tactically go after market share for certain PC models aimed at home and small business customers. Like all good marketers we would only sell Works when we had to, with all marketing and sales efforts aimed at selling Office. Even the Works customer would see opportunities to upgrade to Office. That seemed simple enough. On paper this looked like a great spot to be.

There were two problems. First, Works was not compatible with Office. It was only marginally similar in how the user interface worked and not at all compatible with files created by Office, nor was Office able to read Works files. Why would this matter in a world without networking or email? It didn’t. Any given person would just use one or the other and it would be fine to print documents when they were finished with their work. But in our world, the press would ask questions and then make assumptions that all products from the company would interoperate, and by the early 2000s emailing documents was becoming a scenario for many home users. This product limitation led to the eventual inclusion of Word, though not Excel or PowerPoint, in the Works bundle. We failed these tests and too often the product was labeled as incompatible, and in the PC world incompatible is a big blow. Customers expected compatibility from Microsoft.

Second, and this gets to the heart of the matter, people didn’t desire the product that did less. They wanted all the bells and whistles of Office. They just didn’t want to pay full price, or they didn’t have a computer with enough power to run Office. They wanted a more powerful computer and would almost certainly invest in that rather than stop-gap software for their current computer. We had a classic revealed preference problem in customers saying one thing but choosing to take a different action. There was no way around this—customers just wanted more product for less money.

This second point is the marketing challenge everyone with a successful product in software faces at some point.

The natural inclination is to remove some capabilities and charge less. Usually, it is possible to remove features that only a certain customer segment wants (enterprise for example) and that keeps the price low for customers that do not need such features. Today we see this as routine practice where a low-end or even free version of a product is used to upsell to increasingly expensive and feature-rich versions. Again, on the surface this is what we had for varying suites of Office, but we did not have that for the individual applications in Office.

We had a pricing problem. We did not have a product problem in the sense of getting value for the money paid. Customers wanted the value, just not the price. They also wanted the product to be better and sometimes they equated the high price with the reason it was not better, as if a lower price would require less disk space or be easier to use, for example.

Office also faced a competitor with a much lower price, free. Such a competitor is an especially acute problem when that product has a comparable feature set, whether that is real or simply perceived as such. OpenOffice claimed to be compatible and was certainly more compatible than Works, and it also claimed to have the features of full Office. If it was missing features, they promised to add them as soon as possible, just as I personally learned when they changed the product on a tradeshow floor to be more like Microsoft Office.

The scary question for us was would Office be susceptible to defeat in the market by a direct clone. Borland had been successful at making a dent in Lotus 1-2-3 sales and with the relaxed view of copyright law in the courts this seemed a legitimate concern. Still, the technical requirements to acceptably clone Word, Excel, and PowerPoint seemed insurmountable. We knew this because of how much effort it took us to maintain compatibility and document fidelity between our own versions with our own engineers.

In an interesting twist, some enterprise customers equated the low or free price of competitors with low-quality.

In other words, our pricing challenge was not as straight-forward when looked at broadly. This mattered because software did not have highly specific distribution channels like cars or mattresses where we could control which channel sold which products.

The legendary author and marketing guru Geoffrey Moore visited Microsoft in the early 1990s to meet with a few of us to talk about Office. This was before Windows 95 and 32-bit computing, before Office had “won.” Our minds were on adding features and getting new features to market to compete with the category share leaders that dominated the industry by revenue. The conversation was deeply interesting when I look back, though at the time it was not as relevant to Office as one might have thought.

According to Moore as per his Crossing the Chasm framework and book, the PC was still in the early adopter phase. Moore suggested as per the framework that we needed to consider products for specific subsegments of early adopters (legal, financial, consulting, education) providing versions of Office for each of those in succession as we grew the market to later stages of technology adoption. We were worried about price support versus Works, not against a competitor selling a different product specific to bankers or something. Tailoring Office for specific customers, however, was in some way the role of Works, except rather than job title it was skill level or distribution channel. The real mismatch, however, was that we were not struggling to gain adoption with the personal computer. We didn’t have a crossing the chasm problem. We just had to wait for people to have enough money to buy a PC and pay for the software. We didn’t have a segmentation problem. Everyone wanted Office. We did have a revenue maximization problem. We didn’t want a lot of people buying Works.

One problem we did have was software piracy. It was long a bane of Microsoft’s as the company was founded on the premise that software should be paid for just like hardware. Piracy of Office had grown astronomically. We estimated that perhaps 1 in 10 PCs paid us for an Office license, but more than half the PCs out there had at least one major Office application. It was technically easy to pirate Office as we did not employ any countermeasures as were common to software products in the 1980s. With the release of Windows XP (Windows too had a significant piracy problem), Microsoft put in place a global software license enforcement program much to the chagrin of tech enthusiasts and early adopters, not to mention small businesses that often bought one copy of a product and just assumed it would work for a workplace with a few PCs. To say this program was met with mixed results would understate the uproar. Some whole countries prohibited the use of anti-piracy measures and others mandated different mechanisms or terms of use. China officials famously lectured many of us (me personally) by applying lessons from the writings of Confucius (always said with erudition), “software is like a book; it is selfish not to share.” I never looked up if that was an actual quote, but ministers and vice ministers lectured me enough I took it as such.

The result of high piracy? In many markets, customers simply stuck with the older and easy to pirate version of Office. On trips to markets from Italy to South Africa to China, members of the team would invariably return with a CDROM filled with Office 97 and everything Microsoft made five years ago bought on the street for $5. On a trip to China during the launch of Office 2003, I went to a tech market where I was offered a form to fill out where I picked what software I wanted up to the 650MB limit of a CDROM (Office 97, Windows 98, and so on) and within an hour I received my custom CD for just 20 kuai (less than $2).

Absent Microsoft corporate backing off from anti-piracy, something the field salespeople desperately wanted us to do, the calls for a cheaper version of Office were constant. They weren’t quite sure what that would be, but they didn’t want people to like it so much they would buy it instead of the Office that carried a sales quota. Many of the subsidiaries would try to make a case that people could not afford software, even though I saw the price of PCs at the market mirror those in the US, or in some markets such as Brazil PC prices were even higher. The issue was there was a way not to pay, not a lack of ability to pay for software. SteveB loved to point out that the computer market was located near an imported car dealership complete with Lamborghini and Ferrari on display.

The PC itself was also under attack for being too expensive. The One Laptop Per Child (OLPC) initiative out of the MIT Media Lab started in 2005 to address this concern with the goal of providing an extremely low-priced computer running free software for students in emerging markets. Windows quickly followed with their own effort to build an even cheaper version of Windows. This will not be the last of this challenge for me or the industry.

Given this context, the refrain for a low-end variant of Office had been echoing in Redmond for years but now was reaching almost deafening levels. I didn’t really have a choice but to start a project and see where it went. I kicked off a unilateral skunkworks project (without marketing or broad buy-in) to see if we could come up with something that would end this endless discussion. The project even had a code name, Firefly. You can always tell when I wasn’t wild about something when I gave it a code name. The team needed to go through a process to bring closure once and for all. With most of the effort centered on the user interface and access to features, Julie Larson-Green (JulieLar) led the effort from Office program management where she was now leading the shared user-interface team, moving over from FrontPage.

We completely understood how every other product from cars to microwaves to stereos had a cascade of price points for basically the same product. The difference for Office is twofold. First, software is soft, and the marginal cost of more features is zero and customers readily see that. Second, interoperability between price points is key in a networked world and maintaining interoperability when different users can be editing a document with what amount to different tools all at the same time was technically difficult to imagine getting right.

I kicked off project Firefly, which quickly became known as Office Lite, knowing (perhaps that is too strong, I mean assuming) we would go through the exercise of figuring it out only to conclude that no one at the company really wanted it. No one would want to be responsible for releasing a product that was either so bad no one wanted to buy it and the Office brand would get devalued or so good that our enterprise customers would insist on having the Lite version of Office for much less revenue.

The reason I picked a code name was because the mere expression of Office Lite (or Office ES, or Office Prime, or any other marketing moniker) would cause customers to say, “that’s the one I want.” They would do so by attaching all positive attributes to the product: just the features I need, easier to use, boots and loads faster, takes far fewer system resources, and because of those attributes it is also less buggy and won’t crash. There’s something about how low-end products always garner catchy names. Sure enough the name “Office Lite” leaked to the press and customers early in this process.

Our new leader for Office marketing was hired from Adobe. They had not only faced the same problem but tried to do something about it. With its PDF product, Adobe had been struggling with the classic strategy of a free viewer and a paid-for product with the ability to create PDF and a better viewer. The problem they faced was that creating PDF was rapidly commoditized and free (this is the topic of a future section in this chapter as well) and few people needed the advanced viewing features, and certainly not for hundreds of dollars. With their flagship Photoshop product, Adobe had been trying to seed the low-end market with Photoshop Elements (there’s that catchy name) side-by-side with Photoshop. This product still exists today, so we can assume it works for them. I’d say it works so well because you never see it being used (of course I have no data on the real usage and am just speaking anecdotally). This Adobe experience led me to believe that Office would be viewed through this same lens by marketing.

The first step in developing Office Lite would be to go through an exercise where we removed a bunch of features from the product. Doing so technically is not difficult, one would think, but in practice the list of hypothetical problems gets very long very quickly. As an example, someone creates a template in Word that makes a document look a certain way. The document is then sent to someone else who has Word Lite. Can they see the new look? Can they edit the new look? What if they try to modify text within the context of formatting that looks a certain way? How do formulas work in Excel? Does Excel Lite have all the same formulas? What if a spreadsheet with a Pivot Table is sent to an Excel Lite customer, can they pivot it? The list goes on and on.

The fun part of this exercise was just how easy everyone thought it would be. Almost to a person, the first things to be removed for Lite were Visual Basic for Applications, Mail Merge in Word, Pivot Tables in Excel, animations in PowerPoint, then circle back to Word and remove features like table of contents and legal citations, track changes/revision marks, and so on. Everyone brainstorming found it easy to make their own list of easy to lose features.

There’s a core assumption these features aren’t used and so it is easy. That’s the problem. Everyone had an easy time removing features they believed they didn’t need. How does that reconcile with creating a product that the enterprise customers would not want? It doesn’t. In the next sections we will dig into the realities of what features are used or not as we design the next release—we had the real-world data on usage. For now, suffice it to say that it is very easy to make a list of features to remove but very difficult to remove any features that cause customers to feel they need the full version of the product. Those are painful decisions.

Some discussions became almost comical. One of my favorite examples had to do with documentation. For years, Office produced weighty tomes of printed books of documentation that more often than not served as ergonomic monitor risers if the end-users even got to see them. With the rise of enterprise agreements, we moved most documentation online. With the internet we were very excited to have always improving documentation available directly from within the product. One of the key differentiators for Office Lite was a proposal that the only documentation be available as a printed book that would come with the product and no online documentation or connection to the web. We no longer had the ability to produce printed documentation, and before I knew it someone in marketing already put out bid proposals to publishers to create the book for us. The cheap to make Office Lite was getting to be more expensive and have a higher bill of materials than the real Office.

One person who was hardcore about what not to remove was BillG. I exchanged mail with him over some of the rumors he heard about Office Lite and he came back to me saying exactly what I predicted he would say, which is we can’t remove any platform features, such as Visual Basic for Applications. A lesson learned the hard way with platforms is that platforms must be consistent for developers to choose to use them. While it is fine to adorn the platforms differently for various price points, anything a developer might want to use must be in the baseline SKU. Otherwise, they will work around it and either implement something on their own without using the platform or simply not have a feature. That’s why every Windows API is in every Windows SKU where developers can always count on them being there (recall the Tablet PC discussion).

Cameron Turner (CameronT) on the product planning team developed a framework for the brainstorming efforts for Office Lite. I gave up calling it Firefly. These goals included: great for creating simple documents, a great viewer for all Office files regardless of where they were created, effective competitive response to low-end competitors, smallest delta from full Office to reach design goals.

The team also developed a view of who the product was not going to be for. Office Lite is not for: group collaboration, data analysts, developers, online communicators (no Outlook), “beginners”, or multi-language document creators.

The Office team was long expert at resolving what appear to be impossible to resolve challenges such as shipping on time versus shipping with quality. The Office Lite goals, however, were almost certainly, perhaps mathematically, unsolvable. Even something that to Americans seems simple like not supporting multi-lingual documents, becomes problematic for sales even in neighboring Canada. The most unsolvable constraint was that the product wasn’t for beginners. If not for beginners or the home and not for specialists in finance or law, then who was the product for? Who is this broad middle and what are they doing? In this stage of PC expansion, there were tens of millions of customers getting their first PC and first use of Office at work. They were beginners too.

Rumors about Office Lite started making their way around Microsoft. Marketing teams across the company were getting very excited at the prospect of a low-priced Office because for some time they had wanted to have the Office brand associated with their product, but the price was too high. The Windows OEM group, the team responsible for selling Windows to PC makers, wanted nothing more than Office attached to every new PC “socket”. They hated selling Works because it was so cheap. OEMs expected Office Lite to be only marginally more than Works. The emerging market teams loved the idea of a cheaper Office.

Then people started to think through the issues and how revenue would suffer. Not just revenue, but the sales quotas carried by each subsidiary and sales segment.

It didn’t take long before the Office small business marketing team would come to realize that if every Dell Small Business PC came with Office Lite presumably because the OEM team was successful, they’d never make their numbers for selling the Office Small Business SKU. There weren’t enough small business PCs to make it up in volume.

The MSN, Microsoft Network, team was working hard to develop a paid offering because the advertising business was not yet large enough to sustain the investment we were making (recall the pressures mounting on the investment businesses from the previous chapter). They were very excited about being able to bundle Office Lite with a new MSN subscription. We had not yet arrived at a price, but it was obvious that like OEM they though it would add $1 or $2 to the monthly subscription, which was a Works level of pricing, not Office.

Then the other shoe started to drop. Not just the BillG shoe but the global enterprise field. Suddenly my inbox was filled with subject lines “Rumors about Office Lite,” “Concerns about Office Lite,” “Office revenue goals and Lite.” These emails expressed incredible reservations about the potential for tanking the existing business in favor of a product that, by knowing only the name, the salespeople thought was too desirable for too low a price. My good friends in MSKK (Microsoft Japan) sent me a note directly stating they decided not to offer Office Lite in their market. They were so against the idea they just presumptively closed off any discussion in the most non-Japanese way I could imagine.

Problems such as these could be solved. Many businesses solve them all the time. Cars have low end models with a magical suggested retail price, but they do a fantastic job constraining supply of that model. Consumer electronics (including PCs) almost always have good, better, best, but these are often easily distinguished based on capacity measures (memory, watts, screen size) and also by distribution (where the products are sold). Imagine if Word Lite limited documents to 10 pages or Excel Lite had row and column limits.

Software, especially when exchanging data files and documents in a network, do not lend themselves to these artificial constraints. Those that grew up with IBM mainframes know the frustration of IBM upgrades when customers would request a higher-priced hardware upgrade and a tech would show up and simply crack open the case and turn a screw to enable the upgrade costing thousands of dollars per month (this didn’t really happen, but the stories were legendary).

Unlike these other products we were also squeezed at the high end. Office for enterprise customers is designed to be a bundle with everything we sell. As discussed with the addition of Outlook, SharePoint, OneNote, and InfoPath, there was no support for adding more expensive enterprise “bits.” Today many cloud software applications save enterprise capabilities such as security and management for the high-priced (or just priced) SKUs. With Office, 80% or more of the revenue was already coming from the enterprise SKU. There was no appetite to move up with higher prices, which could make the lowest priced SKUs more price-friendly.

The process of planning the SKUs for Office 2003 was an exercise in chasing our own tails, so much so that we spent a significant amount of engineering time to create a push-button feature that enabled the production of a new SKU (a different combination of the 11 different applications) to be created without additional code or testing. This came in handy as the Office System 2003 Editions were rolled out with seven different SKUs.

We started to toy with the idea of being able to dynamically enable or disable different features in this same way so we could make progress on whether Office Lite was even possible. At the plumbing level this was not difficult but with thousands of features and product design elements such as toolbars that depend on features existing, it was not practical.

The design started to go from brainstorming to an actual product offering in a table form. Suddenly, Office Lite did not look so good. After all the sessions over features to remove, the desire to remove features faded away. The team created a table comparing the proposed Office Lite product to competitors. The resulting table was a disaster. It looked like one of those magazine reviews where a product gets clobbered for missing all the checkboxes. After getting feedback from the subsidiaries and hearing their lack of desire to even offer Office Lite, the risk of the subs failing to make their numbers and blaming Office Lite became real. The reality that Office Lite would be a non-competitive product versus our free competitor sucked all the excitement out of the potential offering. It didn’t matter what we removed from the product, OpenOffice could just add it to their product, and charge nothing.

Office Lite was dead. Again. We had to win in the market with a better product that cost more. We had the product people wanted and we needed to sell it harder if that’s what it took. Today we know we had product-market fit and a little thing like pricing was not going to be our biggest problem. By comparison, the Office price of $499 for a perpetual (runs forever) license of Office or the roughly $150-200/year for an enterprise 3-year agreement is comparable to an Office 365 today that can easily cost an enterprise more than $650/year per license, though Microsoft is running Exchange and SharePoint in the cloud in these plans.

What was not dead, however, was what got us talking about Office Lite in the first place. The customer concerns were not really about price. Price was a proxy for bloat. We needed to address bloat. We tried before but now it was critical.

What the heck does bloat mean?

On to 077. What Is Software Bloat, Really?

Wrapping up the development of Office 2003 was an enormously challenging time for me personally, while the team continued to do well finishing a release with an unprecedented breadth and depth. At the executive level the company was under enormous strain, not because of a lack of business results (quite the opposite), but from what the NY Times called a "popularity problem". The core business was less dependent on Windows than ever before and in fact the percentage of Microsoft revenue or profits from Windows likely peaked. In addition, the Server business and Office were doing extremely well. Few companies have more than a single tier 1 business, let alone nearly a dozen billion-dollar products. Wall Street, however, was no more happy with Microsoft than it was with most every other company. In 2010, the "lost decade" was used to describe the lack of broad stock market returns over the past decade (2000-2010). Some began to apply that to Microsoft specifically with the rise of Google, then Facebook, and Apple’s resurgence in consumer devices. This post details the start of that period and I will leave it to readers to judge if this was truly such a start, or if indeed, we simply had a popularity problem, or something altogether different.

Back to 074. Outlook Pride, Finally

Over the course of building Office 11, Microsoft began to see cultural transformations that in hindsight were the product of trying to mature as an organization while not taking on the risk of changing as an organization. It was as though we wanted to add all the benefits of a coordinated, multi-dimensional-thinking, well-executing, mature company while at the same time not taking away the hardcore, code-centric, engineering-driven culture that got us to where we were. The goal was laudable. How could it not be? The only surprise was how long it took us to get to this point.

Around the company we were not executing well, not even a little bit. To some, however, it felt like we were executing. That was only because we had so many activities going on. Everyone was very busy (just try scheduling a meeting with someone) with launches, pre-releases, community gatherings, partner events, PR outreach, ecosystems, big reorgs, offsites, slide decks, spreadsheets, reporting systems, and more. The airmiles were accumulating at a phenomenal rate. A big company has an ability to show a great deal of activity even with little progress. What wasn’t happening was new product innovation, except financially. That distinction is important. The money was coming in but that was for all the products we had already built, in some cases several years earlier.

Microsoft saw less than stellar success across most of our new initiatives. If the primary goal was to gain market share, then we were losing.  SteveB used to say “share is air.” Whether it was phones, consoles, web sites, advertising, and so on, the first few years of the millennium looked like the dot com startups we had ridiculed. To clarify our new initiatives, Microsoft began to report earnings across seven operating segments: Client (Windows), Server and Tools (Windows Server, SQL Server, Exchange, Visual Studio), Information Worker (Office), Microsoft Business Solutions (Great Plains/Dynamics), MSN (all the “consumer online” properties), Mobile and Embedded Devices (Windows Mobile), and Home and Entertainment (Xbox, consumer hardware). Every earnings call and cover story about Microsoft asked when these new businesses would become “profitable”. The calls for “when will you win” were deafening.

Such a question was a naïve approach to how business worked, but that’s how bringing visibility to a product under development is talked about (anyone who has run a business knows that new products are not profitable at the outset and take years for a full P&L view to look profitable, but that’s not how people comment on earnings). At company meetings or routine team meetings, SteveB had a great series of slides where he emphasized the long-term nature of Microsoft’s approach and what it means to invest in the future—“investing” Steve would always emphasize. As a reminder, Windows took at least six years and three major versions for it to become a significant product. Had Windows been reported separately from MS-DOS it is not clear Wall Street would have been forgiving.

The new businesses were still much newer and were part of a vastly larger landscape than Windows or Office were years earlier. Combined, the four investment-mode new businesses (MSN, Mobile and Embedded, Home and Entertainment, Business Solutions) had a (FY 2003) negative operating income of $1.6 billion. Windows, Server and Tools, and Information Worker had an operating income of $17.9 billion, on total revenue of $32.2 billion. In other words, there was no material risk to the company due to these investments, nevertheless losing money or failing to pay off began to permeate the whole of the company’s operating model and external narrative. Culturally, we weren’t used to negative numbers.

There was an additional problem that drove operational changes. The Windows team began to have the signs of a product spinning out of control (my words). The company was experiencing in real-time what SteveB and I discussed in his first series of one-on-one meetings when he became president a couple of years earlier. Big projects can seem to go from execution to out of control in a flash—there is a fragility in large-scale software projects that we had yet to fully grok. The time it took to complete Windows XP SP2, the resulting desire to produce separate releases for Tablet PC, Media Center, and Windows Server, and expanding strategic inputs from BillG shaping Windows development created a situation where the Windows XP follow-on release, Longhorn, was either “at risk” or “out of control” depending on who you asked. In practice, some still believed it was a typical Windows product cycle.

Beyond the new businesses described by segments, Microsoft had a seemingly infinite breadth of new products under development. Few areas of software went unnoticed without a Microsoft group claiming to be in the space. Yet, we lacked clear strategic view or even line of sight view to all these projects, if or how they fit in, when they might deliver, or what progress they were making. A skeptic would say this was an additional level of potential negative ROI hidden underneath the success (or not) of each segment. Optimists would say this was entrepreneurial thinking at its best. The challenge was that as primarily an enterprise company, the customer demand for a strategy, unification, and clarity were ever-present.

Seeing these challenges drove a shift in how the company operated, at least I that was a root cause. A pendulum swung away from autonomy and lack of rigorous strategic and execution oversight at the top-level towards a more centralized approach to planning and execution. In any business environment I’ve seen, when things aren’t working the inevitable solution is to swing the other direction of some easily identified pendulum. In our case, that meant more corporate standardized processes.

I found such a change challenging (for me in Office) in two ways. First, it felt to me that Office didn’t have these problems. We were executing well and had been for a long time. We had processes and delivered results—even when our projects were late, they were not unbounded, and we promised and delivered on plans without any gaming or redefining of deliverables. Second, the problems seen in these new businesses could look like execution problems, but as we’ll see over the chapters that follow, they were fundamentally strategy and manager (versus management) issues. It wasn’t enough to work to get the trains to run on time if there was no understanding of where the trains should run. Some of the projects were running well, but the destination was poorly understood.

That was my perspective. It was not shared by everyone for two reasons.

First, just as with any business if one wants to make a bear case then that would be possible for Office. What if customers rejected a new version? What if open source OpenOffice took share? What if web-browser Office became a thing suddenly? What if we were out of control and just didn’t know it? We just weren’t going to be blindsided by those in 2003, but there was no way to prove that. Any attempt just sounded defensive. I sounded defensive far too often and that was not good.

Second, the company model for all the new businesses was to be a platform. What do platforms need? They need Office to build on the platform to prove it out. Any lack of success in the new businesses was therefore strongly connected to something the Office team was not participating in. As such, their problems were indeed Office problems. They were my problems. I didn’t really believe they were my problems, and my rolling eyes or audible sighs were the tell.

I was busy finishing Office11. That’s what I knew needed to happen, deep down. Putting up with all that was going on around me I thought added a second job. The Office team had gotten so good at planning and execution that there were plenty of cycles remaining for me to focus on those goings-on, even if I did not find doing so pleasant.

Was this the moment when dreaded bureaucracy was settling in? If only Microsoft would have realized as much, might we have avoided a “lost decade” that followed? The expression “lost decade” became a popular way to describe overall stock market returns in 2010 since the dot com bust. The press started to refer to Microsoft’s own lost decade. In contrast to the broader market Microsoft had a “popularity problem” to quote the New York Times, which said “the company hasn’t received credit for its almost-half-full glass: the 40 percent of its business that is not Windows or Office. . . its enterprise software business, formally labeled Server and Tools, as ‘an incredible business’ accounting.  .  .for about 24 percent of the company’s revenue and with an operating margin of 40 percent.” We were putting up the numbers but unlike Yahoo and Google we did not have a consumer business, and because of the internet and the rise of Google that was all that mattered. Yet, that was by design. We were not putting in place an arbitrary bureaucracy or processes, but the logic behind the changes was to try to have it all: an enterprise business, a consumer business, competitive products, and an overall technology strategy. We were not lost as much as trying to do a lot. Maybe too much. We were Microsoft and we thought big. What’s wrong with that?

Dealing with these processes was challenging for me and it showed. Some aspects were always going to be my style. I did not have a staff (a business manager and/or chief of staff for example) who could spend full time in the preparation meetings for the larger meetings. I made slides I was responsible for by myself and got them done on time, but without endless iterations and sweating over every point that can come with a staff working full time on slides. In doing so I wasn’t always part of the month of pre-meetings leading up to meetings and did not always have the context for when something new became a hot topic amongst the staff (what is the Office answer for “healthcare” that came up in an earlier meeting or what are we doing about “small business” that was in that mail thread from UK). It was obvious to me that the processes were an effort to bring the rigor of the Mid-Year Review (MYR) process used by the subsidiaries and field to product development. It was never clear to me, however, that sort of process would work for the creative and uncertain aspects of product development. I was frustrated that no one ever asked for input over what we were being asked to do.

I believed that tired cliché about building products, which is you can’t know everything before you start but you can cause everything to grind to a halt by asking questions at every step or thinking success can be known before we start. I held that romantic view that building products is an art, and no quantity of meetings could turn it into a science. Perhaps the most frustrating (to others) belief I held, was that questioning too much after a product started was a sure-fire way to bring chaos. That’s what I saw happening.

I agreed with the problems that preceded these process changes. I didn’t see processes as the solution. We were not going to fix things by having better slides or box diagrams. We weren’t executing because we lacked the planning infrastructure and organizational structure that was required to deliver. Such a point of view, however, was difficult to prove because the very nature of the processes we were going through (with names such as Business Plan Review or BPR) was to surface the planning and org structure issues so they could be fixed. We were caught in very tricky loops.

“Competing with Linux” was a long series of meetings that was top of mind for the Server and Tools business and illustrates this point. I was running Linux at home. It was comfortable for me as it brought back muscle memory from college and graduate school (that was technically Unix, just to be completely accurate), but importantly it brought back a lot of technical reminders about the architecture of Linux. Office also experienced the rise of Linux through FrontPage, which achieved far more success connecting to Linux servers on the internet than anywhere (or anyone) else. This would serve me well in the product-led discussions, as would the feedback from internet service providers all running FrontPage on Unix and not Windows NT.

Strategy and execution meetings about Linux were overly focused on the immediate crises of head-to-head sales losses. What should be our pricing? Are we positioning correctly? Do we need a better partner? Many in product groups (the development teams) were familiar with the technology, many deeply so, but the product plans did not reflect Linux as a competitor when viewed through the lens of resource allocation and feature lists. It was as though there was broad acknowledgement of the competitive issues without responding with product plans. The basic idea was that we could win if we didn’t change any of the product plans, where the list of must-do features for enterprise customers continued to grow. The real problem was that the business results made this look like the right decision. The sales of Windows Server continued to rise, and Linux was still free as in free like a puppy. We were winning at least in appearance.

From any objective distance, it became difficult to see the difference between how Windows and Office responded to Linux or competitive risks in general. If I suggested Linux was a real product competitor requiring a significant change in product features over what we would do if Linux wasn’t on our radar, then I could just as easily be challenged over responding to OpenOffice. . .”you lost that sale to the German government didn’t you?” they would knowingly ask. A response claiming it was different just made me look like I too was dodging the issues around Office or something akin to whataboutism.

One Linux review meeting reached a surreal phase when the whole of the all-day meeting with hundreds of slides and many presenters boiled down to a request for headcount in order to effectively compete with Linux. As a matter of practice, that was not how meetings were supposed to go. Headcount requests were for another meeting and process. As though it was to emphasize the matter, the actual headcount ask was for two, yes just 2, heads. The entirety of the strategy to compete with Linux from a 10,000-person division required asking for two heads. It was as crazy as it sounds. To his credit, SteveB was not happy with the ask and the team was not happy with the response.

I hesitate to write the above because my experiences at this time could not possibly reflect experiences of the thousands of people during this same transition. It is not even clear to me today what were causes versus correlations of the challenges we faced. Frankly, some of what seemed so wrong then turned out to not matter at all to where Microsoft is today. Such are complex stories. Such is product-market fit, which is likely the most important lesson. We had the most amazing product-market fit, which (at least according to theory) meant it hardly mattered at all what we did.

Through these new processes I reluctantly learned to be pretty good at telling the Office story with respect to execution. I became well-versed in explaining how we worked, organized, planned, collaborated, and executed. I spent an enormous amount of energy detailing these topics to anyone that would listen. Even very small details such as knowing how many people worked on a given project, something we routinely did for years, would take on almost mythical status as SteveB would ask other groups for a report that looks like the one from Office. They would often ask to connect with the staff that created a chart only to find it was usually just me. There were no secrets. We just did the work, but it did have a cost.

There was some personal history to my desire to do a good job explaining resource allocation within the context of this new business planning framework. Back when we organized for Office9 (Office 2000) one of the significant decisions we made was to allocate resources even more towards Office suite-wide development and also to what would become SharePoint. In doing so, the number of developers on Excel, for example, reduced from an historic high of 50-55 to just under 20. There was controversy and disagreement within the Office team, but that was no match for how BillG viewed such a decision as nearly irresponsible. Yet in a short time it became clear that reallocation for products that had won was a much better approach than to continue to incrementally pile on resources. In real-time, both BillG and SteveB got to see the culture difference between Windows and Office when it came to embarking on new projects. Everything in Windows always seemed to be incrementally new headcount (like Linux compete) and everything in Office was a reallocation. I didn't realize it at the time but using today's terminology I relied on the product-market fit achieved by Word and Excel. We just weren't going to lose in the overall Office business because of incremental features we failed to add to those products, even in 2001.

Counting developers became an obsession with me. Starting in Office 2000 I even did a census where I asked each developer to add a row to a spreadsheet saying what they worked on in their own words so I could compare it to the schedule, the vision, and what team they were on. After that we even started using unused columns in the SAP employee database to record what part of the project a developer worked on—that way the information was always available live and could be kept up to date as employees moved around the team. Any time someone asked me how many people were working on some aspect, I just brought up http://headtrax (the internal front end to SAP data) did a few queries and there was an answer. For data across the whole team I’d just export to Excel and create a pivot table.

Such attention to resource allocation was seemingly encoded in my Apps Division DNA. It came from a reality that it didn’t matter what a team said they were working on, rather it only mattered what developers were actually assigned to. As the company grew and cookie-licking became more common—when teams declare they own or are driving a critical initiative but are doing so without the work or resources to support it—the need to bring clarity to those discussions became even more important. I only wished at the time that more teams had clarity of resource allocation reflected in SAP.

Managing personal time was just as important as clarity on developer allocation. Following a lesson I learned from SteveB for the past few years I tracked where I spent time during the day. How many 1:1s, product meetings, customer and partner meetings, skip-level 1:1s, team meetings, and so on. I did this in a very lightweight manner attaching a category to Outlook schedule items. Every quarter I exported my calendar and created an Excel pivot table of hours spent on these categories.  Over the course of developing Office11 I noticed that I was spending more time in what I labeled “process”, the corporate driven planning and coordinating meetings and that was taking away from ad hoc time just talking with people in the hallways or more structured time with the team. I found this disappointing, if not depressing. When I discussed this with my manager or Steve (in a skip-level with him), usually the feedback I received was that I was not spending enough time on corporate. Somewhere between too much and not enough was probably a better answer. I had reached that point where I felt caught in the middle and failing both of my constituencies. My algorithm for addressing this concern was that the team always won out, whenever it could. I just felt so much more useful in working with the team than in corporate rituals. It was easy to feel good because we were making a ton of progress, especially comparatively.

The team was doing a fantastic job finishing Office11, which was formally named Office 2003. Well, not exactly. With new marketing leadership in place and a mission to be more aggressive along with license to spend more doing so, the product branding was brought more into an enterprise perspective.  Office suites sounded so small. We had so much more software. The entire collection of Information Worker software was branded “more than what it used to be” as “Microsoft Office System”, “now an integrated system of programs, servers, services, and solutions”. The suites of Office programs typically bought were called Editions. This meant Office11 was officially known as “Microsoft Office Professional Edition 2003” or as humans called it, Office 2003.

JeffR approved a major advertising campaign to go with Office 2003, over $150 million, five times the $30 million spent on Office XP. It was one of those campaigns where even the campaign itself gets a PR push and stories about it—marketing of the marketing team. The campaign covered print, online, television, and more (such as airplane video). Called “Great Moments At Work”, the campaign was a playful take at workplace successes as though success was celebrated like sports complete with pile ups and high-fives. The ads were fun. The print ads used photos of the same scenes but emphasized the sheer breadth of Office System software.

Breadth was an understatement. The sheer volume, or mass, of software being released as one product at one time was overwhelming for customers and the press. It wasn’t just that it was overwhelming in quantity, but the features individually were so deep, so complex, that few could really understand them well-enough to provide detailed reviews. The product guide we distributed to reviewers and the press was 170 pages, a book! The Microsoft Office System Evaluation 2003 Enterprise Edition kit consisted of 11 CDROM discs and two discs filled with various technical and overview documents, demonstration videos, and an entire disc-based website of Macromedia Flash content. It seems easy to make fun of this today, but then one look at the web site for Office 365 and I guess one could long for the finiteness of a bundle of CDROM discs.

Outlook was the hero of the release, with a little bit of OneNote from the press as expected. From junk mail to the new user interface and especially more reliable mail delivery, Outlook finally achieved status as a first tier Office application. It was a story that started in the mid-1990s and took Outlook 97, Outlook 98, Outlook 2000, and Outlook 2002 before we finally got it right in 2003. Through all the strategic twists and turns, organizational changes, and internal competition it had been quite a journey. With 2003, the product finally made it.

A huge amount of software, and Outlook. That is how I remember the release. We so over-achieved on building enterprise software that even marketing, which by and large picked out the end-user features to promote in previous releases, went all in on enterprise to market the release. In the above Evaluation Kit for example in the included “Top 10 Reasons to Upgrade” four of those top reasons had to do with XML, magical XML.

To that end, the release came across as one deeply committed to the new XML technology, our fifth of five priorities when we planned the release. The problem was that we used XML as an implementation detail, not as an end to itself—we had built a platform not a solution, and it was too soon to tout the uses of the platform that had yet to see adoption. The company was overall was so committed, so enamored with XML technology, that it took on a life of its own. It became the destination. The Office marketing team was drafting off the incredible amount of XML evangelism being done by the Server and Tools group, where XML was a key underpinning of the .NET platform. It was still a text file, but we were going to make it seem magical.

If previously Office 2000 focused too much on cost of ownership and deployment to the exclusion of end-user features, then Office 2003 focused too much on a technology enabler or platform technology to the exclusion of doing more with the technology that enterprise customers could use immediately. Looking back at the vision, clearly the big change at the start of the project removed the bulk of the end-user appeal—the vision of Office.NET as an end-user service. The corporate version, “Team and Corporate Productivity” in the vision from May 2001, delivered well but suffered from the complexity and slow deployment of SharePoint as previously discussed.

Large projects are indeed a portfolio and with something as large as the Office System it is essential to build a product such that each constituency has something significant to grab on to, almost selfishly. This is an intentional part of the planning process—we look at the features we are building through the lens of critical stakeholders and make sure everyone has something. I measured our success on delivering on value by constituency.

Enterprises, medium businesses, IT professionals, channel partners, developers, integrators, and more had the full weight of the Office System. It was what they wanted. End-users, typical reviewers, and the individual “power users” (Influential End-Users in our taxonomy) were left behind, though with Outlook and OneNote there was enough, just not an overwhelming amount. The reviews showed that.

Rob Pegoraro a seasoned reviewer for the Washington Post wrote, even with some stinging criticism of some specifics in Outlook, “If e-mail rules your world, Outlook 2003 offers tough competition for pretty much every other program around. . . But the rest of Office 2003 is a yawner. Most people at home can comfortably sleep right through this upgrade cycle.” That’s what most of the reviews were like. Individual reviewers representing typical Office users struggled to make sense of XML, SharePoint, collaboration, and the rest of the massive Office System. The thing is, those individuals just weren’t our business anymore. Enterprise was our business. Those reviews were incredibly strong.

While we were nine months late, we were never out of control or unclear on where we were in the project. We just had a ton of software to get built. Nine months might seem too long, but with the original schedule finishing in late September that really meant a late January launch anyway because launching over holidays isn’t something you can do with enterprise software. So really it was just 6 months, a cup of coffee. The unanticipated long tail at the end of the release gave us more time to plan. My thoughts were wandering to bringing real excitement back to the product while solving the problem of the heft of the Office System.

The launch was a huge worldwide event. I chose to go to China for their launch. Shortly after the launch, I would use a sabbatical to live and work in China for the subsidiary full-time, on the heels of SARS no less. It was an amazing time in China as the markets were opening up, welcoming us, and anxious to expand business connections. The climate of optimism and collaboration was unique.

The launch was difficult, however. For all we had done to execute well, the last-minute change in the product plans away from a consumer service made the release difficult for me. Most people didn’t obsess over or even think about the change, but it lingered for me. Perhaps because I took it as a personal failure in how I managed the planning effort or perhaps, and more likely, I felt it would have been incredibly cool to deliver on the vision of an “online Office”.

I began to think about what would come next for Office and was clear that the product needed an end-user focus. The enterprise momentum had run its course. We were not going to lose for not being enterprise enough. We needed to regain the end-user. I thought to myself about the commitment to do that after Office 2000 and the moderate success we had in development but that did not translate into the way we sold the product. Office 2003 was to remedy that but the start of the project solidified the all enterprise approach. We faced real competition now and the reviews showed we had real problems for the humans that used Office, not just the organizations.

More than anything, the launch was bittersweet not just for me but for many on the team. Just as the product was going to beta test (summer 2002) the team received some devastating news.

Reader note: The following contains an emotional description of the loss of a Microsoft employee.

On Thursday August 22, 2002 (almost exactly one year before we released the product to manufacturing), I received a call on my landline at home from Steve Shaffer (SteveSh), the HR generalist for Office. A call from HR to my home never happened so I knew something was up before I was able to discern the shakiness in his voice.

“I have some terrible news,” he said. “It is Heikki. He’s gone.”

I was not able to process what he was saying and was silent for what I am sure seemed like an eternity. I managed to ask what happened. Details were thin, but there was a fatal car accident in Monroe, Washington, about 20 miles north of the Microsoft campus in a relatively rural area. While trying to pass a car, Heikki’s car collided head-on with a large vehicle. The roads were clear and dry and there were no visibility problems. It took a few weeks, but we learned that there were no drugs or alcohol involved. A young mother of two was also killed in the crash. The children and their father and grandmother survived.

The sudden death of a coworker, a direct report, long-time colleague, and friend was both a personal event and a team event, and a Microsoft event. Heikki was a towering and immense presence on the team, and many people were deeply affected. Microsoft was still a young company and, while we experienced some tragedies, this was the most sudden loss of a senior leader.

Heikki’s family lived in Finland and made their way to the United States as quickly as they could.

We were all in shock. Yet we got through, in part, by thinking about how Heikki would have guided the team. Heikki in his most Finnish stoicism would have insisted we pick ourselves up and stick to the mission at hand. That was Heikki, Olympic-caliber athlete, submariner, sailor, and friend.

We were not ready for the loss. There was little about a technology workplace that prepared anyone for tragedy.

The memorial service was held at the Finnish Lutheran Church in Seattle. With Seattle’s strong ties to the Nordic region, it was fortunate that he had found this community. There was an enlarged photo on display of Heikki enjoying his beloved boat. The church was filled beyond capacity, and we arranged a satellite broadcast for campus and a memorial gathering after the service. Speaking at church, out of admiration for his work family, I shared an expression that meant so much to him and one we often spoke of as a description of the kind of leader he was. “The sign of a great leader is that when the goals are achieved, everyone says things just happened naturally.”

Heikki always said that he took on the mission and “did what needed to get done.”

Back at work, everyone slowly began to move forward. Asking ourselves “What Would Heikki Do?” helped keep status mail going out and project communication across the team.

But there was a void to be filled. Heikki held the most critical communication and coordination role on the entire Office team, and we were at the most critical point for the project to come together. Big teams have succession plans, but they almost always assume some period of adjustment.

No one was expecting to do anything other than finish Office11 on plan. Antoine Leblond (Antoine) agreed to take on program management. In the same announcement, Don Gagne (DonGa), from Outlook and NetDocs, moved to lead Office development. It was what needed to be done and we were so fortunate to have a leadership that could adjust. The team continued the work while mourning the loss of a friend. It was most certainly what Heikki would have wanted.

The RTM milestone, a muted one for many, almost exactly a year later was a reminder of Heikki and all he had contributed in his time with us that was cut so short. Everyone thought of Heikki often, but especially on that RTM day knowing how proud he was of the team every time we shipped.

In remembering Heikki’s spirit as I write this personal journey, I chose to add a page remembering Microsofties that I personally worked with on Tools, with BillG, Office, and Windows who contributed so much and whose memories are indeed blessings.

On to 076. Chasing The Low-End Product [Ch. XI. Betting Big to Fend Off Commoditization]

Each module of Office deserves a shot at being the hero of a release. That’s how a healthy product bundle should move forward, rather than relying on a single anchor. Excel 5.0, Word 97, PowerPoint 2000, Access 2.0 anchored Office Professional. While Outlook was top of mind for IT infrastructure managers, it remained complicated and frustrating for regular end-users. Embarking on a radical redesign of a major product is a career opportunity and also a big bet for a critical business that continued to be half of Microsoft. That would be difficult enough, but nothing is that straightforward. Outlook would still face internal pressures of strategy and alignment that have made building a breakthrough release so difficult previously. Would this be the moment for Outlook to shine?

Back to 073. **DO NOT FORWARD**

Outlook barely worked. Still.

Such was the product-market fit of Outlook that enterprise customers owning the latest in all the Office tools were routinely deploying the newest Outlook while leaving old versions of the core Office apps on the PC.

Five years and three releases from the debut of the product, Outlook remained fragile, bloated, and too difficult to use. It wasn’t as though the team hadn’t executed, releasing Outlook 97, Outlook 98, and Outlook 2000 in the span of just over three years. Rather the team, through little fault of their own at least after Office 97, whipsawed through strategic initiatives. First, they had to split the product into internet and corporate modes. Then they had to merge the product back together while attempting to integrate with Office and the deployment tools of Office 2000. Then they had to charge up the hill of unified storage for the second time, only to cut the feature again at the tail end of the project. As if this wasn’t enough, the past couple of years saw the rise and unveiling of NetDocs which pivoted to a potential Outlook replacement, only to see that vision meet reality.

Marc Andreessen, founder of Netscape, wrote in 2007, years and a generation after the release of Outlook and long after the demise of Netscape, “The Only Thing That Matters”. This short piece codified product-market fit. Essentially, he said that the market pulls a successful product out of the company, “[t]he market needs to be fulfilled and the market will be fulfilled, by the first viable product that comes along.” Outlook was such a product. Coupled with Exchange the market simply needed the combination to exist and to be provided by Microsoft. No matter what, the market was going to make the offering successful. It simply didn’t matter what Microsoft did or did not do, Exchange and Outlook were going to be successful. Once customers saw enterprise-grade email running on Windows Server with a single integrated mail and calendaring solution, all from Microsoft, everything else was set aside: bugs, bad user-interface, poor performance, and missing features. The combination clobbered IBM Lotus Notes. The rest is history.

We (or I) could not overcome the internal forces driving Outlook’s strategy in order to give the team space to focus on building the product it needed to be. It was weird to achieve so much success with such a challenging product. That really throws one off balance. Product people, so to speak, like to think that being a great product is what matters in the market. This belief drove so much of the dialog internally and across teams it is hard to think of any other factors that were ever discussed—the battles were over what makes for a great product. We battled features, architecture, performance, competition, and more. We never really debated the other aspects of the 4 P’s of the marketing mix beyond product: price, place, and promotion. Outlook was the right price, available through the right channel, meeting an articulated need exactly the right way. Oh, and Outlook email and calendaring kind-of-sort-of worked.

Still as a product development organization and leader, I really wanted to make Outlook work. We really wanted a release of Outlook we could be proud of in a product sense. It was a mission.

Standing in the way, more strategy.

The stars were aligning to allow us to focus—Exchange 2000 shipped and was stable, and Windows simply moved on from Outlook Express to aim for a grander and more unified Longhorn plan, the successor to Windows XP in the early stages as of this time. Yet, we found ourselves in the middle of a Hailstorm.

Hailstorm was the code name for a set of services announced shortly after Forum 2000 that built on the announced .NET strategy. Hailstorm would provide email, messaging, notifications, storage, and more, aiming to be the foundation for a broad set of consumer internet services.

That hardly stopped the corporate strategy motions. No sooner had Office XP shipped than the Hailstorm juggernaut took aim at Outlook. Once again, the classic Microsoft platform play entered the picture—a platform needed apps, and apps needed to demonstrate the value of the platform as the first and best adopters. Plus there was that other part of the strategy play, which was that the platform wasn’t even close to complete. Pushing apps to support a new platform sooner accelerated its completion. Such a dynamic worked once, with Excel for Windows 2.0, but Windows was under development for several years before Excel really began to drive the platform with feedback. Plus, Excel had already made GUI work on Macintosh. This approach did not work with OS/2, though maybe IBM shouldered some of that blame. It could be said that Outlook contributed to Exchange success, but that was not a feeling shared across teams who did not see Exchange success as a client as much as success of a server (I disagree). Hailstorm managed to get a mandate for Outlook support, old-school Windows-Excel style.

Outlook was going to get beaten with the strategy stick once again. There was, however, one problem.

The Hailstorm platform was marginally more than memos and specifications, and few understood how it would diverge from Exchange (or Hotmail)—in other words Hailstorm implied supporting a new mail protocol for a client that only understood Exchange and was still not very good at internet standards. There remained an old-school belief that the world would accept a new proprietary mail protocol for internet scale email. Hailstorm was going to build on Hotmail infrastructure, but somehow introduce a new scale platform. Underlying this was the assumption that Outlook was architected to accept plugins supporting any email protocol so long as some small amount of protocol-specific code was written. This classic Microsoft miscalculation on the utility and viability of such architectures caused many cross-group skirmishes and much finger-pointing.

What many never really understood about Microsoft’s email strategy and execution was that Outlook and Exchange were tightly coupled, just as Lotus Notes and later Gmail were for their respective clients and servers. They are essentially one product built by two teams. Even though Outlook could sort of support other mail servers, such as Yahoo or Hotmail, using those was never as good as when using Exchange—many features in Outlook required Exchange, with users mostly shouldering the burden of figuring out which features worked or not. Importantly, vast numbers of features were not expressed in the industry standard email protocols that existed and exist today. Hailstorm tried to build a mail server without a client. Supporting Hailstorm amounted to rewriting Outlook to support whatever it was that Hailstorm decided to implement as email, calendaring, contacts, and more.

What became clear was that the three-year Enterprise Agreement train that the Office11 schedule demanded would not be enough time for Hailstorm to deliver a working, solid, and scalable platform for Outlook. Hailstorm needed more time. Beyond Outlook even, Hailstorm proved to be too much, too soon for the many partners it needed.

The world of consumer companies was starting to warm up to advertising on the internet and saw the internet and software broadly as an extension of customer awareness and acquisition. The digital transformation that came to characterize most industries a decade or more later was far beyond what most companies were considering. Hailstorm concepts such as digital payments, customer identity, and even customer support happening through an array of software tools seemed wildly out of step, and, more importantly, concerning, as most companies were not looking to trust 2000s era Microsoft with those interactions.

In fact, many companies and organizations were so concerned, the thought of Hailstorm generated complaints to regulators resulting in a series of Congressional hearings. While many theories about regulations gumming up Microsoft existed (I disagree that was the case), in practice Hailstorm was an example of the specter of regulatory oversight slowing down or even outright killing product development. Whether Hailstorm would have been a success or not is easily debated. Certainly, all the capabilities described continue to exist.

The primary failure or resistance, however, came from customers and their concerns about owning data and customer relationships. These same potential industry partners eventually found themselves in the web of Facebook, Amazon, Google, and the likes of PayPal.

It was a grand vision that proved to be exactly right—and about 15 years too early and from exactly the wrong company.

By the time the fate of Hailstorm was sealed, we were only through the early stages of Office11. This gave the Outlook team time to regroup and renew the focus on making Outlook work. The team was already deep into the designs and features but cutting support for Hailstorm was a gift of development schedule hours to the two main innovations in Outlook11: rearchitecting the basics of mail delivery and reshaping the user experience.

Like many technologies in Office, from working on long documents in Word to recalculating large Excel spreadsheets instantly, delivering and storing mail was not the most electrifying feature in the product, but getting it right was something that Microsoft accomplished uniquely well. Before the rise of cloud-based email, mail delivery systems meant downloading email to a PC where it could be read and filed away—mail was stored locally on a PC and everyone was responsible for backing up their own email. It is not difficult to see how problematic that might be. Such effort was required primarily because storing and backing up mail on a corporate server was expensive (very expensive and time consuming) especially for a corporation with tens of thousands of employees. As an indication for how routine it was for IT to offload critical business functions to end-users, few considered the distributed costs and risks associated with every end-user at a big corporation acting like their own IT department. During the early days of corporate email, another limitation was connectivity (Wi-Fi was not yet ubiquitous)—employees were often disconnected from the network, especially information workers with laptops. Routine business travel was a constant hunt for hotels with wired networking in rooms or guest network cables at customer and partner offices. Of course airports and airplanes were disconnected experiences. Customers were offline and disconnected quite frequently.

The previous two Office releases attempted to address offline using the idea of a new storage technology, the Local Store, or LIS. Outlook supported a clunky way of working offline (rooted in old-school dial-up support), which the team improved marginally, but it needed much more work to be broadly usable by road warriors. Working online was how Outlook was built. By online, I mean Outlook worked best when it was connected to an uninterrupted, reliable, high-speed network.

As mobile work increased, working offline became much more the norm. This reality is difficult to imagine today, but two decades ago connectivity was the main topic of conversation almost everywhere there was a laptop. Connectivity, or lack thereof, was a major point of contention at sales Mid-Year Reviews (MYR) where country managers genuinely believed Redmond’s product designers had no idea how poor connectivity was in other markets. They were mostly right, and even when we visited would had no problems paying $35 per day for wired connectivity in a business hotel. It would be ten years before Starbucks would offer free Wi-Fi.

Offline was the key to making Outlook vastly more reliable and responsive. Everything that a user experienced in Outlook would operate on data that was already downloaded from a server, which was not how it previously worked. If there was no network connection Outlook was still snappy and responsive and every feature just worked. When a network became available, Outlook seamlessly and silently connected, receiving any new mail, sending all the mail that was drafted while disconnected, and filing away emails in the right folders. A key detail was that an individual’s PC was no longer the only storage for email but was a copy of all the email stored on the server. If a laptop was lost or a person wanted to use two computers, mail remained up-to-date and exactly the same. Outlook was a cache or copy of Exchange, which is why we called this cached mode. Through today’s perspective, this is exactly how the Mail application on an iPhone works when connected to Gmail.

In Outlook 97 through 2002, online mode, when it worked (which was not always), worked incredibly fast, and instantaneously. When the server received new mail, Outlook instantly showed the new mail on a PC. That mail was fetched from the server then displayed, which, if the network was perfect, was snappy. Even a small network hiccup (as the CEO of Boeing experienced on a business jet) and Outlook would hang, and almost never recover gracefully. Email was novel and speed of delivery was a feature, so even then customers remembered how fast it all seemed during demonstrations. The important detail was that the mail still existed in storage only on the mail server. The PC was a rendering of the server. That’s why mail delivery seemed so fast—the mail itself did not travel over the internet, just the visible portion of the screen.

With cached mode, Outlook11 changed how email felt. Suddenly, when new mail arrived on the server, the PC silently fetched it, waiting for a good network connection. It was fast, and not always instant, but predictably mail arrived when it could. When it did, the entire mail message, including attachments, was there. Mail with larger attachments took longer to appear. To big customers impressed by the speed of previous Outlook, Outlook11 felt slow and sluggish. With the rise of Wi-Fi on laptops, Outlook could sense when connectivity was available and, without crashing or hanging, continue to work seamlessly.

We were caught in the middle of crazy conversations with customers who could not get past it feeling slower, even though it was not, and it was more reliable. BillG even complained to me several times about how slow Outlook seemed, wondering if we would fix it as product development progressed. Again, we faced how changing small factors in a running system led customers to believe the changes were bigger and worse. Word introduced background printing and saving, and sure enough the absence of a progress indicator scrolling across the screen led people to believe Word slowed down as well. Cached mode, background save and print, and many more changes that improved Office in an absolute sense convinced customers it was slower, more difficult to use, or different and thus worse. At least that was the case initially.

When I was working on the first release of Visual C++, we were deeply concerned about performance when creating Windows programs, new for most developers, especially compared to the speedy Borland Turbo C++. I added a feature to rapidly display a count of lines of code as they were processed or compiled. Much to my chagrin, my code to draw that ticker technically slowed down the process. In usability tests, however, developers always thought being able to see the line count whiz by was perceived as faster. So, we left the line count in, even though overall processing time was slower.

Perception matters. The performance of an interface can depend on perception of the design as much as stopwatch time, though it isn’t always obvious which matters more.

Outlook 2003 was so critical to Enterprise customers and so complex to make work reliably and correctly, that along with volumes of detailed documentation for system administrators we released a 27 page “Outlook 2003 Performance Guide” detailing all the improvements and capabilities for performance, security, reliability.

Office was no longer in the realm of tech enthusiasts anxious for every change. It became business infrastructure and like the floorplan of a factory or cost centers in accounting changing infrastructure was not done on a whim.

The middle-age of the PC was a period during which each change, obvious or not, was viewed with skepticism. It used to be that Office was difficult to upgrade because of the cost of upgrading disk space and memory, but such expense was viewed with a bit of excitement or even pride of accomplishment. Then upgrading Office became difficult because customers did not want it to change at all. Change was different and different was assumed to be bad, especially for Office, which was not the cool place IT was willing to invest time and effort. The complexities embraced on the server and in the datacenter were driving a movement to maintain status quo on the desktop. Change was actively discouraged when it came to the desktop and Office.

Still the user experience of Outlook remained horrible. It was Byzantine and bloated and had the reviews to prove it. Even today, searching for “Byzantine Microsoft Outlook” yields almost one million hits. Outlook11 aimed to recraft Outlook based on what we had learned over four releases and four years since Outlook 97. We were going to take the time to make it right so it could properly share the stage with Word, Excel, and PowerPoint. Each app in Office deserved to have a release where it stood out and was recognized for being great.

Jensen Harris (JensenH) was asked to lead program management for the first broad, and much-needed, reshaping of the Outlook user experience. Hardly the typical computer science hire, Jensen joined Outlook from college where he majored in music. Previously, Jensen attended Interlochen, the prestigious performing arts school, with fellow classmate Jewel. When not composing for all the instruments in a piece or performing, Jensen was programming. Jensen was among the best of a new generation of program managers on the team and he seemed to know as much about how Outlook was coded as even the most senior developers. These skills were put to the test in sweeping changes to Outlook11—a process that, if successful, could prepare Jensen and the Office team for even bigger changes in the future.

While we made many small or incremental changes in user-interface in each release of Office, Outlook11 would be the biggest changes to any one product to date. We would also make these changes in the context of the change-resistant enterprise customer base, especially the email administrators in IT that saw Outlook as a necessary evil supporting their beloved Exchange servers.

To say the changes were sweeping and high-risk only makes sense in the context of the time. First, many small features of Outlook that piled on over the previous years were rationalized, sanitized, streamlined, and in general made better and more accessible. Second, and more importantly, they came at a time when email was the most critical and mainstream tool being added to the workplace. Using email and Outlook often meant taking a training course, buying a book, or simply struggling to master a few scenarios and little else. Email was still in an expansion stage, leaving ample opportunity to make it better for new users not just change the user experience for existing users.

That context is important because so many of the paradigms we think of in email today were pioneered or refined in Outlook11: message flags, preview pane, switching between calendars, contacts, mail, message thread view, junk mail filtering, integration with instant messaging, and much more.

The most acute pain point in using email, any email not just Outlook, was unsolicited mail, junk mail, or SPAM. The rapid rise of email brought with it an exponential rise in the morning ritual of deleting unwanted mail offering everything from get rich quick schemes to fast college degrees, and even offensive sexually oriented offers. Everyone felt invaded by the onslaught. Unfortunately for Microsoft, the rise of Hotmail with hundreds of millions of accounts was both a source of junk mail and the target of junk mail senders. The junk mail problem on Hotmail was so bad that @hotmail.com addresses became synonymous with spam. It wasn’t just an inconvenience, but email was losing its utility for businesses to communicate with customers as primitive junk mail technology too aggressively filtered out legitimate mail.

In one of BillG’s most successful (and perhaps last) great cross-company technology initiatives, a working group from Microsoft Research, Exchange Server, and Outlook convened over many months with Bill insisting we collectively make improvements in junk mail filtering.

The work from Microsoft Research was one of the early applications of the same technology used in the Office Assistant, Bayesian probability, advancing beyond typical keyword filtering that falsely flagged messages. Junk mail senders adopted their language rapidly to get around filters, substituting alternate spellings for words such as S3X instead of SEX or S1NGLE instead of SINGLE. Exchange server pioneered some of the first cross-industry efforts at verifying legitimate senders. Outlook took advantage of MSR technology used in Hotmail to apply it to the desktop application so it could work for any email service customers used. The Outlook features were so well received that almost every review mentioned them, though they also mentioned Hotmail as the biggest junk mail headache.

So successful was the feature in the previously released Outlook Express that I found myself along with several lawyers in a San Jose courtroom defending the right of Outlook to even have junk mail filtering. A popular electronic greeting card company (yes, web sites that created a JPEG birthday card were a big thing for a short time) sued Microsoft for falsely flagging some of their free greeting cards as junk mail. I spent several weeks creating new mail accounts and collecting the junk mail that would routinely arrive even before using the account for legitimate email to show the judge as we entered arbitration. The lawyers made a great case for the right to protect consumers, but in the post-DOJ era the David v. Goliath environment was too difficult. We settled the case for an astonishing amount of money. The good news is that over time it paved the way for the industry to legitimately offer junk mail protection, if for no other reason than everyone with email recognized the junk mail problem.

In applications, the way to signify a major update is to change the user interface substantially. Doing so signals to the world how big the change is. BradWe, our product design leader, referred to this as the ten-foot test. Looking across at a PC screen ten feet away, could a typical customer see the difference in the product. This is surprisingly difficult as most people see typical screens as an array of meaningless graphics. On the other hand, when it comes to using a product up close even the smallest changes elicit massive feedback. The rise of Outlook in a few short years created a good deal of muscle memory, even though the product was awkward and complex. Most customers were not just learning Outlook but learning email, to many Outlook was email. Changing Outlook was changing email, and email had rapidly risen to be a core part of work. No one likes their daily workflow changed for no good reason. These conflicting goals set the bar high for JensenH and team to deliver on a vastly improved, and iconic user experience for Outlook.

The team answered this challenge with an entirely new layout for the main Outlook window, one that would pass the ten-foot test. The screen was divided vertically into three columns: folders, mail messages, and a single message open to read. It was a clean and logical design that was . . . broadly panned during beta testing. The visceral reaction to seeing a narrow column of the inbox subject lines and that the view was showing each message with two rows led beta testers to think less email was shown on the screen, and less email meant less productivity. Similarly, the relatively narrow reading view of the message led to a conclusion that less text of a message was shown on the screen. These observations were hotly debated on the newsgroups and the subject of many outcries from testers.

Yet, these observations were not true, and easily demonstrated. Jensen and team were hyper-analytical in the design and measured everything about the interface—in particular, the design showed a much higher level of information density on the screen, while apparently making people feel like less was on the screen, which would make it easier to read and less tiring. Brilliant. Over a few weeks the outcries were settled with volumes of screenshots and posts to the newsgroups, leaving a design in place that is routinely used by all email clients today. This was another example of visceral perception of user experience versus actual experience.

Outlook users tended to be either pilers or filers when it came to managing email. Pilers, like the BillG I knew, let their inbox grow, seemingly without bound. Inbox was where mail was read and also stored. When a piler wanted to find a message, they used Outlook search, which was slow and deeply unsatisfying, or more likely they sorted thousands of messages by sender or date or subject, which was fast. Filers created elaborate hierarchies of storage folders and messages. Advanced filers created email rules, moving messages to folders even before they read them. One reporter I knew maintained a folder for every company, and a folder within that for each contact at that company. He worked with all the folders visible and the whole hierarchy expanded, watching for unread messages.

There’s a challenge when customer knowledge of the past makes improving for the new, faster-growing base of customers super difficult. The customers we heard from in early testing were those with knowledge and time to engage. They raised issues and engaged in debates that others happily let product design work out for them.

We came to learn that many of the tech elites were avid filers, making use of email rules. When a customer goes through the effort to create a rule, mail messages are automatically placed in a desired folder as they arrive in the inbox based on criteria such as the sender’s name or company name, or perhaps keywords in the subject line. The general concept of advanced tech thinkers embracing hierarchy was consistent with how people made use of folders of files on their PC. Typical users often had desktops filled with files including what they were actively working on, whereas techie users tended to have elaborate folder hierarchies and store documents in the right place from the start.

Studying how customers used Outlook, rather than listening to how they thought they used Outlook, revealed a spectrum for how the onslaught of email was being handled. Customers tended to self-report how they wished to be perceived rather than how they used a product, something we learned over the years with the instrumented versions. As an example, customers routinely self-reported sending far more mail than they actually sent or would rarely get the number of messages in the inbox approximately correct. BillG, the piler, used to wax poetically about his love of filers as though he was one primarily due to his fondness for hierarchical lists, but also to make a point about the future of storage that would support hierarchy. He also exaggerated the amount of mail he sent and received.

Business books are filled with stories and strategies about learning from customers, getting feedback, and doing what customers want. In technology products, and in Office in particular, in the more than a decade I worked on the product, much of that feedback would have frozen our product where it was and prevented us from moving forward. Staying true to learning the reality of what customers experience was such a key lesson reinforced with Outlook11. The lesson was one for the ages and one that impacts every technology product, including, as I would learn, Windows.

Showing Outlook11 to the press and reviewers was not just a demo, but a story. We incorporated the data about how customers used the product in reality and showed the analytics behind the product. It sounds obvious, but it just wasn’t something done in the industry because prior to the internet no one really knew. We had surveys and focus groups, and the early data about quality, but with Outlook and Exchange we had real data about real people doing real work. This story-telling approach dramatically changed not only how we designed and communicated product changes, but our willingness to take risk to make bigger changes that met customer needs.

Outlook 2003 had its own “Reviewer’s Guide” that was provided to the press and Enterprise customers. It was 35 pages!

As the success of Office continued, we were fast approaching the point where most everyone that wanted Office owned it, legally or pirated. PC sales in 2002 (post dot-com bubble) were nearly 130 million units, growing at an anemic rate of 3 percent or less. There was a fear that we had peaked and that conservatism in making changes should have ruled how we thought of the product. Some thought we should have been focused on listening to customers and not rocking the boat.

Except we were listening to customers.

There’s a famous saying falsely attributed to Henry Ford suggesting that when potential customers of the Model T car were asked what they wanted, they said a faster horse, not a car. No customers wanted a graphical interface with a mouse, or an integrated suite of productivity tools, or even for those tools to evolve with the changing nature of information and the internet.

Finding a balance between listening to customers, while also moving forward with technology, is the most difficult challenge any successful technology company faces. Microsoft was no exception.

On to 075. Scaling and Transitions

As readers of this chapter have seen, the theme of Office11 continues to be enterprise, though now it is turned up to 11 so to speak. Despite my concerns about end-users and reviewers, the unstoppable force at Microsoft remained enterprise customers and meeting their needs or the needs of our growing sales force serving them—whether those needs were technology, positioning, or strategy, as expressed by customers or the field sales teams. A key attribute of enterprise software strategy is connecting the dots and making sure one part of the full enterprise stack uses (or leverages) another part. A cynical view of this is that it encourages a form of lock-in relative to the Microsoft stack of software. A practical view is that customers appreciate this interconnectedness because they are buying everything in a bundle and broader usage of what is already owned offers a high return on that investment. A charitable view of such a strategy is how it makes for more elegant implementations where the various parts simply work together. Perhaps the story of Windows Rights Management (also called Information Rights Management within Office) generated a seemingly unachievable level of complexity while simultaneously facing an unrelenting technical buzzsaw of customer feedback.

This lesson from this section is not a one-off. Instead it is prototypical of the era but also what happens when a product pivots to enterprise customers and the enterprise relationship dynamic defines how products are built. It is a tale of caution.

Back to 072. Notes on Tablet PC Innovation

“I’d like to present to the witness Exhibit 6508, Bates number 0017811. Mr. Sinofsky, do you recognize this email that lists you as the sender?”

To anyone involved in modern litigation, especially being deposed, there’s a sinking feeling that comes with being presented an old email. A similar feeling arises when receiving a call from a reporter starting with, “I was just anonymously forwarded an email about . . .”

Email became ubiquitous across the corporate world by the early 2000s. With the rise of companies moving ever faster came “business at the speed of thought” (that was the name of Bill Gates’s second book from 1999) or “flattening organizational hierarchy,” to name two of the many touted benefits of email. In the early days, while senior managers at non-tech companies were still having email printed out for them and assistants transcribing email replies, not much thought was given to the permanence of email or the instant impact of an employee innocently (or not) forwarding email outside the company.

Every company that deployed email and embraced an email culture eventually wound up with a company policy on the use of email, likely explaining the ramifications if one were to be less than scrupulous in his or her use of email.

Born out of this were automatic disclaimers placed at the bottom of email, “THIS INFORMATION IS CONFIDENTIAL,” or my favorite, simply writing in red letters across the top of a message (perhaps the first use of rich email formatting) “CONFIDENTIAL.” We should not forget putting “**DO NOT FORWARD**” before the subject line of the email. We all knew that those emails were the important ones, and these warnings weren’t even worth the bytes they took up—copy/paste and printers still worked. Just in case there was a button on every keyboard since the first PC “Print Screen”.

Outlook featured commands that implied “Confidential” and “Do Not Forward,” though these did little more than offer a fancy version of red text and, worse, were invisible to recipients reading the mail on systems other than Outlook.

Maintaining the corporate confidentiality of email became the Achilles heel of the platform, except that email found such incredible product-market fit that there was no putting the toothpaste back in the tube. Customers wanted a solution that protected email misuse, or more clearly made Outlook enforce a company email policy or intent of the sender.

Over the previous several releases of Office, we steadily improved the ability to encrypt Office documents. Office always had the ability to add a password to documents, and for years a top call to customers calling PSS was trying to retrieve a lost password (Microsoft provided no help, but a search on the internet quickly led to a variety of tools that worked with trivial effort up until about Office 97, and incidentally those search results were a common way to spread malware). We eventually added true encryption that made it increasingly difficult to read a document that was not yours to read. This level of security eventually became minimal as the ability to break encryption techniques had steadily improved.

A peak effort and an early test of our platform capabilities for encryption was working to win approval for Outlook and Exchange to be used in the Defense Messaging System in the Department of Defense in the United States. Implementing the required encryption was useful only to the Defense Department but we eventually added it anyway. That was not before the head of North American sales, Orlando Ayala (OrlandoA) made his case to me by standing on top of a table in the briefing center begging for an update to support the DoD. I was terrified. The customers were impressed. We did the work.

The core of implementing encryption was an ongoing collaboration between Windows and Office, as well as Microsoft Research. Encryption was not exactly one single thing or feature, but a complex platform that required servers, user identity, and a lot of sophisticated math. It was exactly the kind of infrastructure that enterprise IT was gobbling up in the early 2000s. The old days of encryption were rapidly being supplanted by the need to encrypt information that flowed across the public internet and used public internet infrastructure. It was no longer as simple as a closed network with known proprietary endpoints.

Protecting files (and messages) with encryption was not without controversy, and without exaggeration for some technologists it was a line in the sand—crossing it put one squarely in the camp of the man. Encryption often collided head-on with the libertarian roots of the software field. Encryption was something of a third rail in the counter-culture elements of software.

The rise of the internet for online commerce created a brief moment where software vendors got caught up in the intricacies of import/export laws related to military products, specifically munitions. For a few years, the basic encryption algorithms—the results of widely-published academic research—were classified as munitions by US law and thus restricted for export. The hardcore technology advocates created a t-shirt featuring the code that implemented encryption with the implied threat that wearing such a shirt through a border crossing might subject the individual to law enforcement action of the highest order. The result was a headache for software vendors who maintained a secure version of products for the US market and a markedly less secure version for “export”. President Clinton signed an executive order ending this awkward situation and at least one type of encryption flourished.

Broader awareness of encryption came about because of the iPod, surprisingly, because of how Apple chose to protect digital music downloads from being copied or pirated. The music industry embraced digital rights as a way of protecting the world from another Napster, the online music service that institutionalized either digital distribution of music or mass-scale theft of music depending on which side one was on. Essentially, using digital rights management (DRM), Apple’s iTunes service ensured that the person who purchased a song was the only person who could listen to it and could only do so on devices authorized by Apple’s iTunes.

Such usage restrictions had shades of authoritarianism harkening back to the early days of commercial software. In the first years of MS-DOS, software vendors routinely encrypted software in such a way that only the licensed user could install it on a PC using serial numbers that would unlock the floppy disk and permanently assign it to a given user. Vendors also made it difficult to impossible to make copies of the software disks forcing buyers to be extra careful with their $500 purchases. So annoying was this to even legitimate buyers, that I spent several weeks one summer internship writing a low-level assembly language program to make copies of Lotus 1-2-3 disks for a huge defense contractor. Historically, Bill Gates was at least on the side of the honor system by and large though he believed strongly in active enforcement of legal ownership of software.

The industry collectively backed off from rights enforcement during the high-growth years, particularly at the urging of upstarts such as Borland, who used the absence of anti-piracy measures as a selling point. Then, as piracy of Office and Windows increased, so too did the use of serial numbers and activation codes, which were then labeled DRM by some, as if to further inflame consumers seeking legitimate use of their license. Thus, any feature using any software use restrictions was going to enter the maelstrom of tech enthusiast ire. BillG was particularly unphased by the pushback, widespread negative news coverage, and relentless hostility online in just about every language of the world taking place just after resolution of the antitrust saga.

For many in the tech community DRM in music was the devil’s technology. DRM prevented “fair use” of music and video all in the name of profit. The music and visual arts communities did not see it that way. Anything that looked like any combination of encryption or restricted use of digital information was labeled DRM. Anything called DRM came under intense scrutiny with the potential to backfire as features capitulating to authoritarian forces.

Nevertheless, enterprise customers were quite enthusiastic about a “Do Not Forward” button that worked. As one can imagine, in Microsoft’s top-down selling motion, it was the C-suite executives most interested in protecting the rights of their own email and documents. Even though we knew the idea of protecting email from being forwarded had all the makings of being labeled DRM and building the feature would utilize previously militarized technology, the allure of solving such a clearly articulated need was enough to overcome such resistance.

During the early days of building out the Microsoft enterprise infrastructure stack, customers were perhaps unknowingly open to enormous amounts of complexity to implement new features. Our sales force actively embraced complexity if it meant opportunities to link products together in a cross-selling motion, especially across Windows Server and Office. Office11 Information Rights Management (IRM) did not disappoint. We called it IRM as if to distinguish it from DRM, kind of. We knew we were walking straight into a messy feature. In an early nod to the complexity of the feature, the Windows infrastructure used by IRM was called the Windows Rights Management Service (RMS), thus implementing our DRM-like features called IRM used RMS (phew!).

Customers were already annoyed that they could lose a password to a document and Microsoft could not, or perhaps they thought would not, help them. IRM, in the eyes of detractors, implied that Microsoft held the keys, literally, to documents and somehow positioned themselves to become gatekeepers of email and documents. Or perhaps, as some customers thought, Microsoft did not hold the keys to documents and email and somehow a company’s own information would be subject to some sort of super-password that even they might not be able to unlock. What if there was a bug rendering the company information inaccessible? The questions were endless.

There was something inherently untrustworthy about the potential of using a content protection feature that could render the content unreadable. This was not theoretical. Many were already experiencing owning a library of rights-managed music, only to find it inaccessible when a company went out of business. Stories of lost music players and accounts disconnected from the rights were endlessly populating support sites. Whether these cases were real or not, they all contributed to a distrust of rights management. At this point in the company’s history, Microsoft was not always viewed with the most latitude in terms of doing the right thing for customers.

IRM proved to be one of the most complex features we ever shipped, perhaps overly complex, but in many ways it was symbolic of the overall complexity we were delivering to customers, whether it was IRM, SharePoint, or even the base infrastructure of Windows Server.

During vision planning for the release the feature was proposed so an Office shared team was created to tackle the implementation of IRM for Office11—the team aimed to implement the feature across the suite of products, not simply a one-off for just email. They had a bold vision for a future where companies could have much more control over their corporate information.

Lauren Antonoff (LaurenA) led program management, and with her prior experience on the Windows platform side she was great at navigating the extensive collaborations across the company to make this feature possible. Mark Walker (MarkWal), a veteran of several releases of Word as well as SharePoint and one of the most consistently smart and broad-thinking engineering managers, led development. Brian Wiese (BWiese) led testing, perhaps the most complex interoperability test responsibility we had created to date.

From the start, even when sketching out the original feature, IRM was a big feature. All we were aiming for was that “Do Not Forward” button, but to the surprise of many we overachieved.

IRM had to handle a plethora of edge cases, as testers called them. What if the users lost their PC? What if they wanted to read a message or documents on a rental PC in a hotel? What if they wanted to use IRM with a trusted partner who was on a different email system? What about access on a BlackBerry? What about wanting to open a file on an old version of Office? What if in the future someone needed to open a file on some not-yet-existing Office15? Then lawyers started asking if documents were part of legal discovery orders? How would screen readers used by the blind work? Or what if an employee was terminated? These what ifs went on and on. Every time I stopped by LaurenA’s office I learned about another case they were working on.

The strategic changes at the start of Office.NET seemed to be the kind that might reduce the complexity of this feature, because we no longer needed to worry about a parallel implementation of enterprise and outside the firewall, as we generally called it. The feature, however, needed to work outside the firewall if, for example, executives were to be able to read protected information on the road. The team took on the mission. We ended up doing much of the same work as we did for a hosted service but in bits and pieces, enabling IRM to work for customers using Hotmail in a browser, as long as the customer used the latest version of Internet Explorer.

As each development milestone progressed, M1, M2, M3 . . . the complexity continued to rise. IRM added code to Office, SharePoint, and Internet Explorer and required additions to Windows Server and to Active Directory. Administrators needed to learn to manage and distribute encryption keys, something that was making its way into enterprise infrastructure.

Along the way we experienced surprises that questioned the notion of Microsoft implementing IRM at all. Historically, many third parties—companies building products that relied on Office files or email—relied on being able to change documents or read them without launching the app by directly modifying files. Screen readers for the blind were one such example. Many document management systems relied on reading the contents of Word documents. Financial systems routinely read the contents of spreadsheets pulling out specific cells or data. Such behavior should have been impossible because the files were encrypted. Ultimately, the team designed capabilities to enable these “hooks” but at the expense of even more complexity. The depth of the feature was astounding.

The operational flowcharts created by the IRM team were legendary. The team rose to the occasion, producing untold volumes of written materials for corporate admins, partnering with all the teams at Microsoft, and coordinating the documentation across the writing teams that made this feature possible. Setting up IRM remained a monumental task.

IRM’s pièce de résistance was the addition of administrator-created rights management policy templates. It wasn’t enough that a message could be marked “Do Not Forward” or a document could only be opened by a fixed set of people. Office11 enabled IT to create new document policies that expired (like Snapchat, but 15 years earlier), or for documents to be forwardable but only within a company. Several combinations of permissions could be set via policy.

The keepers of secrets in enterprises, especially those sending mail on behalf of big bosses, were super happy. IRM was an enormous hit in the Executive Briefing Center. Emails on corporate reorgs or M&A PowerPoint decks could finally be shared worry-free.

Then came the debate to end all debates. In an early customer briefing about Office11 the details of IRM were discussed. With all the work going on to secure Windows XP SP2, marketing and the field thought it prudent to refer to IRM as a security feature. The problem is security features imply a promise of robustness in an absolute sense. Either a document or email message was secure, that is it could not be read or forwarded, or it was not. We had those nasty details to contend with such as the Print Screen key (or the more cryptic Prt Scr key on laptops). What if someone was reading a document and took a screen shot? That was a “security bug” according to the customer. The field sales reps were frustrated. The documents and emails were more secure because they were encrypted, but they were not absolutely secure from all forms of attack. Nothing is. After a scramble, work was done to disable screen capture involving the Windows team and marketing repositioned the feature away from security, we thought we were set. At least we thought so.

Once Office11 was available to Microsoft globally in pre-release, IRM quickly became an oft-used feature. Routinely the most interesting mails were rights protected. Re-org announcements, strategy changes, schedule shifts, anything to do with sales numbers, staffing adjustments, and more were reflexively rights protected. Employees started rights protecting snarky threads commenting on other rights protected threads. Along the way, many learned an inescapable workaround for capturing the text of a protected message. Using another new Windows feature that allowed one to remotely log on to another PC, all one needed was a second PC to remote into your primary PC. After connecting, just read the message normally on the remote PC while capturing the screen on the second PC where the session was started. This was not something we could address. Most people didn’t have a second PC so we felt reasonable about this and if administrators wanted, they could disable this capability, primarily used for servers anyway.

The feature, however, came just as mobile phones were gaining cameras and suddenly photos of screens were passed around with the latest news about a reorg or product schedule slip. Mobile phones would prove to be a huge challenge, especially non-Microsoft phones. Microsoft implemented support for protected content on Windows Mobile in a reasonably timely manner and released it to an anxious Microsoft workforce. Those of us still on Blackberry or Treo devices, however, would have no idea what juicy secrets were sitting in a protected message we received while at the movies or out to dinner. We’d rush home to check out the message on a full PC as soon as we could. The proliferation of mobile devices only amplified the complexity of rolling out IRM to an organization. Almost fifteen years later, I joked with the founder of Accompli, a company that Microsoft acquired in 2014 and rebranded as the mobile Outlook client for iOS and Android, that among his first Microsoft duties would be to add IRM support to his product. A request that quickly materialized.

IRM could in no way protect anyone from discovery and litigation. Administrators had all the requisite tools to comply with courts. It was the start of a new era of information control. The era at least in Microsoft, of mail that frustratingly could not be forwarded. A feature of IRM was not just that the mail could not be forwarded but even the attached documents in mail received the same protections as the mail message. Documents could be saved in SharePoint where entire document libraries could be protected against unauthorized sharing. In fact, long memos could be protected so they could not even be printed. Those email attachments had to be Office documents, however, as people quickly learned. Photos or PDF files that were attached to protected messages did not receive those same restrictions.

Office IRM gained many fans inside Microsoft especially with the sales team who simply loved the way it connected all the major company initiatives of Office, Windows, SharePoint, and Windows Server.

Customer usage, however, was far lower than we hoped. This was perhaps in part because most end-users didn’t want to invest the time and effort into dealing with the restrictions and no doubt IT departments could not absorb the complexity to deploy and manage the feature. It was likely that the only team that was able to run much of Microsoft’s mid-2000s era infrastructure correctly, securely, and reliably existed in the 425 area code and carried blue Microsoft badges. Setting up, deploying, and training end-users was beyond the reach of most customers who were struggling to keep PCs functioning and patched with all the latest updates.

Setting up and deploying IRM in a company was an enormous undertaking. Once Microsoft successfully deployed IRM, a Showcase IT whitepaper detailing how MSIT implemented the feature stretched over 40 pages. For an average company to deploy the feature, they would need to invest in hardware and skills training across the Microsoft product line. On top of the typical deployment for desktops with Office and Exchange email, a company needed the Windows RMS server (or several), a Windows Server running Microsoft SQL Server, an SSL Certificate server (the encryption infrastructure), as well as to configure numerous externally facing web addresses for access outside the company network. While these products could be covered by an extensive Enterprise Agreement, typically adding these components was an upsell.

We were creating features that were, for all practical purposes, impossible to consume. More than anything, this defined the era we were enabling. The problem was not that we created these features, but that customers and the sales force were embracing them—not so much deploying the features but embracing the underlying strategy of the features. Complexity was empowerment for the enterprise IT leaders, so it seemed. While there was continued backlash about bloat on the desktop and bloat within Office, the newness of servers and server infrastructure made features that relied on servers seem cool, and they were given a free pass regardless of complexity. The routineness with which IT succumbed to “standing up another server” was incredible. The enterprise account managers did not hesitate to push features that required more infrastructure—doing so was showing more value to customers and good for Microsoft’s bottom line.

IRM was an incredible collaboration across the company. Development teams including Office, Windows, Server, Research, and more contributed to building the feature, while sales, support, and Consulting contributed to selling and working to deploy the feature. It was an amazing sense of pride of execution capability, that I wish was met with as much enthusiasm to deploy and use the feature as routinely as we would have hoped. Today’s Microsoft 365 and Azure made the feature somewhat more accessible and perhaps more usable, though the decisions of an architecture from decades ago still linger in an underlying complexity that was probably good at the time in theory but not good relative to first principles.

Somehow, we had gone from simplicity as the guiding light to complexity as a sought-after competitive advantage. The story of IRM is both one of successful implementation and a cautionary tale of too much focus on customers to the exclusion of what is usable and desirable.

The world turned upside down, or sideways, or something.

On to 074. Outlook Pride, Finally

Few products have captured as much attention as Microsoft’s Tablet PC (except perhaps Xbox, which coincidently launched the same year). The company’s history working to deliver the form factor goes back to the earliest days of Windows. BillG’s intense focus on handwriting recognition led to one of the first extensions to Windows, Windows for Pen Computing (1992), and a bitter lawsuit with then perceived leader, GO Corp. Subsequently, handwriting recognition was among the very first groups chartered in the new Microsoft Research organization. The small Windows-derived handheld devices, PocketPC, were pen-centric. Then finally in the early 2000s Microsoft began in earnest (meaning in Windows proper) the technology for pen and handwriting that made it into a special edition of Windows XP for Tablet PC and a new type of computer. This arc took place a decade before the iPad was released (purists do love to point out the Newton from Apple came and went in the 1990s). Famously, Steve Jobs tells the story of the iPhone as one that began with a tablet form factor, but that was abandoned in favor of the phone. With such a long story, one could easily write a book on just the evolution of the tablet and the Wikipedia history page represents the industry search for a paradigm-defining product. In this section, we’ll start with the launch of the modern Tablet PC from Microsoft and detail the much more difficult (in my view) challenges of building software for the form factor in the context of Windows.

Back to 071. Resolving NetDocs v. Office

I should have been prepared for what transpired following the unveiling of our Tablet PC. I was not.

The line to enter Bill Gates’s keynote at the November 2001 COMDEX snaked through the hotel and required metal detectors and body searches following the events of September 11, 2001. Themed Digital Decade 2001-2010, it was set to be a highlight of the week—discussing bringing digital innovations across industries and emphasizing increases in productivity, richness of business infrastructure, and significant changes in home entertainment.

Previously at Fall COMDEX 2000, Microsoft unveiled the Tablet PC, showing a prototype tablet created by Microsoft, highlighting BillG’s personal favorites of pen-based handwriting capabilities and online document reading. At the time printing was still the standard for sharing business information. The prototype was how we hoped to convince OEMs to build similar PCs.

A recurring theme for the Windows business was to use big tradeshows to demonstrate exciting new PCs across the PC ecosystem. JeffR joined BillG on stage to show off multiple innovative PCs running the new Windows XP Tablet OS, many of which were to be available later in 2002 with the tablet-capable version of Windows XP. As with all things Windows, the strength in bringing the product to market was emphasized by a broad array of hardware of different sizes, shapes, and price points. Building off the first party prototype demonstrated the previous year, the keynote brought the full strength of the PC ecosystem to this new form factor with support in new variant of Windows XP.

Alan Kay, a pioneer in visualizing and prototyping the concept of a tablet while at Xerox PARC, conceived of the DynaBook, perhaps the original tablet. The DynaBook was envisioned as a “personal and portable information manipulator" described in his amazing paper, A Personal Computer for Children of All Ages (1972). Of the launch of Microsoft’s Tablet PC in 2001, he told Newsweek’s Steven Levy, "Microsoft's Tablet PC [is] the first Dynabook-like computer good enough to criticize." In PARC-speak, that was a high form of praise, not a back-handed compliment.

The quest for a PC tablet was not new and perhaps dates back in our memories to Captain Kirk on the bridge of the starship Enterprise with his tablet and pen. In the 1980s and 90s the PC industry was buzzing with innovative large screen computers based on tablets and pens from the likes of IBM, GRiD, Momenta, NCR, Compaq, and Asian companies like NEC, Samsung, and Toshiba. Small screen computers arrived (and departed) as well. Palm had a breakthrough with its Pilot, while Apple failed with its Newton. Windows CE devices were blessed with a stylus as well.

What Microsoft envisioned to do differently was to build a new class of computer. The Tablet PC would be a full notebook sized computer, but better. It was a notebook PC in power with the convenience of an actual notebook and pen. It was also fully capable of running the latest Windows and Windows software. This was not only the core of the Tablet PC strategy but the core of everything Microsoft was doing with the “scalable Windows architecture”, or “one Windows, with many implementations”.

Microsoft’s new Tablet PC group, led by Alex Loeb (AlexLoeb), reported to JeffR’s division (rather than Windows) to streamline delivery of a killer productivity solution. As the original manager of the pen computing effort a decade or more earlier, JeffR had a longtime passion for pen input (Some personal trivia is that my first trade show booth duty was showing off C++ support for Windows 3.1 for Pen Computing 1.0 at Spring COMDEX 1992). Jeff was an early fan of PocketPC devices, never missing a chance to use the stylus to jot down notes or show off the latest financials in Pocket Excel.

While the connection to information work was clear, this organization structure was a tacit admission that the Tablet PC might require more end-to-end design and implementation than a typical new Windows PC. To build a complete experience required integrating product design and engineering efforts across Windows, Office, research groups where the ink and handwriting technology was being developed, as well as hardware engineering for digitizers and working with PC makers. Coordinating marketing and partnering with OEMs introduced another aspect of the end-to-end effort.

Technology for digital ink progressed significantly, primarily as a result of the increasing focus on screens and digitizers—the technology that picks up a signal of some form from a pen and converts it to a series of datapoints representing what is drawn on the screen. Flat panel displays for notebooks were progressing quickly. The Tablet PC was timed well to capitalize on these innovations as display and touch/ink sensor-equipped panels proved to be the limiting factor for building even a marginally acceptable experience.

From its earliest days, Microsoft Research was working hard to make handwriting recognition a reality. Handwriting recognition had long been one of the fundamental linguistic technologies (along with language translation and bi-directional speech) that were always 5 years away (since the mid-1950s). Our state-of-the-art approach was fascinating in hindsight. Improving digitizers were able to capture many more points (coordinates) as the pen moved across the screen, even when moved quickly. These points were used to connect dots, which could then be smoothed out to look like a continuous line of ink. Meanwhile, the starting point, ending point, direction, and other data were used to guess the letter being drawn. Recognition was obtained by comparing the series of captured points along with direction and speed of the pen to a library of pre-collected samples. This was done letter by letter, building up recognition based on pairs or triads of letters commonly occurring together. Then when a collection of letters was detected, something like spellcheck was used to recognize an entire word. It was rocket science, the kind of rocket science BillG loved because no one could possibly duplicate the effort to develop the technology. The researchers managed to attain some almost useful level of accuracy, perhaps 90 to 95 percent, enabling ink to be searched as though it were plain text or to be selected and pasted into Word as plain text. This physics-based approach was used for decades with slow progress, but state of the art in 2001.

Fast-forward 10 years and handwriting recognition was upended by an ingenious use of machine-learning image recognition advanced by research at AT&T Bell Labs in 1989 led by Yann LeCun. In a heartbeat 50-odd years of attempts turned into something that worked 99 percent (or more) of the time and was vastly easier to implement. The advances in machine learning represent the most fundamental improvement in computer science I’ve seen in my career.

A most exciting step with a new Windows release are new form factors. An even more (super) exciting hardware innovation was dubbed the “convertible,” which was a laptop that looked at first glance like a normal clamshell notebook, though smaller and thinner than most available at the time. Through a presto-change-o flip, the screen rotated and covered the keyboard to become a full-fledged tablet that resembled what Captain Kirk used on Star Trek (likely in size and weight too as the 8.5x11x0.8” device weighed 4lbs/1.8kg). In tablet converted mode, using a pen became the primary way of interacting, instead of a keyboard and mouse or integrated pointer. Techies have always loved and continue to love transformer PCs—presto-change-o is always a crowd pleaser.

The convertible form factor was particularly attractive to typical Office customers who craved mobility and could opt to use a keyboard and mouse when required for “full productivity”. This contrasts with a slate form factor, which (like an iPad today) is a screen-only computer, requiring a pen for all input and manipulation. Perhaps surprising, the idea of using a touch interface was not pondered primarily because the existing screen technology did not work with a finger, nor did handwriting for input. As we will see, even when rumors of Apple building a tablet surfaced (a pun!) the biggest question on BillG’s mind was how they acquired handwriting technology, or did they build their own solution which was bound to be inferior.

The dual personality modality was a significant source of tension across JeffR’s Information Worker division—does the design assume a convertible in which case Office was fine as it was, or do you design for a pen user interface? How productive did it need to be relative to how frequently the pen would be used. Every demo of a Tablet PC created questions (or concerns) about whether Office was participating in this future. There was no using Office without a keyboard and a mouse. Full stop. Microsoft’s DNA was such that a new OS required apps to push the OS to succeed, and the lack of Office was readily apparent. Worse, Office did not commit to “full support,” whatever that might imply.

Program managers across Tablet PC, Office, and Office applications spent months of meetings, prototypes, and discussions trying to understand each other. What did full support look like? In the best case, how should Excel work with a pen? Where and how would one input numbers and formulae? Did the Office user-interface work well when navigated with a pen instead of a mouse? We were in a circular platform-apps debate—the platform said it needed input from apps to finish the platform, while apps said it needed guidance on what the platform was enabling. The dividing line between platform and app is always tested when the organization represents that split (the same dynamic happens with front-end and back-end in web applications).

The platform believed it was enabling a particular scenario while the apps don’t value the scenario or had a thousand reasons why the scenario is way more complicated, and the platform should go back to the drawing board so to speak. In the case of supporting a pen as a replacement for keyboard and mouse, the list of what was impossible to do in a standard Windows app seemed impossibly long. There was a seemingly irrational insistence that every place one could type could also accept ink input, converting that to text. Being able to ink into the Excel formula bar was both awkward and a technical nightmare, with little benefit.

The only way to have pen support, I believed, was to build a pen-capable app from scratch. Unfortunately, the implication of that was that this new platform did not get Excel and there can’t be a new platform without Excel. Except this new platform was also just plain Windows and ran Excel perfectly, so long as there was a mouse and keyboard. Though requiring a convertible PC was out of the question because of the svelte attractiveness of the screen-only slate form factor.

Regretfully, the perception became that Office was stuck in the mud or resistant to change or influence. This was at least equally, if not more so, a problem of a platform searching for validation from Office without clarity for how apps should work. There seemed to be a great deal more work to do on the very basics of user-interaction before validating that with the most complex applications around. As would prove to be the case for a host of innovations around Windows, adding something on top of, or on the side of, Windows was not a sound method of creating either a new product or market, no matter how much we wanted the new market to be based on Windows, and more importantly to have compatibility with existing Windows applications, especially Office.

Beyond the technical integration was the ever-present go to market challenge. Was the new version of Windows for tablets a separate SKU and if so, was it more expensive, or were the tablet features simply extra features that would light up if the hardware supported them and likewise was there a special version of Office or did Office just light up with new features. We should not forget the ever-present tension over putting everything in the enterprise bundle versus monetizing new innovations.

The desire for optionality, both for Microsoft and OEMs, almost always pulled the product towards a strategy where features would be active if hardware supported them. That way third party developers could always assume the APIs were available on any Windows PC, making it safe to use without concern for system requirements. On the other hand, this also reduced the incentive to use those features (APIs) because doing so introduced complexity into a product where it had to test if features were available or not and behave appropriately. These challenges are why BillG always believed in the magic solution where developers used one and only one API and the conditional or variable implementation was hidden away in the API. Making this concrete it might mean a place in a product expecting typed input would magically transform into a place where a pen could be used for input. No one knew how to accomplish this in practice except for extremely limited scenarios that were more demos than reliable approaches. This was reflected in another classic tension point, which is how much of an application is simply a repackaging or use of Windows capabilities versus creating new capabilities in the application code? Recall earlier discussions over the role of text input and creation where Windows was woefully deficient which pushed Office to build significant capability in how text was entered. This would be repeated across every major component of the user experience—Office simply did not use much of what Windows had added over the years. The implication was that even if such magical transforming APIs were invented in Windows, Office would need to reinvent them for much more sophisticated and capable features that existed only in Office, including text input.

The disappointing truth would prove to be that innovation didn’t move from the platform to the applications, at least when it came to Office. Innovation was flowing from Office to Windows, while Office was no longer looking to Windows for direction. The dynamic of leading applications scaling to a level where they are both dependent on but separate from the platform was a sign of platform and app maturity. It would be a while before we’d learn how problematic that was for both Windows and Office. Right now it was a Windows problem.

Collectively, these lessons failed to contribute to evolving Windows for other markets including mobile phones and home entertainment. It would prove to be an amazing struggle for me in a few years when I worked on Windows.

In this case, Office, at the core, used a mouse and keyboard and did so in every single facet of design. Equally at the core, the pen was designed as an alternative to a mouse not as a reimagined interaction model. It was a pointer, like a mouse, and the fact that it also wrote on the screen was added to the side. In any existing Windows software, writing was done in a small window that popped up and allowed for a few short words to be written at a time. Those words were converted to typed text and inserted into the application. That’s how ink worked in all existing Windows products. Switching between ink for text input and typing was awkward, while ink remained inefficient.

The question was how to make the pen when used with apps like Excel work more like ink on paper. No one really knew because the first requirement was to shoehorn pen computing so as to require as few changes as possible to the existing code base. The theory was, and BillG strongly believed this to be the case, that the pen should just work. If this sounds familiar it is because “should just work” was a common refrain for Bill (This contrasts subtlety with Steve Jobs saying “it just works.”). The right architecture and abstractions should enable whole new implementations to appear above or below a given bit of code and like magic new capabilities appear. Programmers know this is great in theory but almost never works in practice. My rule for this type of capability is that unless the operating system ships having tested a particular type of replaceable layer then it doesn’t exist and if one attempts to use it all the problems will eventually surface. Outlook connecting to internet mail, Word converting to/from WordPerfect, Excel/Access connecting to Oracle database, Windows replacing the file system, and on and on there are too many examples to list.

There were so many challenges, we simply did not know where to start. Some of the problems were hardware related, such as while a typical screen might be 60 or more typed characters across, handwriting was more like eight to ten. All the on-screen places one might type characters, from simple numbers in a date to file names to formulas in Excel, all the way to full pages of text in Word, were too small for ink. Making them all larger was simply the first step in an entire redesign of the product.

While we were debating how to make the pen work, keyboarding was becoming a native skill replacing handwriting in schools. Kids were learning to type at the earliest ages, and handwriting was viewed as optional. Smartphones were not yet ubiquitous but sending SMS by triple-tap captured the imagination of teens around the world and replaced the proverbial handwritten note slipped under a desk. Maybe the opportunity for pen computing was generational. . .a boomer scenario?

Bigtime bosses were very excited by the prospect of pen input. In the EBC and with execs in general, taking an existing typed document and marking it up with ink annotations captured their imagination. They loved this. In fact, I loved it. I reviewed significant memos this way—printed them out and wrote on them in red like a teacher. I took notes at meetings on printed out PowerPoint decks. Yet even I was skeptical that such a scenario justified an entirely new computer. It did not even need a new version of Office. The easy solution could take an image of the document (a PDF!) and support ink on top, exactly what the Tablet PC team’s notetaking app, called Journal, did. It was a fantastic solution. There were still limitations, such as that the ink writing was huge compared to what was easy to read text. In fact, about all that could be done effectively compared to a real pen on real paper were gross annotations like arrows, circles, or crossing out with an occasional “bad idea” scrawled. The technology was not a replacement for the commonly used paper markup scenario. Not even close. It did not help that using a PDF-based solution was completely off the table as far as Bill was concerned. His feelings about PDF had not changed in the intervening 7 years since I first confronted him about the advantages of the format.

Even with those obvious limitations, BillG wanted those annotations and comments to use the semantically rich comment and annotation features that were part of Word, Excel, and PowerPoint—the track changes features used by lawyers. There were many problems with this including training people to use proofreading marks to change text versus typing using the existing keyboard features. The screens weren’t big enough, digitizers weren’t accurate enough, and handwriting recognition not good enough for these features to work.

The Journal app remained the closest we had to a killer app within the Tablet PC team—simply using ink as ink, with occasional translation to text. They made a cool feature where you could print a document to Journal and then mark up on top of it as though there was an acetate layer over a document, spreadsheet, or slide. It had all the limitations above, but the demo was perfect for executives.

Several Microsoft executives were early adopters of the new tablets. While they were effusive about the benefits, there was an aspect of them was difficult to escape. The amount of focus and attention it took to take notes with Journal was excessive. It was a head down, blinders on sort of focus. In meetings with people using the tablet maybe the notes were good, but it was a strain on engagement. As if to emphasize the limitations, executives that liked to print out their notes and file them soon discovered that a full screen of notes in Journal printed out cartoonishly large on standard paper due to the relatively low resolution of screens.

In early tests with the tablet across the company the feedback was uniformly positive, surprisingly so. As we kept digging into it, what was clear was that despite the heft of the early devices they were much lighter than the typical Microsoft issued laptop, which came in at 6lbs or more. It wasn’t necessarily the use of a tablet that people were positive about, but simply having a 4lb laptop. The early tablets were designed as premium PCs, which meant they were light, thin, and very expensive. It wasn’t merely the extra hardware for the pen that made them expensive, or the fancy hinges. The PCs used the latest in chips and displays too.

No matter what limitations, or frankly impossibilities, were raised, it always came back to Office being stubborn or resistant to features from other groups. Microsoft’s inherent bias was always to suggest that the new group with the product that wasn’t done yet was in the right and the existing group was resisting—in many ways this was a correct diagnosis and the right bias to avoid stifling innovation. Such a bias left little room for acknowledging that something new might not yet, or ever, work as intended.

It was clear, by collective body language and explicit direction, that Office was on the hook for something. Aside from adding ink to Word and Excel, what we needed was an Office version of Journal. The idea for a free Journal that came with Windows and a fancy version that was part of Office was exactly like the original strategy of having the mini word processor, Write, with Windows and Word in Office. Could we take a pen-centric approach like Journal and create a new category of productivity app, designed for ink but integrated with Office? Perhaps a Journal that also worked with Word and Excel? Or Word and Excel that worked just like Journal? Should Office build a product specifically for one kind of hardware that would likely sell in small units at first? Would such a product make defining SKUs challenging? We already had a half dozen SKUs and customers routinely expressed frustration with the complexity even though the bulk of our business transitioned to enterprise agreements where SKUs don’t matter much. So many questions about what seemed such a simple request. . .this type of routine program management was difficult and not particularly suited to executive-level strategy discussions.

There were many potential categories for Office to enter as we understood from JeffR’s opportunity map, but none seemed uniquely suited to tablet or convertible devices. Notetaking, however, was perennially on the minds of journalists and reviewers, implying anything we did would get a lot of personally motivated (though potentially nitpicking) coverage. Press encounters were also an opportunity to do research on information work. How did the reporter take notes? What tools were used to organize stories? How did they structure the writing process? By 2000, reporters were mostly using a Windows XP luggable with a big power brick in tow, while using Word to take notes during discussions. At most press events we often set up elaborate strips of outlets (and dangling network cables) attached to tables so the power-draining laptops of the era could plug in and file real-time stories. Invariably, reporters bemoaned the inadequacy of Word and Windows for the sort of juggling they did, working with notes, interviews, emails, documents, and later photos. Office didn’t offer a tool to work with these in one place.

In the old days, this category of software was sometimes called personal information managers, brainstorming tools, or outliners. It was never a big category and fragmented among the many small players and metaphors. It was almost exactly the kind of software we tended to avoid. There didn’t seem to be a winner-take-all strategy, nor did there seem to be a ton of revenue. On the other hand, if we could somehow develop an innovative product that caused people to rethink the category there was potentially a broad and horizontal product that could yield much-coveted organic growth. We discussed the idea that all the Office tools were about producing final and permanent documents, but we lacked a tool for ephemeral information. This seemed to be a potential anchor for a new product. I was under a good deal of pressure to provide innovation in a new category that might lead to new revenue.

Notetaking was definitely worth a try. What’s old was new again.

Trying to navigate the urgency to engage on a pen application and have something consistent with Office, I sent an email to Chris Pratley (ChrisPr), the leader of Word program management, to frame the need for a solution to notetaking. Chris was a Waterloo graduate hired to work on Word products who had previous experience living and working in Japan. He was instrumental in the transformation of Office to an extremely successful worldwide product, especially in Japan. Chris was also one of Microsoft’s earliest contributors to UNICODE standards. Aside from his East Asia experience, Chris was an exemplar of Office program management when it came to defining products and executing.

Our biggest concern was that we would embark on notetaking only to end up with a subset of Word, re-creating the problem of Outlook and Outlook Express, but with the anchor tenant and most used Office app. We wanted to innovate without developing a confusing subset of Word. Customers were already using Word for notetaking but adding a notetaking mode to Word to address missing features would have been a horrible mess and bloat for most customers.

Innovator’s Dilemma would say to create a new team to target new customers, but that almost guarantees a collision with Word (as we saw with Publisher). In our world, any time a new team was chartered they will invariably spend 90% of their initial time revisiting basic user interaction models and duplicating basic infrastructure of the main competing product—such a dynamic was rampant at the company in the early 2000s with every new team creating their own variant of menus and toolbars with a web-like twist under the guise of being easier to use and innovative.

The other option was to ask the Word team itself to develop the product as they would be most sensitive to colliding or overlapping. But would that impossibly constrain the team and create an odd product that spent too much energy not duplicating Word, even if it made sense? Again, so many questions . . .

Most products dedicated to taking notes proved to be subsets of Word, where using Word bullets, numbering, and outlining would suffice. Scenarios were changing, however, and notetaking was expanding to include collecting snippets from the web, links, photos, and even audio and video from new laptops incorporating cameras and microphones. To differentiate notetaking from Word, we needed a novel approach to the problem that went beyond typing (and inking) and basic text entry. Tailor-made for user research, notetaking was the kind of thing researchers loved to study. Suddenly, the hallways were filled with examples of notes, the flow of notes for different authors using different tools of Office, notebooks and ways people organized them, notes for students in classrooms, notes for home and work, and more.

Examples from the Office hallway in building 17 showing notes and notebooks collected from a field study. (Source: Personal)

The team was excited and quickly converged on prototypes and an approach that was ink-centric yet also text-centric and highly differentiated from Word—in other words they took on all the work to design a product that seamlessly worked with ink or with a mouse and keyboard, or both. Peter Engrav (PeterEn) joined to lead software development. PeterEn, a rare Bellevue, Washington, native, was one of the most thoughtful development leaders on the team—he was also a founding member of JonDe’s Office development team working on Escher graphics. Our offices were next to each other during the Office11 project and he and I often discussed the choices he was making into the late hours of the evening. The team picked a code name even though Office tended to shun code names, Scribbler.

ChrisPr took the team through a planning and vision process just for Scribbler. The team had sketches, prototypes, and a vision, Scribbler.doc. Perhaps a most impressive aspect of this process was how closely the concepts and details outlined in the original vision made their way to the final product.

From the outset, Scribbler intentionally did many things differently, as expected. We viewed it as a chance to pioneer some new approaches. While not as freewheeling as it might sound, the team would definitely say they would bump up against the culture of Office more than once—ironic given that PeterEn was a founding member of the Office development culture.

Scribbler built a native XML file format with next-level robustness, as one of those new approaches. Scribbler’s files could have multiple people edit a file at the same time and almost immediately see the changes made by others. Editing by multiple people seemed crazy for a personal notetaking product, but early on the idea of shared notes or group notes became a hallmark of the innovation. To enable shared editing, Scribbler would eventually be able to use SharePoint and, for one of the first times in a Microsoft product, data was stored on the internet (what eventually came to be the cloud). While we abandoned many of the MyOffice internet experiences, Scribbler eventually offered a key demonstration of native internet services.

Scribbler was able to focus on truly differentiated features because it was the first new product to make use of the MSO.DLL, or the Microsoft Office library of shared code. For the five previous years, Office engineered a platform of shared code for Word, Excel, PowerPoint, Outlook, and others, but no new product tried to use this code starting from a clean slate. Remarkably, PeterEn and the development team were up and running in short order by using this code—normally it would take months of work for a new application to take shape. With minimal effort, Scribbler inherited all the basic capabilities of an Office application, such as menus, toolbars, localization, Watson recovery, fancy graphics, enterprise deployment and management, plus engineering and test tools, and much more. This let the team focus on the core task of taking notes. It was exciting to see MSO in action and, most importantly, to show that in middle-age Office reached a significant level of operational maturity. InfoPath, discussed previously, also used MSO.DLL.

The novel experience of Scribbler and the key differentiator for users was the ability to write or type anything anywhere on a page. Just like on paper, one could simply tap the screen with the pen and start writing or click the mouse and type in that spot on the screen—delivering on the promise of the NetDocs universal canvas demo from Forum 2000. If one thinks about each of the apps, Word documents are bottomless, starting at the top and continuing down with a fixed page width. Excel is an endless two-dimensional grid. PowerPoint is a fixed-sized rectangle that allows anything to be put anywhere. Scribbler was bottomless, two-dimensional, and it also let users put anything anywhere simply by clicking and typing or tapping with a pen and writing. Ink and text were seamlessly and effortlessly mixed. Content like photos, videos, and audio could be added anywhere on a page. In a hint at the future of all applications, Scribbler also let users mostly ignore files and the tension-filled process of saving data and simply organize thoughts as one did with a paper notebook, with tabs, but with the advantage of software. Reorganizing and quickly searching across all the notes brought the power of software to note taking.

One area where Scribbler diverged from the way the Tablet group thought was integrating handwriting recognition. ChrisPr and team found in working with early adopters that recognizing ink as text was of little utility—people rarely wanted to convert their ink to text. In fact, people loved leaving ink as ink. Where recognized text was most valuable was in searching through the ink notes. Scribbler constantly recognized the ink converting it to text for search, but rarely did that ink get used in other places. Journal had taken the lead from BillG who was literally obsessed with converting ink to text and was generally against leaving ink as ink. It was a debate he and I had many times when looking to expand the use of ink in Word and Excel.

There were many seemingly small but novel touches in the product such as the ability to create a table by typing, hitting tab, typing, tab, typing, return, and poof, a table appeared. Scribbler also created checklists—list items that could be marked as to-do items, checked when completed, for shared or personal use. Scribbler supported photos, drawing shapes, and a whole range of outlining features.

The most eye-popping demo was when taking notes on a new Tablet PC, whether typing or using a pen, Scribbler could record the audio of a meeting and keep track of what notes were taken during the recording. One could easily hop from a note to the full recording of the meeting or vice versa across pages of notes. In another demonstration, easily drawing diagrams using a pen on a PC with the same ease as on paper was unimaginably cool.

Despite all that it offered, and as important as I thought it could be to the Office franchise as a growth opportunity, Scribbler would become the next innovation to get caught up in the challenges of bringing new revenue-generating capabilities to market with Office. Should Scribbler be a new category of software with dedicated marketing and sales yielding new organic revenue, or should it be added to the Office product enhancing the suite for every user? We faced this challenging decision so many times: Outlook, FrontPage, SharePoint, and now in Office11 with Scribbler and InfoPath.

Scribbler was designed to be a core part of the Office suite, a broadly horizontal product, not for a small or specific segment or narrow selling proposition as we saw with InfoPath, Access, Visio, Project, or Publisher. Yet, in an ironic twist, Scribbler did not make it into the suite and was destined to be a new category.

Normally this would be a great idea. A new category meant a real revenue opportunity. That opportunity was only realized with a dedicated sales effort. A dedicated sales effort for a broad, horizontal product would be nearly impossible because those same resources would be selling the Office suite and upselling to EAs or more expensive suites. Recall, however, that the notetaking category was known to be fragmented and small. Such a category has a low return on investment. Customers are hard to find and the efforts at reaching them don’t scale well. When you do find those customers, because there are so many alternatives, there is little pricing power.

Adding Scribbler to an existing suite would make the product available to everyone, which would be great, but would not alter the sales motion unless it became the key reason to upgrade or sign an EA. There were no such plans. In fact, the formal Office 2003 product guide mentions the new product exactly twice in 170 pages. One mention is a trademark footnote and the other in the SKU table, whereas Outlook is mentioned almost 200 times.

Scribbler was a product for everyone but marketed and sold to no one. The only suite Scribbler was added to was Office for Students and Teachers, used as a way of communicating that the low-priced suite was poorly suited for business enterprises because it included a notetaking product. In fairness to marketing, Scribbler had done some pioneering work with students at the University of Washington to support notetaking in college courses. Students loved Scribbler, which was also a testament to the product design for a version one product.

It would be reasonable to ask why I did not force the issue with marketing. Primarily, my view was that SKUs were entirely a marketing decision and accountability. With a dozen individual applications to mix and match, marketing spent the better part of a year picking and choosing combinations. The development team invested in features to make the production of different suites easy. I would be remiss if I didn’t mention that to consolidate marketing across the entire information worker business, JeffR took on marketing as a direct report as well. Packaging literally wasn’t my job or accountability.

I have exciting news to share: You can now read Hardcore Software by Steven Sinofsky in the new Substack app for iPhone.

With the app, you’ll have a dedicated Inbox for my Substack and any others you subscribe to. New posts will never get lost in your email filters, or stuck in spam. Longer posts will never cut-off by your email app. Comments and rich media will all work seamlessly. Overall, it’s a big upgrade to the reading experience.

Right up until the last minute, we had trouble coming up with the commercial name for the product. Scribbler was a good name the team loved, but we were unable to secure the rights. Eventually, the marketing team settled on OneNote, a perfectly good name but the one that left the product team somewhat bummed. Over the course of the product cycle, Scribbler really grew on the team and came to mean a great deal to them. Most (including the press) had a first reaction when hearing OneNote as it reflected the common expression “one note wonder” as in lacking range. It was a name where common usage reflected poorly, shades of DIM Outlook. In a small form of passive protest, some on the team mockingly referred to the official name as Onay-No-Tay. Fortunately, this name led to a tagline “One place for all your notes” and that made everyone happy. Like every naming exercise I experienced, eventually everyone warmed to it.

The product went on to be much loved by a core set of customers and received many super positive reviews. Ed Mendelson of PC Magazine, a longtime (very longtime) reviewer of productivity tools, called OneNote “breathtakingly well-designed.” Paul Thurrott, also a longtime Microsoft commentator and often a critic (especially of me), said, “In my mind, OneNote is one of the best applications Microsoft has released in years.” He and other reviews bemoaned the fact that OneNote was not included in the typical Office suites they bought.

The Tablet PC group was both happy and disappointed with OneNote. On its own OneNote showcased the new convertible Tablet PCs. Reviewers who loved OneNote were anxious to get their hands on one of the new devices, and certainly all the device makers were anxious to show off the capabilities using OneNote. At the same time, the existence of OneNote was viewed as some sort of cop-out relative to solving the big problem of using ink as a first-class input in Office apps. Perceptions aside, we invested disproportionate engineering effort to implement ink support in Word, Excel, and PowerPoint.

I viewed that criticism as harsh and a way of dodging the real question, which was whether ink was broadly suited to productivity or simply a way of trying to use software to emulate an old way of working. Was it the equivalent of controlling the first motor cars like a horse or was there something deeper about the benefits of ink? Was using a pen and ink something that seemed natural to a generation that had to learn to type later in life? Was handwriting a skeuomorphic answer to human-computer interaction that long outlived its need as a technology bridge? It might be an ironic twist that finally after decades of research and development handwriting, which was always the next big thing just five years out, improved to the point that it worked but the market that might have existed moved on.

We are 20 years through continuous investment with massive improvements in recognition technology and first-party hardware that supports pen input, yet the usage remains de minimis.

I have such a warm place in my heart for OneNote. The team did such a wonderful job. It was a breakthrough product, taking advantage of the latest operating system, while leveraging the latest hardware. Failing to capitalize on it with the field and business left me feeling that I let the team down. Microsoft couldn’t capitalize on a horizontal, pure-play productivity tool—the sales team and Office bundle wanted IT-centric, and enterprise-focused products like InfoPath. OneNote was a distraction.

The good news: There was no shortage of complicated features for IT professionals.

On to 073. **DO NOT FORWARD**

With the announcement of .NET, Microsoft was overflowing with projects, many not yet products, destined to become the next big thing in one area or another. Everything had a “Net” somewhere in the name and everything was in the press or in an enterprise strategy deck. There was plenty of optimism, but collectively the company was well ahead of itself. There was simply too much going on to have a coherent strategy or roadmap, even though BillG was 100% focused on that, having assumed the role of Chief Software Architect. The push-pull of “be more innovative” and “ship real soon” meant that many of these efforts were at the ends of the spectrum of “architecturally suboptimal in order to finish” or “architecturally correct but can’t possibly finish”. The unwinding of projects like this is incredibly painful for everyone involved, especially when what really happened is so different than perceptions.

If you have not seen part 1, check out 064. The Start of Office v. NetDocs

Back to 070. Office.NOT

Hardcore Software is a reader-supported publication. To receive new posts and support the work, consider becoming a free or paid subscriber.

I was still working through the stages of grief over a product getting killed or at least wounded, considering what happened to Office.NET quickly renamed Office11 at the last minute. Karma was about to come back around and bite me for, ostensibly, doing the same. Since Forum 2000 in June, the NetDocs product continued development. The team expanded, absorbing products, and broadening the mission. BrianMac used the same approach and much of the team that created Outlook.

The team was fired up but going in several different directions. Depending on who you asked on the team, NetDocs might be something different. What originally started as a new style of document creation tool, blending aspects of word processing, spreadsheets, and databases, expanded into a full-blown email program to replace Outlook, a photo editor, and even a web browser. It was also using the latest (unfinished) and most strategic technologies. Sensing the excitement over XML, the product also found itself deep in that strategy and brand new code. NetDocs was also using the latest reusable code from Internet Explorer, which was great for the IE platform but also meant it was not exactly what most customers thought about as a browser-based implementation. Along the way, it created some of its own technologies such as the ability to install updates easily over the internet. There was a lot of excitement over a product that does. . .everything. How could there not be?

On paper, this was quite something. During the early days of MS-DOS, these all-in-one products always struck a chord with techies and regular people alike. The idea of using only one tool to get everything done, including email, was insanely appealing. In demos, everyone, especially BillG, got excited. The idea Microsoft could finally crack the all-in-one category with a professional tool would be huge. ChrisP had a name for a design demo that incorporated “all the best of everything in one easy-to-use app.” It was called Uniprog Deluxe. That’s what we came to call this expansive vision. It wasn’t meant to be cynical as much as it was meant to imply an unachievability.

Importantly, NetDocs was also a key part in the nascent strategy to use XML everywhere. XML was being pushed heavily by BillG. Despite being a simple text file format, Bill had let XML take on the role of providing a proprietary advantage to Microsoft in some way. This was a difficult topic to discuss because it conflated several aspects of implementation (such as where the actual intellectual property or code was) and appeared to assign proprietary value to a simple text file. Much of the excitement around XML (and thus NetDocs) was because of the concerns over the now ubiquitous HTML format and lack of proprietary control Microsoft had over a format. In short, XML was the way to regain a proprietary control over an internet technology. Whereas HTML was viewed as a display format, XML was viewed as a structured data format. I had a difficult time with the magic attributed to XML, especially because Office was already invested in HTML. I was holding on to the notion that HTML would remain human-readable at some level, whereas XML was brand new but already super complex (advocates would say it was never meant to be human readable). We planned on a significant amount of XML work, but viewed it as interoperability more than proprietary advantage. For example, Excel would be able to import XML data files such as those from the Securities Exchange Commission or SQL databases.

There was one big problem. And a lot of little ones. The big problem was creating yet another email program—while NetDocs did try to do a lot of things, everything emanated from being an email and scheduling product. Microsoft went through several years of a comical email client strategy that was confusing and frustrating to customers. Email was literally the most important product the company was building and the most important enterprise product. Not only was it the key server product, but it was also the key new Office module. Perhaps that is why we had so many email products in the market and in the works—something important attracts a lot of attention from development teams looking to do important work. In a world where we were just establishing enterprise credibility, having multiple email programs was a disaster, especially when our flagship one wasn’t so well-received, yet.

When something is hot, however, every project converges to that product. So everything had to do email.

We had Outlook, which was struggling to become a great product for Exchange and enterprise email. After the initial release that just made it into Office 97, there was the split and the creation of Outlook 98, which was either a not-so-great Exchange client or a not-so-great internet mail client, but not both. Then for Outlook 2000 and then again with Outlook 2002 (XP) we failed several times at becoming a more reliable Exchange client with a new storage engine. Finally, with Outlook11 we committed to addressing the problems, come hell or high water.

We also had the new browser-based version of mail, which we named Outlook, technically Outlook Web Access, even though the relationship to Outlook was zero when it came to code and only acceptable when it came to user experience and features. The inability to share code and limited capabilities of rendering all of Outlook in 2000 era web browsers caused this divergence and inefficiency. Customers were extremely enthusiastic for the promise of browser-based email with Outlook Web Access.

In 1996, the Windows team released Internet Mail and News, or IMN, which became a much-loved internet mail program. It was part of Windows and Internet Explorer, made by the same team. IMN was plugging along doing great things for the internet when it became clear to our enterprise sales efforts that we could not have a first-rate internet mail and so-so Exchange mail. The solution was—and I’m not making this up—to rename IMN to Outlook Express.

This was a decree that neither the Outlook team nor the Windows team liked, but the theory was that it clarified the products for customers. The IMN team did not want to be tainted with yucky enterprise Outlook, and the Outlook team didn’t want to be confused with free or, for that matter, the internet. Customers called everything Outlook and were, basically, always confused. Product support was confused. Reviewers were confused. Most of all, normal people were confused. It was a silly, self-inflicted mess that continued for more than a decade, except for the reality that in 2001 work on both Outlook Express and Internet Explorer stopped, and and improvements were dependent on the future Windows Longhorn. There were no plans to update either on Windows XP. Those capabilities were going to exist in some new form on Longhorn.

We had Outlook, Outlook Web Access, and Outlook Express. The branding and naming relationship was much deeper than any technical one.

To complete the mail strategy, we also offered Hotmail, the web-based email acquired in 1998. Hotmail was both a mail “client” and a mail “server” in BillG architectural diagrams. MSN mail was trying to converge to Hotmail, but was also building a client-side application to compete with AOL (and thus a client mail experience). Hailstorm was slated to provide (or connect to?) a set of these email experiences, but it used a different protocol.

If you were to try to build a matrix of mail clients and mail servers and which connected to which, you’d have a matrix with many holes. Our strategy was a mess.

Many reporters (and customers) at the time looked at this mess and thought of teams competing and some sort of bloody “there can be only one” battle within Microsoft. From inside, it was not that at all. In fact, by and large the teams did not care what each other did. In its own way, each team thought they would win out in the way they expected and the others simply wouldn’t be relevant to the battle the way they defined it. Outlook Express was certain they would win against Eudora (the leading classic internet email program) or Netscape Communicator, if for no other reason a bunch of people weren’t going to pay for Outlook (not to mention, that Outlook was in no way competitive with Eudora). They were right, and the Outlook team put little energy into competing with Eudora or Outlook Express. MSN was going to win with their own subscribers and be the best (and only) experience for their dial-up customers. Hotmail was going to become advertising supported and win in browser-based email. Outlook proper anchored itself in the corporate market with Office, and made all the money.

There was a competition and that was for people. Recruiting and hiring was a source of conflict. Often when a new group spun up, recruiting kicked into high gear. There were neither rules nor much of an internal system that managed individuals moving between teams. Most moves happened by word of mouth. Teams would routinely bump up against the norms (not formal rules) by implying the potential for promotion or broader responsibility with a move. More often than not an employee would get caught in the middle of one manager recruiting heavily and another manager trying to hold their team together in the short term.

Such staffing skirmishes uniquely impacted Office where the vast majority of our hires came from college (hundreds per year) and we maintained a strong culture of finishing a release that was started. Luring people away from the team mid-cycle was something we deeply frowned upon at a cultural level. New hires with even a partial release of Office could join a team having gone through valuable training and initiation by Office. At release boundaries, Office proved a strong net exporter of people to other teams, renewing our own teams with even more college hires the next year. Since there was no coordination by HR, more than anything it was this cross-recruiting that introduced friction between teams.

If there was drama it was mostly constrained to the boardroom where the complex matrix of what worked with what, and who was using the latest technology were BillG’s main discussions. Most of the time the problems were not anyone’s fault, as much as the teams thought it unnecessary to implement something because their customers didn’t care.

Yet the strategy from the top of Microsoft was to resolve these architectural “impurities” and to strive towards rationalization and consistency. Still, that did not create competing groups as much as a set of groups that all thought the other groups weren’t doing their part to increase synergy. There wasn’t anger, hostility, competition for resources, or anything substantial. Mostly, it was just eye-rolling and exasperation at a lot of meetings followed by long emails over how impossibly difficult some alignment would be technically.

The post-2000 Microsoft (after Windows XP and Office XP, with the arrival of the enterprise business) was a period of extensive meetings around synergy and strategy. At the extreme, groups could spin out of control on their own by signing up for too much synergy and strategy. At another extreme, groups could stay focused on shipping. Leading the former meant receiving high praise and attention internally while failing to deliver or delivering what was perceived as suboptimal. Groups of the latter type shipped and often received poor marks for lacking strategic alignment while developing a reputation for being difficult to work with. The reader is invited to guess which type Office was closely identified with and I came to personify that. Nothing occupied my psyche more than this reality I lived. Shipping is really difficult, even more so at scale. As ChrisP used to say in his “Shipping Software” talk from the early 1990s, it is like everyone comes to work every day to prevent a team from shipping. “Everyone” can be many people in a big company.

Every once in a while, something would get so visible and so tricky that a decision would have to be made and we could not just let some notion of passive-aggressive Darwinism decide.

NetDocs was another mail program, one that would in theory work for both Exchange and internet mail, and maybe even Hotmail, MSN, or new Hailstorm mail. Over the intervening years, since the NetDocs team was formed, Outlook won over corporate America and gained an enormous number of features—very difficult to code features. Everything from handling attachments to scheduling meetings across time zones, shared mail accounts, recurring events, sharing calendars with coworkers, SPAM protection, security, looking up other employees in the corporate address book, plus to-do and task lists, and personal contacts, and still more. Those features were built in Outlook; in fact, many weren’t even available in the web version of Outlook Web Access (thus adding to the complexity of our mail story).

To software architects, the code implementing the semantics and capabilities of the Microsoft email solution was in Outlook running on the desktop, not running on the server. It was architected in a decidedly old-school manner, mostly out of necessity but also because of history. The problem (the big problem) was that there was no way for NetDocs to implement all those features either on its own or by sharing code with Outlook. It would be like trying to use Word’s code for footnotes in PowerPoint, without dragging along all of the Word code. Code doesn’t work that way. Getting all that right in the new NetDocs code base was a long project. Infinitely long. The team knew this, primarily because it was made up of many members of the original Outlook team. They were not worried. Their intent was to introduce NetDocs and add features over time.

There were nearly countless smaller features and implementation details to worry about. Being built on all the latest and greatest technologies from .NET and Internet Explorer was great in theory, but in practice most of those technologies themselves were far from being complete. In a commercial product for hundreds of millions of customers, they expected the product to handle typing in the world’s languages (left to right, right to left, vertical and switching between)—a particular hot-button for Office given how much work we put into this area. They expected it to understand how dates, time zones, and other locale-specific data worked, which was especially important in calendaring, and they expected it to work with accessibility tools for people who needed assistive devices to read the screen or used alternatives to mice and keyboards. Customers wanted the product to work on the hardware they owned with the amount of memory and processor they already had. These “abilities” as we called them were a long list of requirements to just release a product that carried the Office logo. Many of these might make sense to readers today because the operating system, particularly mobile phones, provide this auto-magically by simply using the platform as intended and this is verified in the App Store submission process.

In a series of meetings and demos to BillG, SteveB, JeffR (who managed both NetDocs and Office), and many across the company, it became clear we were heading for something a big company never wants to happen—a decision meeting with consequences. I often referred to a line from the movie Wall Street when Gekko (Michael Douglas) sighs, “Showdowns bore me, Larry. Nobody wins.” It is never a good thing when there are only two options on a substantial decision and a deadline, forcing one side to walk away a winner and another a loser. Management is all about avoiding these situations in the first place. The Microsoft of this era didn’t make choices early, and for good reason—the original Windows project was exactly the kind of thing that could arise if you let ideas flourish. Windows NT was essentially a side project. Windows 98 (98 SE, and Me) took on the role of side project. The whole company was built on what were rebellious side projects.

It is easy to skip this point or to take the point of view that conflicting side projects are a cultural disaster that eats a company from the inside. It is very easy to say that. In practice, projects that might conflict also create optionality. Great CEOs treasure optionality. BillG was one of those. The risk is not having too many options, but too few. The other risk is that all the options being developed converge on products that look too much like what we already have versus new approaches. That is the mistake Microsoft made with some frequency. Too many photo sharing tools. Too many data access technologies. Too many mail clients. Each of which was similar, but different while not anchored in a scenario that introduced a step function change in the trajectory of a category. The key indicators of potential trouble are usually obvious in hindsight. First, the project plans become especially expansive and generally can’t be scaled back because every feature area is critical. Second, the team size becomes especially large. Rarely do small teams cause big problems.

In this case, NetDocs worked super hard and made a ton of progress. Between two alternatives of fully replacing Outlook in the next release of Office or adding a fourth mail program even one that was potentially exciting to Microsoft’s already confused mail strategy, there was no good answer. Not wanting to decide immediately, a question was how much more time it would take to be a full replacement for Outlook. Brian and team wanted to release a product and grow into the market, rather than wait and wait perhaps suffering from the enemy of the good is the perfect syndrome.

Unfortunately, catching up over time seemed like an unbounded problem as well—Outlook and Exchange were evolving. These products were still early in their lifecycles. For example, the major work to improve reliability was about to start and that could have a broad impact on all the code already written for NetDocs. Across Office, everyone was working to integrate with Outlook. In the competition with Lotus Notes, we continued to try many new features to embrace programmability of mail. It was not simply replacing a static view of email but plugging into an entire collaboration strategy. We already failed twice trying to use the new storage system for Outlook, would NetDocs be able to make it work?

The only thing we could do, and have a rational email strategy, was decide not to ship NetDocs and find a way to create a new product that did not try to replace Outlook. That’s what I wanted to do and advocated. The past few years of trying to stabilize Outlook left an impression on me. I didn’t see a path where NetDocs could ever catch up and was deeply concerned about customers perceiving the need to choose between NetDocs and Outlook, knowing how much of the Office value proposition was built around communication scenarios using Outlook.

For all the good ideas and hard work, a clear decision was needed. We discussed alternatives with the leaders on the team. There were well-deserved mixed feelings and some significant pushback, and honest emotion. The leaders on the team knew the facts and challenges, and so did most of the team.

Brian met numerous times with BillG and SteveB. Along with the NetDocs leaders, JeffR, Brian, and I met with BillG to decide on a plan to ship NetDocs with Office or not, and not shipping probably meant shelving the project. Brian hated this kind of meeting. Showing up with two options always meant debating a third option. When it came to this level of technology and product, however, it was increasingly difficult for Bill to have the best or most informed opinions. The company was made of so many brand-new products and technologies, no one could keep track. The NetDocs team was exhausted. They had worked tirelessly for the weeks leading up to these meeting to see just how much they could get done. Knowing them well, I could sense the resignation.

It was too tall an order to deliver on all the new things while maintaining compatibility with Exchange and Outlook, while advancing in all the ways they intended. It might sound like we could finesse having two products, but not for the Office business, not against Lotus Notes, certainly not for enterprise customers with new Enterprise Agreements, and definitely not for industry analysts and the press. Our credibility as a company was on the line and too much was at stake too soon in the adoption curve.

The team tried to do too much, too soon. Brian agreed with Bill that team should have focused more on XML seeing how important that had become to the strategy, and that it would have been too difficult to have a sort of slow burn email strategy where it took several releases to surpass Outlook. There were better ways to have a bigger impact, and sooner. Bill was clear he should have provided more direction to the team on priorities. There was ample humility and professionalism to go around. As painful as this transition could have been, much of the difficulty was mitigated by the level of accountability Brian and Bill demonstrated.

Brian pushed to have the refocusing of the product to XML scenarios happen within the Office team.

We held an all-hands meeting with the NetDocs team in the cafeteria, led by JeffR. While the decision was made between BillG and BrianMac, there was no escaping that some perceptions of this were about how I held control over the Office “box” and thus I ended up bearing the brunt of it, especially for those who thought NetDocs was closer to realization than not. Any meeting like this was going to be tough. Still, cancelled and redirected projects are a part of engineering and often turn out to be important lessons for many. I had just gone through a last-minute reset as well.

Few engineers make it far into a career without enduring at least one major project reset.

I was caught off guard by how much the press had continued to portray this as a battle, my battle. There were so many difficult situations, differences of opinion, and product challenges, but this wasn’t one of mine. I experienced a friction between teams, primarily over hiring, and some regarding product claims when it came to working with Exchange. The irony of the situation was the friction was mostly rooted in the history and connections so many of the engineers on the team shared. It was as if members of the old Outlook team started building a new Outlook to take on their earlier creation—perhaps a second-system syndrome as detailed in Mythical Man-Month.

When a project goes through a big change or reset, the feelings come out. When a project is in the press too early in its life, then these feelings make it to the press too. I knew enough to understand that people want to find a clear point of responsibility, even blame. I was an easy target. It would not be the first time.

It was also ill-advised to engage the press on these stories, leaving them to be based on whatever perspective was tipped to one of the Microsoft beat reporters. I understood it was clearly part of the job for me to take on accountability for things that don’t go well, even when it feels like a stretch to call something my fault. I watched every manager or mentor I had (BillG, JeffH, ChrisP, MikeMap, PeteH) do that more times than I could count. Like so many difficult situations, the NetDocs transition proved a valuable learning experience.

Many on the NetDocs team used the project reset as a chance to stick their heads up and see what other opportunities were going on around the company and beyond. More specifically, there was a noticeable exodus of middle pyramid people in this era. The core group that remained earned a unique opportunity to create an entirely new product for Office11 focused on maximizing the value of XML. That was the constraint. My view was that if they were close enough to spend all this energy on NetDocs shipping in this timeframe, then they could ship the less complex product (without email) while still having the full Office11 schedule to work. They would be able to use the Office shared code to bootstrap the entire app, which would save a huge amount of time and also make consistency and synergy much easier.

During the project, NetDocs had expanded scope broadly so as to include the universal canvas, XML editing, XML data transformation, new user interface, a mail and calendaring client supporting both old and new protocols, and many more. To support these the team grew to a significant size—over 500 people. To put that in perspective, the entire Office team was about 2,000 people including everything sold under the Office umbrella. Office maintained a long history of letting people move around the different teams (or, staying put if they chose) at the break between releases. That is exactly where we were which enabled many to easily move to other parts of Office (or other teams). Don Gagne (DonGa) who previously led Outlook and then moved to NetDocs would soon find a huge role in Office, so it was rather fortunate he stayed on. In writing this, I know that all these names can sometimes seem to be overdoing it but having read many accounts of how things happen in big companies I always feel that too many key contributors and their work are left out. There won’t be a quiz at the end.

From NetDocs, Don Gagne (previously from Outlook) would lead a newly formed team called XDocs, short for XML documents, along with Rajesh Jha (RajeshJ) leading program management. XDocs was NetDocs repurposed to an end-user tool using the XML technology using the core NetDocs code base—at a high level NetDocs without email and calendaring. There was much work to be done in that regard, including the difficult work of right-sizing the team for the task at hand. PPathe would step up as a VP to provide additional leadership in helping to integrate and shape XDocs. He brought with him a deep understanding of the history of SGML (the predecessor of HTML) and the way Word embraced HTML, which would come in handy when it came to XDocs integrated across Office.

The team went through a fast process to identify where XML technology in NetDocs could be reused. XML generated a ton of buzz in the industry as a way of exchanging data between applications. We increased support for XML in Excel (for example, the SEC began requiring companies to release quarterly earnings in an XML format, making it easier to import into spreadsheets or databases for analysis). BillG was now actually excited about XML in Office11.

The Infopath team under RajeshJ’s leadership was one that appreciated that diversity of the team helped to build a better team and better products. Early in the product cycle the team made this video introducing members of the team.

Leading the effort to create a vision for XDocs was Judy Lew (JudyLew). Judy joined Microsoft about five years earlier out of the University of Michigan MBA program. She attended Columbia University as an undergraduate and her pace in words and action was more New York than her Utah upbringing. She was thoughtful, analytical, and persistent, traits which served the team well in pivoting to an entirely new product.

Her research identified a tool for companies to create forms—expense reports, invoices, surveys, and more. She envisioned enabling a much more elaborate experience and including programmable logic, data validation, and connectivity to other data sources to make it easier to fill out forms—a significant benefit, it could function without being connected to a network using offline email, which was a huge win at a time when getting online was incredibly difficult. Such a product could help in competing with Notes.

XDocs showcased SharePoint to share forms and store the results of the data collected. Competitively, IT developers were starting to use web browsers for many applications and were often seeing limitations of HTML compared to how these problems might have been solved with tools like Visual Basic.

To put XDocs in today’s context, it was designed to solve many of the problems solved by DocuSign today. Before web browsers were as capable as today, having a desktop application where the form to be signed and manipulated came together was a good idea. As it would turn out, leading customers were perfectly happy dealing with the limitations of browsers and HTML if it meant not deploying a desktop application. There was an extremely important lesson in there. The era of looking to solve new problems with a new Windows application was over. I was increasingly convinced of this fact. Not only was this an unpopular opinion inside the company, but the company strategy also assumed this was decidedly not the case. The problem for me was the Microsoft bubble with influential enterprise customers and the strategy bubble inside the company were protective enough that it would be years before the reality of our situation would be shared.

If having to outright cancel projects was rare, rarer still was the opportunity (or ability) to pull from the ashes of a cancelled project an entirely new product that, at least at the time seemed strategic and viable. The team, and the broader Office team, were excited by the work. Judy Lew’s efforts were remarkable as was the execution for the remainder of the team. It was not our best product (in fact, it was a failure in hindsight, the right problem to solve but the wrong technology approach) nor was it the most exciting to work on but going from a long trek of not shipping to creating a credible product so elegantly was a noteworthy accomplishment. The team left behind a consumer subscription product for email to build an enterprise business process tool using XML. They delivered and that was a huge accomplishment in this era—so many new ideas failed to gain escape velocity. As Brian said in his mail to the team announcing the changes, organizing in Office would be a huge opportunity to ship on time and to maximize the potential impact of the product.

InfoPath, the final product name, shipped with Office11 as a full-fledged module in a business SKU. It showed off a strategic new technology, XML, along with SharePoint and Outlook, and it helped to compete with Notes. It provided the kind of strategic demo of business value that the salesforce appreciated. It was the kind of product that Microsoft Press, Microsoft’s book publishing subsidiary, pursued aggressively resulting in a book even before the product released. I fondly recall stopping by Rajesh’s office when he showed me the book, beaming with pride.

InfoPath was bundled in an Office enterprise SKU. Doing so brought great distribution but made it difficult to realize the true value. As with Outlook, the desire to support the bundle was greater than any incentive or perceived opportunity to create a new business. JudyLew’s work clearly identified the revenue opportunity and specialized customers for this type of product. Reaching them, as is often the case, required an investment in new sales and marketing people and programs.

Sales and marketing did not share those views—their priorities there were to increase the perceived value of Office, particularly signing new and renewing enterprise agreements. XDocs had the beauty of being a high-end tool for IT while being useful to every desktop in an organization, which fit in well with the EA.

From my perspective, I faced another round of being on the hook to deliver organic innovation that expanded to new categories, only to see the work turned into incremental innovation to support the existing Office bundle. The pressure to drive upgrades was greater than the need for more organic growth, yet it was clear no one was going to upgrade for InfoPath more (or less) than for any other feature in the bundle. The difficulties in upgrading were unrelated to the value proposition of any part of the suite. The complexity of the overall platform of Windows and Office cemented a view that any change introduced upgrade friction. As we saw with browsers, if something interesting came along that was entirely new rather than simply an upgrade, customers were more than happy to consider adding to their standard deployment. We never got the chance to see if InfoPath was interesting enough to consider as a new addition to the enterprise platform. It was just more bloat.

I was disappointed that we chose to simply add more bloat to the perception of Office, as reviews would say, rather than strive for new business opportunities. The revenue for Office kept going up, either demonstrating I was wrong or perhaps proving that with the product-market fit we achieved for the core suite, nothing else we did could impact the suite business.

Still, this was difficult for me. Clearly, I was responsible for what ultimately transpired in the NetDocs to InfoPath transition, at least to the degree that I advocated for the only rational choice technically and in the context of EAs and the business. On the other hand, I was not the one who let the product go on for a couple of years nor was I the one who insisted on the demo at Forum 2000 (and numerous other demos to all sorts of industry people). NetDocs had enough external exposure that it was clearly perceived as a super cool product under development—at least based on that cool demo at Forum 2000 (why else demo it?). Would it have been better if it were permitted a slow burn over several years? I have my doubts, as the technology seeds that it contained were inside the Microsoft bubble, not where the industry was strongly heading. Instead of a Win32 app and proprietary XML, Office would double-down on browser-based tools starting in the next release of Office. Ultimately, the product just was neither different enough from everything going on nor did it take a radically different approach that could come from a new technology.

Thanks to me, I suppose, NetDocs was one of several products on every list of legendary Microsoft products that never made it to market. Much later, another one of those products caused me and the company a considerable amount of grief.

Stay tuned.

InfoPath was not the only new product in Office11…

On to 072. Notes on Tablet PC Innovation

Welcome to the only project I worked on that had the plans upended at the last minute after one executive meeting. This is a journey that starts back at the 1999 Company Meeting and the unveiling of “Software As A Service” bet the company strategy. With many excerpts and artifacts, we will go through planning Office.NET where you’ll really get to experience the product planning process in Office. Followed by a last minute change putting all that work at risk.

Back to 069. Mega-Scale, Mega-Complexity

In the fall of 1999 Microsoft held its annual Company Meeting at the old Kingdome (a stage was set up over second base). While most of the world was fixated on the rise of internet sites or more likely the looming Y2K crisis, both SteveB and BillG used their time to begin a transformation of Microsoft—the transformation to a software services company (this would later be called cloud computing). Few even in the industry knew what this meant. Pioneer Salesforce.com was just months old and the original cloud infrastructure company Loudcloud started by web browser pioneer Marc Andreessen and former Netscape executive Ben Horowitz was incorporated just a week before the Company Meeting. This was very early, but it was also very big. Even though Microsoft was at the peak of success and the most valuable company in the world, the company was going to be reinvented. It was powerful.

BillG spoke first. His opening was dramatic—a reinvention of the core mission statement for Microsoft—the title slide was “Changing the World of Software”. From the meeting transcript:

The vision statement that many of you have heard, year after year after year, we actually decided to change. That statement, a PC on every desk and in every home, running Microsoft software, is still true. It’s a great vision. It really drove the company for the twenty-four years that we’ve been in business. But in some ways it’s outdated. Not outdated because it’s wrong. But outdated because it’s not revolutionary. When you hear that statement today, you say yeah, of course, what else is new. PC’s are in sixty percent of U.S. homes already. The prices are coming down to a point where increased penetration is very, very easy to predict.

But Microsoft is a change agent. We’re not just about taking the software we’ve done and making it a little bit better. We’re about changing the platform. Taking the kind of risks we took when we bet the company on graphical interface or bet on a Windows NT. We’re embarking now as big a bet, or I would say, a bigger bet than any of those. It’s captured in this new vision statement. Empower people through great Microsoft, internally we say Microsoft, externally we just leave that as implicit thought, great Microsoft software, any time, any place and on any device.

Now when some people in the company heard that they thought is that all really that much different? Is it something completely new? And just in the last month, Steve and I with a lot of help, from other people, have come up with a way of taking this vision and explaining what it means to our software in a way that is quite revolutionary. And that is by saying that from 1975 to 1998 the whole vision centered around the PC. It said the PC is getting more powerful, there is more and more things people are doing with it, just get the applications on to that PC and we’ll continue to lead.

Well, now we’re saying that although the PC will continue to be important that it’s actually the capabilities that are delivered through the internet, the services across the Internet that people will be thinking about.. They won’t be thinking about managing their files on an individual machine. They’ll want all their information stored in the network in such ways that any device that they pick up, a PC, a phone, a TV, a small screen device, they have access to the information they care about. That takes storage of file system that was purely PC-centric and makes it much more internet-centric.

This was classic Bill. There was a bold statement. An assumption that the company was willing to take on huge risk. Embracing the success while saying we could do much better. Then pivoting to a very specific technical scenario, and no surprise it was data storage. He did this exact pivot when celebrating the Office XP launch with the team—great job, now about unified storage. There were demonstrations of web scalability on Windows, the new collaboration features in Exchange (including the Web Store discussed in previous sections). In something unusual for Bill, he ended his keynote by going through the newly created Microsoft Values, talking to Innovation, The Customer, Partners, Integrity, Diversity, Community, Entrepreneurial Culture, and People. A memo was authored describing these values, distributed to the company, and leaked to the local press (who often hung outside the Kingdome listening to the meeting anyway).

These ideas did not spring up for the meeting. A couple of years earlier Bill wrote a memo where the concept of a WinTone was put forth—something akin to a dial tone where your computer was always connected to a Microsoft server (actually called a MegaServer in the memo) where files would be stored and where PC updates could be distributed. Technically this sounded a good deal like a typical Unix workstation and was similar to ideas being espoused by Sun and NeXT.  By the time the Company meeting rolled around, these ideas had been much discussed and the Orwellian nature of them toned down. It is interesting to note that these perceptions would change dramatically, and the same ideas introduced today are not only typical, but expected.

SteveB came next. Going from Bill’s almost monotone delivery to Steve’s energy filled enthusiasm was always fun. Steve’s keynote was titled “The Power to Be Strong: The Wisdom To Be Wise”. Where Bill was describing what we should aspire to, Steve was providing the emotional call to action, the aircover to go and act on what Bill said, while also taking us through the detailed business reasoning. Steve came bounding on stage to some song that meant a lot to him that he carefully picked to get him in the perfect mood. Where Bill was measured and deliberate, diving deeply into technology, Steve pounded on “services”. He said the word almost 200 times in the keynote. The key slide was “Reinventing Microsoft: Software As A Service”. Like Bill he started off describing our success, though Steve was even more hardcore from a business perspective:

As Bill said, the PC is not new to the revolution anymore.  People wanted to know in some senses, what is it?  The PC has been it for us for twenty-five years, and we have exploited it, and we have built it, and we have designed it and we did it better than any company in the history of the world! One vision, one technology model, one revenue model, one partner model, and we just went, and we went, and we went, and we went after it!  And you know what?  Here is the good news, it’s still got some mileage left in it!  And I like that a lot.  But it doesn’t have as much mileage to come, perhaps as the mileage it has brought to us in the past.  And so when we talked about a new vision, people kept asking --but what is the new it?--  The PC has been it, and the PC will remain it, but what’s the new it?

I don’t really think people expected that at all. Here we were on top of the world and Steve was telling everyone the party was over. This was Steve and he was going to take us on the emotional journey and was working towards showing us all the opportunity that was ahead. Steve pitched the company on the why of both services and PCs (an echo to “software and services” that would follow). He explained that Applications Service Providers (ASPs) were the new developers to focus on. Then using the model, he was most comfortable with, he went through each Microsoft customer segment—enterprise, small business, consumer—and described the value proposition and how we would approach the opportunity. Who are the competitors and how would Microsoft compete? Steve had a list and made sure even in the face of regulation challenges, it was OK to compete vigorously. He even had a pro-forma P&L describing the way revenue would transition to services. Like Bill, Steve also concluded emphasizing the new company values.

It was a remarkable presentation and strategy. The presentation and details were the first draft what would become the months of meetings for the Next Generation Windows Services (NGWS) task force and presaged the Forum 2000 strategy day the following June. The 2000 wave of products (Windows, Office, Exchange, SharePoint, and many more) were announced at COMDEX just two months after the company meeting to over 340,000 people and created the product foundation for the company that would carry us forward as Steve described. These new products—the foundation of Microsoft for a decade—were positioned as old news before they even shipped. I loved it.

Unlike the internet strategy, especially the Internet Tidal Wave memo, this services strategy was ahead of the market. Microsoft was leading and no big company was heading there yet. It was, at best, a Silicon Valley startup strategy. When it came to services, Microsoft was incredibly early. Were we too early?

Windows and Office both created the XP products over the next 18-24 months while theoretically the new services infrastructure was built up. That wasn’t quite the plan, as really both teams were polishing/finishing the 2000 wave, but it worked out that way. There would be an absolute ton of meetings about Services over the next two years. The big project being worked on was Hailstorm, also known as .NET MyServices. The services topic and getting more done and sooner was top of mind.

In Office we had already spent a couple of years on SharePoint and FrontPage and were more than convinced that services were the future for us—so many of the scenarios described by Bill and Steve were easily enabled by using a browser, HTML, and a web server. It was abundantly clear that any remnants of the old way of working were in the rear-view mirror (file servers, “net use” to share files, directly connecting to databases from Win32 apps, having all your files on one PC, even obscure features like roaming settings and customizations were better suited to a web way of thinking).

We had many difficult balancing acts in front of us such as how much could work in a browser (very little in 2001) or who would buy services from us (we had no idea) or how much would a service cost (would it cost more or less than a box of Office). We had been talking for the whole of the XP product cycle about a mythical product “FrontPage.NET” (every next version product or code name had a .NET suffix by summer 2000) which would be an app-less app. Simply go to a web site and sign in and start creating a new web site. We’d seen self-service collaboration sites take off with SharePoint Team Services. I compiled a list of a dozen or more competitors who were making browser-based products for sharing and collaboration. No one was really doing anything significant for document creation, yet. Outlook was achieving a huge level of interest in the browser version being done by the Exchange team (so much we’d move that team to Office to better align Outlook in the browser and Outlook on the desktop). We were ready for services.

In the spring of 2001 after Office XP released with the rise of the new .NET developer platform inside of Microsoft, Office shifted its gears to deliver what BillG referred to in an earlier memo, Office as a Service. Customers loved the idea of infinite clip art, endless templates, ever-expanding online help, even sending Microsoft bug reports. We had so many more ideas.

As Steve and Bill set the stage to transform the company, it was my turn to transform the Office team. We had almost 2000 people on the Office team. That’s a huge management challenge, even with the air cover from the company meeting two years earlier. There’s only so much a few hours in a stadium can do. My job was where the strategy and words needed to start turning into code and product.

To get there as a team, we needed to scale our planning process. Our mantra for planning had become “the best of top-down, bottom-up, and middle-out”, but in truth we were far more tilted in the direction of middle-out, meaning gaining alignment across the various app and shared teams, and bottom-up where everyone contributed to feature ideation and prioritization. The top-down planning we did was around resource allocation and the big shifts to the suite and enterprise. The transition we’re talking about here needed a much more prescriptive top-down effort. Somehow, I needed to find a way to do so without being rejected out of hand or worse being called “too much like Windows”. Finding an enhanced way of planning that allowed for more senior management coordination and, yes, control, was hugely stressful.

I settled on a process of memos over a course of months that would lead to increasingly detailed priorities and ultimately an organization (aka a re-org) to execute on the plan. Along the way there would be countless 1:1s, skip-level 1:1s, group meeting presentations and Q&A, email threads, and hallway chats. Drafts were shared. Changes were made. The idea was that even the top-down was a product of bottom-up and middle-out. I admit that is an idealized view and some would disagree, but the goal and the work put in was intended to do that. At the very least we were running a version 1.0 process.

The process would take a bit more than 12 months from the first memo to the team meeting rolling out the vision (the plan), starting well before the current release even shipped. That seems like an insufferably long time in today’s environment. Aside from the obvious notion of “boxed” software versus an ever-changing service, there was a crucial difference with today. Office was a single product, with a single strategy, which would all be made available on the same day, spanning the work of some 2000 people each of whom would deliver their contribution on that day, complete and working. There are many enormous, far bigger, projects today, but they are rarely delivered in this manner. Even today Office itself no longer delivers products this way. Today, a single new feature in Office might roll out over the course of a year even in one module, and the same feature might come later in another part of Office (for example, dark mode). It isn’t just that the feature is released before it is done, but even after it is done there is a long tail of delivery.

In April 2000, 11 months before Office XP shipped, I sent out the first memo in the series, Next Generation Office, or NGO. Essentially on the heels of the Company Meeting and just before Forum 2000, I wanted to offer the Office analog to NGWS. The fact that this was just after the dot com bubble was important context. While the stock dropped precipitously, it was nothing compared to most of the tech world. The introduction set the stage for a big change:

Office is at a crossroads—we are on the brink of shocking changes in the technology priorities of our customers and are facing a substantial disconnect between our product and what customers want. For two releases customers have been telling us that they don’t have the need for upgrades and can’t imagine what else is left to do with Office. At the same time we have continued to innovate roughly along the same path started back in 1992 with Office 4.x—improving the basic document process. As we close upon the development of Office10, the signs are upon us that we are truly at the end of one era and at the start of another, and if we don’t act deliberately and precisely we run the very real risk of missing the transition. We have accomplished amazing things with Office, especially Office10. Over the years we have developed a product that is in daily use by perhaps 200 million people and each one of those customers gets tremendous value from our work.

It went on to describe what I called “The Big Bet” which was about developing an “internet user experience” for Office:

The Next Generation of Office is not just an incremental addition to our “client-side” code, nor is it about developing stand alone server applications, or isolated “free services” [This is a vague but pointed reference to the dot-com crash and all the companies doing free software and planning on making it up in volume]. The Next Generation of Office is about creating a compelling Internet User Experience built on top of the Next Generation Windows Services (NGWS, an early document from SteveB). NGO is a product that is the seamless integration of our client, our server software, and our services. When we speak of “Office as a service” we mean that Office is the combination of a Windows application (like the world knows and loves) plus a wide variety of hosted services (extrapolate from Office Update) plus a range of significant server software (such as OWS or mail boxes). Although we might also include some element of support or custom engineering, “consulting”, or other people-based services, our bet does not explicitly require that—we are a software company through and through. We will fail if we do not deliver on that powerful combination.

The memo paints a complete picture of the many challenges Office 2000 faced in the market. I referred to this as the innovation disconnect. The perceived cost to deploying, training, absorbing new features continued to rise, while the perceived value of those features declined. In other words, we were digging a deeper and deeper hole for ourselves by simply doing what we were doing by adding features. The bottom-line on this observation was a dramatic number I placed on what were termed traditional innovation, or features in the desktop apps, which was only 20% would go to “guarding the core enterprise agreement”. Such a statement proved to be enormously controversial with our team and as the marketing team (at the time they reported to me!) As we’ll see the controversy did not end there.

As I came to learn, in a big company (and especially Microsoft) when people read memos from executives there’s an ever-present expectation of a reorg. In Office our re-orgs had become routine and predictable. After a release we’d realign resources, shuffle the shared feature teams in Office proper, and make sure everyone had a chance to do something new or sit tight. It wasn’t stress-free, but it wasn’t a scary free for all. In reading NGO, many suspected a much bigger change. There was not. Instead, what we really needed was to create a whole new type of job. Our historic reliance of the magical trio of dev, test, and pm (software design engineering, software design in test, and program management) could not account for the important role of operations (the contemporary title of devops was a decade away). Part of writing this memo was to have guest speakers come to group manager meetings and to share industry practices from some of the hot startups. For example, Tim Brady, the first non-founding employee at Yahoo spoke about prioritization, keeping services running, and the like (I met him at a Harvard Business School event when I was there on sabbatical teaching). In many ways the biggest change in NGO would be creating not only an operations team, but an operations mindset.

The real purpose of NGO was not to provide answers to what the product was, but to tee up the questions or to frame how the release should look. In the next iteration we’d call the memo at this stage the framing memo, because it framed the release. It wasn’t nearly as prescriptive as BillG would have written because it was more of a management tool than a bulleted list of features that he tended to favor. In that sense, sending these memos up the chain was often frustrating for the recipients and a bunch of work for me. I had to learn how to use the memo to gather their feedback on the framing, not features.

Over the next months there would be any number of offsites and discussions about what should come next. Teams were using many new startup products out on the market, reading a great deal, and learning new technologies (like .NET). This enabled the next turn of the crank and many more specifics. Rather than putting forth a framing, the next memo said at a high level what we would build. It was still not features, but themes. I called it Creating Office.NET: Next Steps in Creating a Vision for Productivity. It was clear that the vision, the actual plan would follow, and this was not the plan. The goal, however, was to be something of a rough draft of the vision. The team would begin to fill in the details and thus own the actual plan. Again, this is solving for the lack of accountability that comes from simply telling people what to do. Plus, I had no idea what every feature should or could be.

This memo is about creating the next generation of Office.  Not a vision statement, this memo outlines the business situation and the clear direction we are taking the Office product, and the bets we are making (a vision statement will follow soon).  This memo is also about creating a new product—one that takes the enormous success of Office and melds it with new functionality and new technologies to create an exciting new product.  We will call this product Office.NET.  Office.NET is the essential set of tools and services that empower individuals to get their work done with a personal computer.

Without saying what the product did, the memo defined what success looked like. Again, this was either empowering or frustrating depending on the mindset of the reader. It is easy to lose sight of the work going on to change mindsets, not just accounting for what features to do. Office had almost no developers working on .NET, HTML, XML, and other new technologies. The memo continued:

• Customers move beyond the view that Office is “just” a word processor, spreadsheet, email client, graphics, web authoring, and database. Office.NET adds whole new services and applications to the toolset that we build and sell as Office.  Think of the service and services elements of Office.NET as “puzzle pieces.” When we release Office.NET people will use our product to get work done in new ways that they might not have thought of and certainly did not think of using Office.  Office.NET is not “Office 11.”• Customers not only use our new suite of hosted services but customers come to rely on Office.NET services as a critical element of getting their work done.  Office.NET services are not about gimmicks or “dumb PC/internet tricks” but about being simple, elegant, and useful additions to getting work done.  For customers, Office.NET is about saving hours, not mere seconds.• The glue that holds Office.NET together is integration and integration is what makes the value of our product greater than the sum of the pieces.  Customers using Office.NET see an unprecedented integration between their tasks—whether those tasks are Office.NET services, desktop productivity tasks, browser-based services, third-party services affiliated with Office.NET, or Microsoft’s own MSN services.  Integration is the key that allows a customer to solve real-life problems, such as sharing a document with a partner outside the firewall or merging a work calendar and a private calendar.  Many would say that one beauty of the internet is the elegance at which a large number of valuable tools interoperate saving time and effort—we will bring that elegance to Office.NET’s services.• Office.NET provides a new level of “customer service” by keeping the software updated, enriched, and “running” for customers.  No longer will customers feel like they are “cut off” from Microsoft after they buy the product or feel like they have to wait a year for a 30MB patch to fix things.  Of course, Office.NET doesn’t change this from the first day a customer gets the product, but we will over time build up the service relationship.  Customers no longer view buying Office as a one-time transaction, but rather customers subscribe to Office.NET because Microsoft is making a commitment to back our software and services with the highest level of support possible.• Customers who use Office.NET can do so with full faith and confidence that Office.NET provides a safe, secure, private, and reliable service. We will go to extremes to insure that customers can trust their important work to the tools and services offered by Microsoft. Everyday one hundred million people trust their work to Office, so we’re in a good position to extend this trust to a new level of support. This will not come easy, but we will make it so by making it the highest priority in everything we do.• Office.NET is good for business.  The great American philosopher, Steve Martin, once had a moment of enlightenment when he realized “it’s a profit game.”[OMG this should be “profit deal”  a mistake 20 years old.] For most of the history of Office, it has been more than good enough to maintain a clear focus on improving our engineering and building products that more often than not continued along the path of incremental improvement and that led to an amazing business. Office.NET is about building a new product and selling this product in new ways.  We are making these choices because everything we know says that they will be good for business—just as we thought building Windows applications was going to be good for business. We will run a service business with the same focus on efficiency and cost that we have had in building our packaged product business.

The text is rather self-explanatory today. It reads like common sense. At the time, each one of these points had controversies. Even the mundane such as providing software updates was broadly unacceptable to enterprise customers that wanted full control over what changed and when (and they still do). While writing the memo and talking (and talking) I could sense an increasing level of excitement. Bringing the excitement of the rise of the internet home to what we work on and how we work in Office was motivating. To put things in the era, many people were just starting to order books from Amazon and track stock quotes and news on Yahoo, though we were still 5 years from the rise of Cyber Monday.

Important to this memo was setting a bounding box around some important project attributes. This is the pure top-down aspect of the plan. This included setting time frames for the release, the number of milestones, system requirements, and more. The real deliverable (as with the operations team from the previous memo) are a set of carefully worded and coordinated “Focus Areas” which would be used by program management. These will anchor the process of feature ideation, prototypes, and scenarios. The memo outlined the following planning focus areas. These came with brief descriptions to answer the why, but were designed to ask the question how, not define the specifics of what we would do:

• Accessing My Information from Anywhere, Any Time • Creating a Personalized Office Experience• Building Effective Communities and Teams• Growing New Opportunities for Office• A Note About “Traditional” Features

The framing memo went out to the team in October 2000, about 5 months before most everyone was done with Office XP. A few weeks after that, the third memo in the series went out which was the adjustments to the organization. I like to remember this as relatively uneventful, though no org changes ever are for anyone who gets a new manager. In fact, the team had gotten so good at this re-shuffling after the release that it became somewhat of a game to go from the framing memo to the new org—clever people could guess the new shared teams or realignments that would happen from the way the focus areas were lined up and how the ideation progressed.

Program management created working teams based on these themes, and smaller groups based on specific scenarios. The features would emerge from these efforts—this is the bottom-up and middle-out planning work. PM led by HeikkiK drove this process, working across teams. If there is one magical step in all of Office, it was this particular part of our elaborate process that I came to value the most—we came to call it participatory design. It wasn’t just that features and scenarios seemed to emerge as if by magic, but the scale and alignment that came with those features. Anyone can (and did) have great lists of features they planned on doing. In Office when we published a list or specifications, we viewed them as team commitments. Heikki was coordinating a couple hundred PMs, designers, product planners, who in turn were partnering with developers to make sure that what was being talked about could get built. Everyone above mostly just watched. I’m not exaggerating. I will learn just how special this process was when I try to import it to Windows in a few years.

By May 2001 we had a full product vision—a product plan—for Office.NET. This whole time I had been sending the memos and talking with BillG and SteveB. In the middle of this process the executive VP leading Office changed from BobMu to JeffR and I walked through this process and all these memos with him. I realize now that must have been like sitting down and trying to untangle the true meaning behind the sales Mid-Year Review (MYR) process in a few meetings and by looking at 100 country and segment-specific slide decks. This oversight on my part will reveal itself shortly.

The pillars of Office.NET included:

* My Office

* Team And Corporate Productivity

* Keeping in Touch

* No-Brainer Upgrade

* Unlocking Information via XML

Phew. We were getting close.

A side note on the process described above is warranted. In talking about what we did I have always struggled to express the iterative nature of the ongoing work. Almost universally, the process is viewed through the artifacts (the memos) and that has the unintended effect of making the whole of the process seem like a traditional, and loathed, waterfall (as described in Chapter VII). When the process is illustrated in PowerPoint, I tended to use a lot of arrows to show off the constant state of iteration. The memos are not the work, they summarize the work. The work is best thought of as the communication, alignment, and learning constantly taking place.

The other concern often expressed by taking an artifact view is that there is so much planning time, or even dead time while people wait for the plans. In reality, the process came about to avoid any dead time at all. Many in PM are able to peel off while dev and test are finishing the product (in the above case a year before). From the end of Office XP until the vision is in place was only two months, and two more months until coding the project started. During even that four months, the engineering tooling is updated, the codebase is cleaned up (the removal of so-called technical debt), and because of Watson we initiated a mini-milestone devoted to addressing top issues. The waterfall versus agile debate would follow me around for many years, an irony for sure given the ability for the Office team to promise and deliver, compared to so much overpromising going on. I even created a slide that attempted to convey the iterative natures of the process and what we felt was unique. I used this slide for many years.

After a decade of offsites and memos about subscriptions and annuity, we finally worked our way to a product that could truly be offered as a subscription. Quoting from our vision, “Office.NET is a software service consisting of the best combination of software and services that provides a personal experience in creating, communicating and collaborating anywhere and anytime.”

The learning from the Office XP services emboldened us to embark on plans to host a broad set of productivity capabilities on the internet. We assumed if the MSN team could do it, then we could as well. We set out to define a new role on the team, on par with development, testing, program management, and design, called operations and led by Arthur de Haan (ArthurdH) as described months earlier in the original NGO memo. Arthur was leading the testing of enterprise cost of ownership shared team in Office and was one of Office’s most senior test leaders with many years on Excel previously and international. He brought with him a calm demeanor and the attention to detail required to grow a new job function for Office. He was eager to learn and the mental model of testing and operations were, we believed, a great match. We were all learning.

SharePoint Team Services anchored Office.NET. Every subscriber to Office received his or her own team site, much the same way IT enabled a self-service setup to create new sites on demand in our enterprise product (for a new project or something). We called this site My Office. From My Office, a subscriber received the features of SharePoint (a place to store documents, calendars, surveys, to-do lists, and more), all accessible from any web browser. In addition, subscribers could download Office (Word, Excel, and PowerPoint) and “activate” it with their subscription. Hotmail offered email. Imagine how cool it would be if files were stored in a website, available from any PC with a browser (if Office was needed it could be installed). In 2002, when we were dreaming this up, it was entirely workable but seemed like science fiction to customers.

We thought we were on top of these new challenges for the business and customers. We were naïve.

The first and marquee pillar of the vision was My Office, a home page for every Office customer available in a browser integrated all the information relevant to their Office experience (documents, mail, calendar, SharePoint lists, and more). From the start the intent was to support analogous features for enterprise customers installing and managing their own Windows Servers. Today we would say this is having both cloud and on-premises offerings. IT could set up SharePoint servers, could distribute Office via browsers, and, in addition, have much improved email with major improvements planned for Outlook. My Office was a gateway to all the communication and collaboration features in the product. The adoption of hosted services by enterprise customers was so early as to not even be in consideration yet.

The plan was great. We were days away from our all-hands vision meeting that HeikkiK owned. We created the vision document (all posted online), a one-page summary everyone received at the meeting, a mock press release, and design built elaborate full-motion demo scenarios to illustrate each of the main themes.

Throughout the process, I sent drafts of the documents and status updates to JeffR, BillG and others. I met 1:1, requested feedback, sent mail, and so on. JeffR told me that it was critical that we schedule a review meeting to again go through the vision with SteveB. This made me uncomfortable because I had already learned the difficulty of reviewing an entire product plan in one meeting. I watched Windows fail at this many times going all the way back to working for BillG as technical assistant. This was nothing like reviewing the goals of an entire subsidiary in 8 hours. It would be more like reviewing every account manager’s plan for their accounts and how it mapped to the subsidiary marketing plans and then to those goals—in 2 hours. Navigating a meeting of this scope—the work of 2000 people on a creative endeavor with a ton of unknowns that would be resolved over the next 18-24 months was, at least in my view, impossible.

While we were incredibly comfortable with our plan and the team was marching almost on autopilot, I wildly misunderstood my job description and accountability. We were planning this product since long before RTM of Office XP, with the elaborate process of memos and public milestones I discussed with JeffR 1:1. Reviewing a whole vision in one meeting at the end is an impossible task—the document was a work product of the team with nothing surprising by the time we rolled it out. Any changes this late, however, would be a surprise to the team. The empowerment that came with our participatory design process meant that management was not allowed to spring things on the team. Any big changes that the team did not participate in would be, um, poorly received.

Jeff and I took the shuttle over to SteveB’s office, the other big office next to BillG. Once the discussion got underway, I quickly realized this was not a casual check-in.

I began to run through the vision slide deck and the demos—the materials that would be used at the team meeting in just a few weeks. The first demo was My Office. There was enormous tension in the room. All I heard was, “We can’t do this product. . .it will put us out of business.” The rest of the meeting remains a cloudy memory.

I was perplexed. This was not simply a feature, but it was the core of Office.NET delivering Office as a service, as planned and described for months. It was just what both Bill and Steve described at the Company Meeting over 18 months ago. Our capabilities were not being doubted, rather it was the strategy. Was it a statement about subscriptions? Or was it a bet against SharePoint services? Did we not even want to do an internet user experience?

It was clear that a collective mind was made up, and perhaps had been long ago. The idea of offering internet-dependent Office was deemed simply too big a risk to the enterprise business. Essentially, they were concerned about what might happen if an individual started using this and then it was appealing to enterprises but not sold or supported by our enterprise sales force. It could even undermine Enterprise Agreement growth. It could cause customers to question the role of enterprise servers and cause troubles for the new and fast-growing Windows 2000 business.

I tried to craft answers explaining how I was certain that enterprises were not ready for this sort of service, and that our sales and marketing effort was aimed at small businesses and individuals—a long underserved market. The idea of internet hosting SharePoint offering downloadable Office was exactly what we had communicated earlier as a long-term goal for what was branded bCentral (an internet product for small businesses that included among other things email and communication), only adding productivity tools, Office code, and data center that could deliver that—done by the Office team as a core business bet, not a separate offering off to the side attempting to build new capabilities around Office rather than into it.

Could this moment have been avoided? I don’t think so. In hindsight, SteveB and JeffR were both focused on the enterprise sales motion—big accounts needing to close deals, enterprise thought leaders from Gartner, and most of all the field leaders. By their accounts, Office needed more “enterprise value” not what the IT industry had dubbed consumer services on the internet. And Office needed to reduce bloat. There was great love for the XML features, so more of that.

Should they have raised these points sooner? I incorrectly gauged their need to have more in person discussions. Their expectation from the field was that the process of planning and getting approval was a series of meetings. My expectations were based on writing (“writing is thinking”), and I found it ineffective to use a process that tried to agree on vast plans of thousands of people in person, with uneven engagement and unpredictable focus. My history, and that of BillG and MikeMap, was writing and communicating with strategy documents, detailed status reports, and transparency of process. But that wasn’t the field’s preferred method of engagement.

I failed to understand how much I was supposed to be managing up. This was my fault entirely.

At scale, a field organization is a much more top-down and prescriptive process than a product team. While a product team needs to scale execution (shipping quality code on time), defining what code to write is a different type of creativity than account planning or sales resource allocation. Field organizations tend to scale with HQ-centric strategy and planning teams that are there to work directly with executives—generally a clear separation between strategy and execution. Development organizations generally avoid distinct roles—those planning the strategy also execute it. As a result, there was a lot less bandwidth and interaction with management. We designed that into our organization, and it was appreciated.

In my case, it meant that I left a big gap in the way I managed the strategy up the organization, especially considering what they were used to.

As the meeting went on, I answered the concerns expressed, but I had mishandled the process. We would address bloat by not adding a bunch of features and keeping the core products the same. In other words, I unintentionally pointed out there would not be many new features in the core apps, except for enterprise capabilities (such as using the new-fangled XML technology). We intended to expand the value of Office with entirely new modules, one for pen and tablets and one for business processing and forms (a deeply enterprise scenario). The enterprise product was a superset of the Office.NET style product that would be deployed and operated by IT.

To be clear, I had said the enterprise product was the product. We were not selling a subscription, but we endeavored to beef up the free services offered with Office. I said the right words about the right priorities, and it was made clear that there was no subscription for Office that competed in the enterprise. But discussing that was not in the cards. Never had a product feature or strategy received a straight verboten before, so I left the meeting saying I was on top of it.

The vision for “Office.NET” reads well even today. In hindsight I should have seen this as a lesson in moving too soon or being early in May 2001.

Office.NET represents a major new vision for Office: integrating web services with the rich client to deliver unprecedented value to our customers. Office.NET also represents a major shift in how the product team approaches the Office product development cycle. Office.NET is not “the next version of Office.” It is an entirely new focus for Office where we will start fresh and extend our software into new and unexplored areas—software services. Office.NET will introduce a new business model, integrate with other strategic Microsoft technologies, and make much of the company-wide .NET vision real.

As of this writing, I still find the time the most puzzling few days in my career. I was too worried about the team and my constant fear of unraveling (as the Windows team was doing) to spend any effort on figuring out if there was a gap in understanding. I viewed this as an edict from above and executed as such.

I came back to the office and discussed these changes with Heikki. My state of mind was such that I did an exceptionally poor job of explaining what transpired. He was as puzzled as I was.

Since everything was essentially baked, we changed the body language of what we were doing. Where once again we started by planning the release not building the next Office, we ended up feeling incremental again. The step-function changes in the product—a subscription and internet offering—were scaled back, and our focus was back on IT and strategic enterprise value, to the exclusion of other work. Most everything we planned on doing as a hosted service we kept on doing, only as a server product using SharePoint. We would have many services as part of the core experience of the product (as previously described, such as templates, assistance materials, bug reporting, updates) and we would develop many new services along the way that would get us ready for a future.

For now, the snazzy sign up for a subscription with a credit card service was going to be the job of the bCentral team creating services exclusively on small business customers. Ironically this team, and its descendants, would spend the next 10 or more years working to scale SharePoint, Exchange, and various telephony products to work first in Microsoft hosted servers (essentially as an application service provider) first in a product called EHS, Exchange Hosted Services offering security and reliability services for a customer’s Exchange servers, and then a suite called BPOS, Business Productivity Online Service. By the end of 2008 there were about 500,000 mailboxes protected by EHS, with some big names driving a large set of those. Then by 2010 there were about 1,000 paying companies on BPOS with 2 million mailboxes (again, highly concentrated).

Therein lie the roots of today’s Office 365 offering Exchange and SharePoint services. The browser-based implementations of the Office apps would come with the next full release of Office.

Hindsight is super clear for this issue. The timeframe for enterprise customers to be ready for Office.NET was not early 2000’s. It would not even be 2010 or even 2015. Running essentially the same enterprise products but on Microsoft servers, the cloud as we call it today, would have in fact been insane in 2000. The killer application for the enterprise cloud was…simply scaling and running Exchange email for large customers. The product had become so complex and yet so mission critical that essentially only Microsoft could effectively operate it. It would take about a decade to build a product that customers would even begin to evaluate.

But in 2001 sitting in SteveB’s office, the enterprise was in no way ready for the cloud model—not even close. In fact they were uniformly against the model. That’s how early we were. Would it have put us out of business? Probably not as most customers would have ignored the offering and thought we were crazy. That’s how most felt even after 2010, and BPOS was essentially running dedicated servers for each customer. Steve was right, however, in that it would have been confusing to customers just as BPOS was in 2010.

The immediately visible change was that we re-codenamed the project Office11 instead of Office.NET. For the moment, at least the corporate branding people were relieved. We presented the vision, only finessing the idea that the design sketches needed to be representative of an enterprise aesthetic.

Office.NET as an internet experience for consumers was essentially dead.

Personally, this was a really tough few weeks in early 2001. Around the same time, Steve was pondering making changes to the Windows CE/Mobile group. He spoke to a lot of people as he always did. Among those, he spoke to me and two other good friends that were also “product leaders”. We also spoke to each other, that’s how we know we all had basically the same input on what to do. We were getting killed by the new Blackberry and our phones were nowhere near credible even though we’d been at it for almost 10 years. Unknowingly, we all said the same thing to Steve—we need to build our own phone and completely reset the operating system for that hardware. That was not the answer the company wanted then as we were totally committed to building out phones as we did the PC ecosystem. That meant no first party hardware and a software-only business selling the operating system to many phone makers. That also meant none of us would have been welcome additions to the team.

As a postmortem, I met up with one of my friends for dinner to talk about the situation and the state of the products, especially the phone situation we found ourselves in the middle of. I managed to inhale an entire slice of Metropolitan Grill 9-layer chocolate cake. Yeah, I was in a bad spot. I managed to inhale an entire slice of Metropolitan Grill 9-layer chocolate cake. Yeah, I was in a bad spot.

A few years earlier I had a wonderful and enriching sabbatical teaching on the east coast. I gave a lot of thought to the idea of switching gears. It didn’t get to the point of discussing it. I’m glad I kept quiet, but that didn’t make it any easier.

We had a slightly different product to build.

On to 071. Resolving NetDocs v. Office

Welcome to Chapter X!

The turn of a new century and survival of “Y2K” begins a massive expansion of the Office product line, a dramatic change in the products we built, and a reinvention of how we market Office, while simultaneously tripling and quadrupling down on enterprise customers. The result of this transformation sets the stage for the most formative years culturally for the Microsoft that takes us to today’s products (365, Azure), but unknowingly constrained us going forward.

Back to 068. The XP eXPerience

One early company meeting as the CFO Mike Brown (MikeBro) was going over the numbers he had a chart of the Fortune 500 showing that Microsoft finally made it into the rankings. He showed the top 5 companies or so, which dwarfed Microsoft then just barely in the top half. Sitting next to my first Microsoft friend KirkG, I recall asking him if he thought there would ever be a software company the size of AT&T or General Motors. His answer, “hell yes.”

Though Microsoft was number 84 by sales, it had achieved the unimaginable as the largest company by market capitalization. Thinking about that even today is still difficult to fathom—bigger than the oil companies, bigger than the entire auto industry, bigger than the phone company. It was obviously more than humbling. It was terrifying.

There was, nevertheless, a swagger across the company. Sure, the trial and settlement were still going on but the worst seemed over. There was such an incredible wave of success from the new enterprise business, both the licensing of enterprise agreements and the product offerings on the Windows/Office 2000 platform, along with Exchange and several other key products. For product people these were the magical product releases. There were “investments” as SteveB called them across every imaginable product category. The combination of Microsoft pivoting to internet technologies, the dot com crash, and simply winning against competitors is what I believe really caused a change in how we thought about ourselves, by rising to the moment and vanquishing competitors: Netscape, Sun, and Novel on servers, Apple on desktops, Borland on tools, Lotus on email, and so many other smaller companies. We saw success in everything we were doing. It became difficult even to find competitive products to get the team sincerely fired up. The biggest competitor was no one company but alliances such as anyone using Java or open source, but these were diffused and fragmented battles. Microsoft’s oxygen came from competing and winning and we’d sucked all the oxygen out of the market by winning so soundly. The market capitalization was a realization of that.

It would be a mistake to think success would not change how we built products. When you chase a competitor, even if you’ve got better ideas for how to express, implement, or sell a product as we did for Excel versus 1-2-3, the idea for the product in the first place came from the competitor. Microsoft didn’t invent from whole cloth many products. Most every product has a lineage of some form, so this is never an entirely fair way to judge. Most every successful product could be traced to a direct competitor with scale. On the other hand, many of our biggest failures were products that lacked a competitor where we would often get lost on a meandering journey trying to figure out what to even build. The Blackbird internet authoring tool previously described was a good example of this.

We had competitors of course, and some were spectacularly good. Oracle would forever remain the top SQL database company. Linux and open source were clearly a huge issue, but as should have been anticipated they would not win head-to-head but would only win when a paradigm shift—cloud and mobile—enabled them to flourish in business software. SAP and the whole space of software that ran the back office of enterprise and CRM software escaped us even with their deep connections to Office and email.

Increasingly Microsoft’s strategies became so daunting and all-encompassing it was nearly impossible to imagine a single competitor that could offer anything close to our strategy slides, and equally impossible for any single person to track. We were in a constant state of tuning the message and product line. Platforms lurched from Distributed interNet Architecture (DNA), to Next Generation Windows Services (NGWS), to .NET to .NET MyServices (aka Hailstorm), with stops along the way such as putting “+” on the name of every new endeavor, for example COM+, or adding XML to expand an existing strategy. At each iteration, everything was rebranded, expanded, and re-factored. An area like accessing data stored in a database cycled through acronyms representing increased capability and complexity, and varying compatibility and tools support: ODBC, OLEDB, DAO, ADO, ADO.NET, RDO, and more. The complexity of naming was only matched by the increasing complexity of software. The original Windows 3.0 APIs numbering about 350 had expanded to a literally uncountable breadth of platform services. No single developer could comprehend this. Definitely no one in Office and we began to feel distant from the very platform strategy we depended upon. Office had historically been the source of killer apps for platform strategies, but now the platform team looked to the biggest consumer web sites and largest commercial web applications as the desktop and client were deprioritized.

The evolution of the much beloved Visual Basic provided a lesson in this divergence. Office had just managed to add VB to all the products with solid performance, a major cross-company success. VB was in the process of being updated, really replaced, by a newly rearchitected product called Visual Basic .NET or VB.NET, which gained synergy with the .NET strategy and new iteration of the language for use on servers. This product was so different from the classic and wildly popular Visual Basic that one of Microsoft’s own and much-loved MVPs (the leaders in the community carefully selected to offer the best knowledge and support for products) dubbed the new product Visual Fred in an infamous blog post that rallied the community but divided it from Microsoft. Other posts began to meticulously track the differences in the new product and the time and effort required to migrate existing projects.

Office could not possibly retrofit this incompatible tool into the product—customers would have lost their minds as we had just completed migrating from the legacy programming languages—leaving the carefully crafted cross-group collaboration in somewhat of a Cold War. The VB team’s best response to the trade press asking about VB.NET was that we had “some difficult choices to make, as it's tough to move from the PC-centric computing model to the Web-centric .Net model.”

Were we losing touch or were we trying to do bigger and better things that would naturally and unfortunately alienate our best fans? Were we growing our ability to create strategic enterprise products or were we over-reaching on what we could (or even should) deliver? Was disruptive innovation happening in real time like it should, or were we just being disruptive?

Broadly, we began the decade far more inwardly focused than ever before. An expression that was often used was “smoking our own supply” or I might have said, “Microsoft was creating our own bubble”. Everything we did was relative to everything else we did which was relative to the feedback we got from the enterprise customers we already won who were champions for anything we did. I thought often about the very first technical conference I attended which happened to be the last global DECWorld on a cruise ship in Boston in 1987. Digital Equipment Corporation, DEC, was the famed makers of the VAX and VMS operating systems I used in college. I was a new graduate student and drove to Boston for the day.

The conference felt like the most grownup event I’d ever seen—everyone was twice my age. It seemed like everyone wore a suit and all they talked about was DEC. What I recall vividly, however, was that the sessions I went to were so advanced and so deep into the specifics of DEC and never mentioned anything else—in particular, I didn’t understand how they only talked about VMS and not Ultrix (DECs Unix variant) which was what we were moving to at UMass—I went to learn about Ultrix. I realize now both how naïve I was to the idea of an industry conference, but also how much of a bubble that conference was. Not long after, DEC began a rapid decline and about 10 years later was no longer a standalone company. It was no surprise that shortly after DEC collapsed the book DEC Is Dead, Long Live DEC: The Lasting Legacy of Digital Equipment Corporation, was widely read across Microsoft. Being on top of the world in technology can be so fleeting and the descent so rapid, even if the products are loved—if only regulators could understand that point. BillG knew that. The competitive nature at the core of Microsoft existed for that reason. But what happens without a competitor? That’s how DEC acted—it built products as though there were no competitors, or more precisely that the customer saw the world only through DEC products.

A company that was on top of the world in 2000 was Sun Microsystems, but it was also starting to struggle post the dot com crash that impacted so many of their customers. There was no cloud computing, so starting a company meant buying a lot of Sun computers, but the crash stifled the creation of new companies and those purchases. Scott McNealy, the outspoken cofounder and CEO had said that people bought more Sun computers when the economy was good so they could grow and more when the economy was bad so they could be more efficient. He did not anticipate what Windows NT would do to those expensive computers though. McNealy never held back in his commentary on Microsoft. He reserved his harshest critiques for BillG or SteveB. McNealy’s rivalry with SteveB seemed a bit personal, perhaps because they attended rival private schools in the suburbs of Detroit. As Office XP was making its way to customers, McNealy unloaded on Office, taking aim at the ever-present topic of bloat when it came to, apparently, banning the use of Office at Sun.

Why did we ban it? Let me put it this way: If I want to tell my forty thousand employees to attack, the word “attack” in ASCII is forty-eight bits. As a Microsoft Word document, it’s 90,112 bits. Put that same word in a PowerPoint slide and it becomes 458,048 bits. That’s a pig through the python when you try to send it over the Net.

Nevertheless Sun continued to use Office in finance, presentations, and more. Sun was still a strong company, though that would change in due time, coincidently as their use of Office declined. McNealy held an influential position, particularly when it came to internet technologies. Like Microsoft, Linux also took its toll on Sun.

To bolster his anti-Office stance, in 1999 Sun acquired a maker of a clone of Microsoft Office, a German company, Star Division GmbH. The rumors were that it was cheaper to buy the company and attempt to standardize on its software than it was to buy Microsoft Office. Star Office was working to be fully compatible with Office and available on all platforms, especially Sun’s Java which had consistently shown that it was not up to the task.

The engineers on the product were adamant that it was a “perfect copy” of Office, copyrights, trademarks, and patents aside. At a trade show, when they were still an independent company, I saw a demonstration at their booth. I was younger then and not concerned about the ramifications of obscuring my badge and affiliation. The demonstrator said they were a member of the engineering team while describing the keen attention to cloning Microsoft Office, “even the toolbars”, they said. I pointed out some, um deficiencies. He launched Microsoft Office on their demo machine and shockingly I was correct. He summoned a coworker and after exchanging some thoughts in German told me to come back later in the day to see that they corrected the mistake. I came back and sure enough they did, and I properly introduced myself. Amazing.

With Sun’s ownership and financial support, Star moved from a low-priced product to a free and open-source product. In keeping with the apparent desire to needle SteveB as much as possible, McNealy and team created OpenOffice.org, a philanthropic-sounding consortium to support open source contributions and distributions of an Office competitor. What started off as an odd and failing strategy turned into an annoyance.

Highlighting Star Office as an alternative to Office was one way enterprise customers expressed increasing frustration with bloat. Depending on who you asked the products indeed had many flaws. What we began to consider was that we were now being evaluated on and held to an absolute scale. It was no longer enough to be better than a competitor we vanquished or a new competitor like Star. We needed to be great on our own, an absolute standard.

Despite the flaws, customers continued to buy, and continued to sign up for multiyear agreements. It was difficult to be a serious global company and not be using the full Microsoft platform for PCs, document creation, email, and enterprise infrastructure. Office and Windows were the very definition of product-market fit—we just could not lose a deal. Even in markets where software piracy was the norm, Office and Windows still won against free (and legal) alternatives. This created a disconnect that was difficult for product groups to fully grok.

Winning didn’t necessarily mean we had built the best product. Winning is a combination of product, price, place, and promotion and can come from any or all of them. At least for Word, Excel, and PowerPoint it wasn’t simply that our products were the most satisfactory sold by Microsoft, dominated industry reviews, and consistently won against competitors. Microsoft’s global sales force, product support, and complete product line were all part of a winning equation. Winning led to more winning when it came to familiarity, training, and cross-organization standards. Whatever products do win are by definition the best product.

Microsoft was a big place, and as we grew there were more and more people with ideas who were organizationally disconnected from execution. It was not difficult to find someone putting forth a proposition suggesting this or that risked ending a franchise: the browser, Java, open source, Linux, competitors using one or more of those, or customers rejecting Office due to bloat, poor quality, or complexity and cost in the enterprise. It was too easy to cast aspersions at the parts of Microsoft executing on what it takes to sell billions of dollars of software. These cross-group dynamics between the big money-making products and the new products or the groups simply incubating ideas with ample time to criticize introduced a new kind of tension in the company—one between those that were shipping and those that weren’t (yet).

In the world at large, Windows and Office were becoming listed resume skills and that enabled them to become the punchline to jokes on late night TV, sitcoms, and a constant stream of syndicated cartoons such as Dilbert. Earlier I described when late-night TV host Conan O’Brien did a funny number on Clippy. “Come on, Bill, Microsoft got off easy compared to what the government did to Clippy, that annoying icon that pops up in Word all the time.” (Followed by an animated gunshot and Clippy’s demise.)

We laughed—how could we not? Perhaps it was a rationalization to say that people always hated the tools foisted on them at work. I certainly remember how much people hated all the IBM mainframe software in use at my summer aerospace job and then the MS-DOS software used throughout Cornell. People loved the Mac, until it ate their file at midnight.

Our answer (and my answer) to all of this—the flaws, the increasing expectations, the late products, the quality issues, the jokes, and more—was to execute. Thinking back to that 1:1 when SteveB became president, ever present in my thoughts was what happens when a large development team loses focus and spins out of control. Considering how large our team had become with the addition of SharePoint, my concerns grew deeper. I had no idea just how real this concern was about to become.

As we were planning the follow-on to Office XP, the Windows team was starting to lose control after so carefully maintaining it. Windows XP shipped on August 24, 2001, within weeks of the original goal and six years after Windows 95, and then sketched out a grand vision for the next two releases. The first was code-named Longhorn after a bar in Canada between Blackcomb, which was the code name for the next release, and Whistler, the original code name for XP. Longhorn was planned to be a scaled back version of Blackcomb available sooner, which was being planned simultaneously as Windows traditionally did. Don’t worry, I couldn’t keep track either. There was so much excitement about the plans for Blackcomb that BillG kept pressing and the team was receptive to accelerating the long term work for Blackcomb into the near term Longhorn. It was typical to attempt this when planning two releases in parallel as the second release always appeared more exciting.

Nevertheless Longhorn was slated to be finished in a reasonable timeframe. Windows generally did not have specific completion dates as much as ranges though there were clear dates for early milestones. The release had a set of four strategic initiatives and grand long-term aspirations. These four initiatives were BillG’s self-declared main projects for the next 5 years (two releases) and included major advances in storage (code name WinFS), user interface platform and graphics (code name Avalon), networking (code name Indigo), and a major set of new developer APIs (code name WinFX). Longhorn would embody the biggest and broadest platform strategy ever attempted by Microsoft. I began to share copies of my favorite book on massive engineering, IBM's 360 and Early 370 Systems by Emerson Pugh, detailing the history of the biggest and most enduring computing platform ever built. Could we top that? I probably should have noted more of the history of the project that came before the 360, code-named Project Stretch, which went so poorly the project leader was ostracized within IBM (only to find redemption with the 360).

A really (really) big problem brewing was that Windows XP was struggling in the market, having received muted reviews it often proved difficult for enthusiasts to upgrade and required a significant uptick in PC hardware from OEMs. More alarming though, the virus and malware criminals and troublemakers that attacked Office moved their focus to Windows XP and Windows Server. Those products with significantly more surface area were under assault. The Windows team was scrambling to patch a relentless onslaught of bugs. There was ample consternation over the rationalization that the product was behaving as was intended while also deep concerns about breaking third-party software. If this challenge sounds familiar it is because it is exactly the situation Office was in years earlier.

Windows developed a plan to implement a fast-turnaround service pack that addressed the major holes in the product and to complete it in six to nine months. From my vantage point, having a 50 percent error rate on the estimated schedule completion of a short-term project was already a sign of a team that was not operating in control. The scope of the work, the resources, and the schedule were not aligned. The update to Windows XP was going to need more time, more people, and more work.

There was some good news in how the update progressed. Windows XP as it released was outfitted with Watson technology from Office. For the first time a Windows release was getting real-time information on crashes. The Office team continued to run the Watson service while Windows was able to isolate and fix a very large number of common crashes, as Office did while shipping Office XP.

Six months turned into twelve. Then more. More and more of the team, especially management, were being pulled into security challenges. An annoyance erupted into an existential threat to Windows. Even more importantly, the security issues threatened to prevent Microsoft’s .NET strategy from taking hold and earning product-market fit before even reaching the market. All around the world, the value proposition of only a browser and web pages with code on the server—the strategy espoused by Sun’s McNealy and Oracle’s Ellison—was looking more attractive. At stake was Microsoft’s reputation with enterprise customers.

A favorite saying in the Office hallways was that it is not enough for the leading product to drop the proverbial ball, but someone had to be there to pick it up and run with it. While there were many challenges in market with Windows XP, the real concern was that it was increasingly apparent that the network computer and browser were there to pick up the dropped ball.

There were endless debates over how far to go. I had a long email thread with a VP of Windows sharing my experience asking if “fixing” Windows was even possible? No matter how much was “broken” the architecture was fundamentally open and extensible and thus subject to ongoing assault. I had my doubts this problem was solvable based on my experience in Office. I would return to this topic in just a few years when I moved to Windows.

The definition of product-market fit ultimately prevailed—Windows was the winning product and the market could not get enough of it, even with security issues and incompatibilities. All Microsoft needed was to respond. The company needed to show it was taking the problem seriously.

Following the September 11, 2001 tragedy, Craig Mundie (CraigMu) led an effort to cement Microsoft’s response to security threats. CraigMu, from his position as chief research officer, went around the world representing Microsoft to governments, universities, and enterprise customers. He was deeply in touch with the public sector perception of products and the nature of the existential threat. Working with BillG, Craig and his team authored a memo called Trustworthy Computing (TwC), released in early 2002 and dictated a new set of priorities and new way to develop products. In addition, CraigMu further developed Microsoft’s Security and Response Center and led it to first-class citizenship in the world of cyber defense.

Often the press and outside world extend too much credit to BillG with something big like TwC. In this case, enough credit cannot go to Craig. He was early to this challenge and brought together the product groups and technologists in Washington, DC and around the world, academics, and other domain experts. He navigated these communities and found a way to frame the problem they were expressing so it could be addressed by the disparate organizations at Microsoft including engineering, sales, legal, product support, and more. Even the phrase trustworthy computing was no doubt influenced by the government commissioned report of that same name, which included participation from members of Microsoft Research and Craig’s advanced products group. Bridging the regulatory and technical gap became Craig’s specialty and proved enormously transformative for Microsoft.

TwC brought increased attention to cybersecurity as a boardroom issue for companies, beyond the damage done by viruses and malware. This was something existential to all companies and their customers, not just technology providers. Microsoft’s Executive Briefing Center added sessions on TwC which served to further entrench Microsoft as a thought-leader with enterprise customers. This was a significant turning point in the establishment of deep customer relationships.

The TwC memo also saw broad external distribution (and would be celebrated at decade milestones). Along with establishing the center, mandatory security training for engineers, and a host of commitments to enterprise customers, we also made security a first priority in everything we did. While many offered input and additions to the memo, I was always proud of pushing what I learned from responding to the Word and Outlook viruses. The January 2002 memo prioritized security over features as we did for Office years before—a strong signal to enterprise customers that we would be, essentially, making incompatible changes.

So now, when we face a choice between adding features and resolving security issues, we need to choose security. Our products should emphasize security right out of the box, and we must constantly refine and improve that security as threats evolve. A good example of this is the changes we made in Outlook to avoid e-mail-borne viruses. If we discover a risk that a feature could compromise someone’s privacy, that problem gets solved first. If there is any way we can better protect important data and minimize downtime, we should focus on this. These principles should apply at every stage of the development cycle of every kind of software we create, from operating systems and desktop applications to global Web services.

Message received. We were going to break a lot of stuff. Customers loved the TwC message, but the compatibility concerns would become a constant source of frustration for decades to follow.

Unfortunately executing the product changes to secure Windows XP turned into a 36-month journey (including an interim Service Pack 1), releasing Windows XP Service Pack 2, XP SP2, on August 24, 2004, three years after RTM and much longer than a quick turnaround. There were several major security incidents over the course of this, which either motivated more changes or slowed down releasing broad product changes, depending on perspective. When people say the regulatory climate distracted Microsoft and slowed execution, all I can think about is how much more responding to security did. While not everyone was working on compliance, every single group with code in Windows, Server, Office was making changes, fixing bugs, or investigating potentially risky areas to improve security of products while continuing to function correctly with the changes Windows was making. PC OEMs and independent hardware vendors (IHVs) contributed immensely by updating all the software installed on new PCs and required by hardware devices.

While the first couple of years were rather difficult with Windows XP, it emerged to become a deeply loved and fixture of a PC operating system. When I was working on Windows, we ended up extending official support for the product to nearly 13 years, three years longer than any other product.

Office was in a different place. We did not face the security challenges to the same degree but faced the needling of Scott McNealy, softening demand for new Office features, and high-friction upgrades from enterprise customers, and the ever-present risks of browser-computing.

More importantly, we were on the verge of understanding how Office could be a full participant in “services”. We began crafting our plans to finally deliver on those offsites from almost a decade ago where we were asked the question of how to turn software into an “annuity” business.

We faced the challenge of forging into new areas and doing new things. Everybody had ideas, which meant saying “no” became a big part of the process. But who would say no and to what and why?

On to 070. Office.NOT

Imagine building a computing platform that powers a generation. Now imagine taking the big step of building the replacement for that platform while the original needs to keep going for another decade or more. This is the story of unveiling the new Windows 8 platform for building modern apps, WinRT, at the first //build conference. The difficulty in telling this story is how everyone knows how the world came to view Windows 8. The developer conference of 2011 was a different story entirely. We still had to work through the big issue within the world of .NET developers and their extreme displeasure with the little we said about the Windows 8 developer story a few months earlier at the preview of the user experience. We had so much to share and were very excited as we made our way to Los Angeles.

Back to 103. The End of Windows Software

The iPad was out there and still had skeptics. Pundits continued to assert that tablets were not good devices for content creation. Techies saw it as a consumer toy for lightweight computing. This same thing had once been said of PCs, right up until they overtook computing. It was said of server PCs, right up until they overtook business workloads and cloud computing.

Steve Jobs, at the 2010 All Things Digital D8 conference, reminded the audience that the iPad was just getting started and added, “I think we’re just scratching the surface on the kind of apps we can build for it. I think one can create a lot of content on the tablet.” By 2011, Apple was demonstrating increasing confidence in the path they had created with iPad. The iPad was already the preferred tool for the road warrior, the boardroom, and the back seat. The iPad and iPhone combined with the developer platform had become the most formidable competition Microsoft ever faced. As much as Android unit volumes concerned the Windows Phone team, there was no ignoring Apple. Some were deeply concerned about the tsunami of small Android tablets. Given what we went through with Netbooks, low quality devices, even in high volumes, concerned me less.

The PC was moribund. The situation in Redmond became increasingly worrisome. This was despite our solid progress on Windows 8 and the interim Windows Phone release, Windows Phone 7.5.

The chicken and egg challenge of platforms is well known. How does a platform gain traction from a standing start? Every platform faces this, but it is unusual for the established world leader to be wrestling with this problem. When I think of how the computer world had literally revolved around every utterance about Windows, it was downright depressing if not scary.

The challenge the company faced was the dramatic loss of developer mindshare. Between web browsers, iPhone/iPad, and then Android, there was no room left for Microsoft. Win32 was legacy, a solid legacy, but a legacy. The latest efforts for Windows Phone seemed to have stalled at best. While there was a rhythm of press releases about app momentum for Windows Phone, the app numbers were tiny relative to Apple and Google and the app quality was low. Phone units were small too, meaning attracting developers was becoming more difficult not less.

Every leadership team meeting provided another opportunity to debate the merits of using financial incentives to lure developers to the platform. And at each meeting I raised the reality of adverse selection that every competitor to Windows had learned over the past two decades. The Xbox team loved to talk about how much they spent on exclusives, but that was a walled garden world of intellectual property. In an open platform, once you’re spending money to win over developers, the least motivated developers show up with the wrong apps creating an awful cycle where paying developers attracts more of the less desirable developers building even more of the wrong apps. But not spending money seems guaranteed to lose if there’s no organic interest. This debate would become front and center with Windows 8 as we faced the same challenge.

The concerns over the specifics of competing with iPad and Android tablets and how Microsoft and partners would respond occupied an increasingly concerned board. We had our plans for Windows 8, but the obvious question was could Microsoft do something sooner? In the summer of 2011, we were a couple of months from our developer conference in September and certainly less than 18 months from general availability of Windows 8. I assumed we could wait that long and knew we could not finish sooner. I also assumed there was no emergency product development that could finish something useful before then. That didn’t stop us from having a classic Microsoft hand-wringing series of meetings to attempt to cons up a plan. Time for yet another Gedankenexperiment as part of a series of meetings with some members of the board and others.

We were not yet certain of the how or who of delivering ARM devices, particularly tablets, though by this point we had test hardware running and we were deep in potential designs for our own device. As a result, I was my routinely cautious self in an effort not to over-promise, especially to this group. I was, perhaps wrongly, determined not to get ahead of our own execution. Such a conservative stance was my nature but also not the norm or even appreciated. I was happy to talk about our developer conference and what was possible. The specifics required to answer when and by whom there would be a mini tablet running Windows were well ahead of where we were.

I reviewed our progress on Windows 8, again. The problem seemed to be that we were not getting enough done nor was it soon enough. They were right. Who wouldn’t want more and sooner? From my vantage point, if we finished when we said we would it would be impressive and historically unique, even on the heels of Windows 7. How quickly people can forget the past. It felt like “more cowbell.”

Shaving time off the schedule was discussed—it wasn’t a grounded discussion, just a wish. After that, Terry Myerson (TMyerson) and his co-leader Andy Lees (AndyLees) of the Phone team, shared the early plans for Windows Phone 8. Since Apple had made a tablet out of the iPhone, the natural question was, could we make a tablet out of Windows Phone? Of course, we could do anything (“It’s just software” as we said), but which phone and how soon?

Some in attendance even asked if should do a “quick” project and build a tablet out of WP7 (or 7.5)? Could we take an Android tablet design and put Windows Phone 7 on it? Why not? Seemed so easy. None of these ideas could possibly happen. There’s no such thing as a quick project. The last quick hardware project Microsoft did was Kin, a poorly received smartphone.

There wasn’t much I could do. From one perspective, Windows was suddenly the product that was holding us back and Windows Phone was the new solution to our tablet problem. Given what we were seeing in the market, Windows Phone apps, and the technical challenges of the platform, this was a ridiculous spot to land.

Windows Phone 8, working with Nokia, introduced really big phones called phablets, pioneered by Samsung on Android. For a time, some analysts thought these larger phones would put an end to tablet demand because tablets were in between. Still, tablets continued to thrive for productivity and, as far as Apple was concerned, to become the future laptop. The iPad certainly thrived. It was the cheap Android tablets, the ones the Board was concerned about, that ended up on the trash heap with Netbooks.

Ultimately, there was no tablet market, just an iPad market. The iPad run rate soon approximated that of consumer PC laptops. It was difficult for Microsoft to see the low-volume player as the real competitor, especially when it was Apple and the last time it was the low-volume producer it nearly died. Android was shaping up to be the Windows ecosystem on phones—high volume, low profit, endless fragility, device diversity (or randomness), and so on, but with a new OS, new OEMs, new business model, and new mobile developers who were making apps on the iPhone, though the iPhone apps always seemed a bit better.

The Windows and Windows Phone teams would eventually go through a challenging period where in the middle of Windows 8, we on the Windows team learned that the Phone team had been taking snapshots of various subsystems of Windows 8 for use in the phone OS. This got the product to market but did not give us a chance to align on quality, security, reliability, and code maintenance. This wasn’t done in any coordinated or even transparent manner. Had we, Jon DeVaan and Grant George specifically, not intervened the company would have been set up for significant issues with security and reliability given we were not finished with the code and there was no process in place to manage “copies” of the code. Jon worked through a better process once the team got ahead of the issue. I had a super tense meeting with SteveB and the co-leaders of the Phone team about this lack of transparency and process and why it showed a lack of leadership, or even competence, on our part. In the new world of security, viruses, vulnerabilities, and more the company could not afford to be cavalier with source code like this seemed to demonstrate. This was all in addition to the lack of alignment on the developer platform as the Phone team made their early bet on Silverlight as previously discussed.

More and sooner was a constant drumbeat throughout the Windows 8 development schedule. I was called to the carpet many times to explain where we were and why we were not finishing sooner. I was grumpy about doing that and I’m sure it showed. Schedules did not get pulled in or completed early. In the history of the company (and software), that never happened. We weren’t going to finish Windows 8 early. We would be fortunate to finish on time, mid-2012 plus two months to reach availability on new PCs.

The leadup to the fall developer conference was a constant series of crises external to the development team but going on all around. It was stressful at the executive level for strategy reasons. Every meeting, every mail thread, every new online story was just more worry for us.

It was stressful at the team level because we had asked the Windows team to pull together most of the company for the release.

In particular, we wanted to fix—yes that is the right word—the schism of the past decade that had replaced what was once lockstep strategic coordination, the Win32 strategy, between the Windows and Developer product groups. The Windows team most accountable for success of the new platform was DEVX, the Developer Experience, and the counterpart to the UEX team. DEVX was led by Aleš Holeček (AlesH) in engineering, Linda Averett (LindaAv) in program management, and Yves Neyrand (YvesN) in testing. The breadth and depth required of this team was in every way as great as the user experience.

Just as Windows 8 designed a new and modern experience, we designed a new and modern new platform to go with it. This platform was designed with the intent of growing to the future Windows platform for all apps across all form factors and devices.

Prior to releasing to the public, we called the platform “Modern Application Model” and later the “Windows Runtime” and finally WinRT, which was the name we stuck with in honor of Windows NT. Like NT we never attached a meaning to RT and just said the letters. In this section, we’ll use the term “modern application” for new Windows 8 apps which had also been called Metro and Metro-style. We were still in the midst of resolving this legal dispute and frankly could not keep the terminology straight which confused everyone inside and out of Microsoft.

We’ve described the experience goals of Windows 8 and to realize these goals the platform for modern apps in the experience had the following goals:

* Native APIs for the new application model, realizing the benefits of the experience

* Rapid application development coming from great tools supporting an API that could be mastered with relative ease

* Amazing tools of choice, including both .NET and standard web technologies

* Broad distribution and a great business model for apps via a new Windows App Store (covered in the next section)

The importance of “native APIs” could not be overstated yet was also subject to many philosophical debates over what really constituted native. At one extreme, some believed native APIs simply meant they came from Microsoft and therefore first party was equivalent to native. At the other extreme native APIs implied written from the ground up from scratch, divorced from any existing capability and consequently all new. As with many debates along these lines, one could debate semantics or simply build the product and let it speak.

I was familiar with this debate from the earliest days of Windows programming. The advent in the 1990s of object-oriented programming called for a new era of APIs that were improved over the abstractions provided natively—in other words taking the native APIs and recrafting them so they would be easier and more amenable to object-oriented techniques. The story of approaching API development this way, and our failure, was documented in section 010. Our BillG Review. In that story, we developed a new API for Windows that was much prettier and tuned to C++ but was also bloated and different than Windows. This failure led to a super lean, efficient, and Windows-centric API that became the standard for building professional apps for the Win32 era, the Microsoft Foundation Classes, MFC.

Without diving too deeply into the weeds of architecture, there is an important point about systems design to make. What separated MFC from the era of object-oriented frameworks was, as described previously, a bet on the underlying platform to do the work. Our framework did as little work as possible and specifically never duplicated Windows functionality. That strategy permitted only one implementation of any given concept to exist and thus defines native. In that case, Win32 remained the native API because of the choices we made in MFC.

These choices were the exact opposite of those made in the various .NET technologies, which liberally duplicated capabilities in Windows. This duplication created both inefficiencies and deeper problems. Incredibly difficult problems to solve such as security, accessibility, localization, and so on were made vastly more difficult when there were potentially two (or more) ways to accomplish the same task or worse one way in a framework that made partial use of the OS. In this type of framework there was complete ambiguity as to what constituted native.

In the modern context, this debate over native capabilities of a platform is the situation currently consuming the Apple strategy of SwiftUI. SwiftUI is a layer on top of the existing native operating system API, but it also reimplements functionality and provides different implementations of other capabilities. Apple is attempting to decree the SwiftUI the answer, but even struggles themselves in moving apps from the old way to the new way. In the context of this story, SwiftUI and the debates surrounding it have a ring of .NET familiarity. I’ve been surprised at the approach but not the result. Apple has the ability to drive change across existing code that we did not have as discussed in the previous section which might smooth out this strategy over time. On the other hand, this entire section describes the outcome of fracturing even the most robust of developer ecosystems.

The approach for Windows 8 was decidedly to define new native APIs and implement those APIs such that there was a single code path for all capabilities. Sometimes the code was brand new to Windows and other times WinRT relied on existing code paths and reused them. Taken as a whole, the set of capabilities represented the first version of the future APIs.

The first version of Windows with any utility, Windows 3.0, was about 540 APIs and documented beautifully in the book Programming Windows by Charles Petzold that occupied a rarified position on every developer’s thick oak bookcase back in the day. Most of us just referred to the book as “Petzold.”

When Windows 3.0 arrived, it was not exactly meeting a known market demand. The platform was intriguing for a class of developers, some of whom had been working on Macintosh apps and others who just saw opportunity in a new way to program user interface. These developers, much like on Macintosh, could pick up a copy of “Petzold” and within a day or so would find their way writing Windows programs, often as a hobby or side project to impress people at work. It was exciting and rewarding. Within a relatively short time the effort paid off with a solid mastery of the 540 APIs. While there was all sorts of complexity and wizardry in the way tools worked, the breadth was such mastery was achievable by a single person.

The property of mastery is an incredibly compelling part of any new platform and often overlooked. The ability to master the platform and to use that mastery to complete an entire project is when something magical can happen, often for a just one or two engineers working together.

By the 2000s, there was no mastery of the Windows API to be had, by anyone. At the very best, one could master a subsystem of Windows such as networking, DirectX graphics, or the file system. Of course there were some wizards, but most of them worked at Microsoft or soon would. Even the largest software houses would struggle with building reliable and optimal Windows software. When the complexity of the various .NET, data access, graphics, and networking APIs were added to the mix the system was insurmountable. A huge part of the attraction of various aspects of .NET, such as Silverlight, was the notion that one could master some subset and complete a project. Unfortunately, as discussed, these runtimes were limited enough that one often needed to venture into other parts of Windows to complete projects. There is no escaping that the explosion of headcount and lack of management accountability to that proved to be our worst enemy when it came to strategic platform coherence for thousands of APIs.

Our Windows 8 plan was to create a new API that covered the full range of development scenarios we expected (or more accurately hoped) to see in the 1.0 version of the modern app world. That API would be the equivalent of “Petzold.” Due to the increasing capabilities of the underlying OS and development tools, the resulting apps would be vastly more capable and easier to write and debug. 

Over the summer as we completed the software build that we would distribute to developers, the DEVX team created “Elements of a Windows tailored app: The Developer Story” which captured the “as we built it” mindset and working terminology used by the DEVX and Developer division teams.

The team took a scenario approach cataloging many types of potential applications along with how the platform could be used to write them. It also detailed how to reuse existing code, such as line of business code, within applications. At 275 pages it represented the amount of material one could master as an individual or team of 2 or 3 people.

The modern platform consisted of three main pillars: modern application behavior, application connectivity, and modern application user interface. Within the context of our ever-confusing terminology, the platform is WinRT which we also called the Metro platform.

One of the biggest changes developers needed to understand was that modern applications did not take over the computer. While many had become increasingly aware of the security model of Windows, which prevented access to various parts of the system without a password, the modern approach to applications meant that there was no access at all to the hardware or to other parts of the system. Every application ran in its own “container” (sometimes called “sandbox”) or essentially walled garden. Most requests to the operating system went through an intermediate “broker” to ascertain whether such an operation would be permitted. For example, in Win32 an application wishing to use the camera would simply connect to the camera as a device and start using it. In modern applications, the request depended on whether the user had given permission to use the camera and importantly whether the developer built into the app the proper requests of the user for permission. This was a dramatic change for Windows and was only just starting to make its way to phones, whereas today we are all too familiar with the endless prompts for permissions to devices. These constrains placed on applications created a new level of trust and security for Windows, though at the expense of the kind of flexibility and “anything is possible” that Windows developers had come to expect.

Applications also behaved differently relative to how they could consume battery power by constantly running. In Win32, every application ran all the time. It did not matter if the user expected the application to be doing something even if the user could not see the application, it was simply how applications behaved. Every little icon on the system tray, every application that created a “background” process, and every window on the screen could be running on the CPU while consuming power. In a modern application, if an application was not visible to the user, then it entered a new state called “suspended” and consumed no power at all. Only when the app was visible did it resume operating as normal. In the desktop computing model, every window must be constantly updated whether the user is looking at the contents or not with each update draining battery power.

This architecture was essential to reduce the power consumption of a modern PC. It was, somewhat surprisingly, controversial. Developers with their large screens envisioned a world with many tasks happening in many windows and work as keeping an eye on all the different windows. The billions on the verge of using phones and tablets, however, were using one app at a time and the screen filled with that app. They were immersed in the app. Switching between apps was instant and tasks resumed instantly when needed. By and large this style of usage so typical on phones mapped to how real-world customers used even current Windows laptops. Most all Windows users had for the longest time, and still, ran applications full screen and worked on one app at a time. Even switching between apps followed the way apps on phones worked. We built support for snapping apps side by side to provide two apps at once.

Still, creating only full screen apps with the new platform would be an ongoing debate or discussion with developers. It was the kind of change that was perfectly fine for the broad user base and certainly for future new users, but not what developers themselves wanted. For developers of course the desktop was still there where all their tools ran anyway. We expected developers to focus on the desktop and they did.

This was one of a number of issues where the initial audience seeing Windows 8 did not see the world the way we saw the next billion customers heading. They had their jobs to do. It reminded me of the early days of Word when the project was not going well and a Word developer asserted that they aimed “to please an audience of one. I write it for me. If I'm happy I know some cool people will like it.” which was a rather limiting way to think of word processors in hindsight.

A distinguishing characteristic of modern applications was how they connected to each other and to Windows. In Win32, apps had a limited way of sharing information with any other app and that was through the clipboard via copy and paste. To do more usually required applications to open up files from one app inside another. This led to all sorts of potential risks, unbeknownst to users, as we learned with Office. Apps could insert malicious data into other apps or apps could crash opening data files created with another app simply because they did not fully understand the other app’s files. Worse, apps could simply navigate the hard drive and gobble up all of a user’s files (in the background!) without their knowledge.

Modern apps were therefore isolated from each other. This would be quite limiting if not for the invention of “contracts” between apps, and between the operating system and app. With contracts apps could easily tell Windows 8 they would accept or provide information to other apps. Windows 8 created super easy mechanisms for apps to share their information with other apps while at the same time accepting information from other apps. This all took place only when a user initiated an action. Across the system, inserting data such as photos, searching across apps, opening files, and sharing information within a file were all just a tap or click away. A key aspect of the design of the platform was to make it as trivial as possible for an app to add these features and access them via the charms.

There were other connectivity features for modern apps as well, all of which were implemented with security and privacy in mind while doing so with a minimal amount of code. Connecting to a printer, a speaker, or camera could be done with minimal code and trivially. One of our most common demonstrations showed how easy it was in the platform to add a live video feed from a camera with only a couple of lines of code.

There weren’t just new-fangled architectural changes in Windows 8. Even the mundane such as how displays worked underwent a dramatic rethinking. At one of the early meetings on Windows 7 tablets when we first showed touch to the PC team at Intel, their ever-enthusiastic platform leader, Mooly Eden, had a question for Windows. He couldn’t just ask he had to show us. Mooly always had to put on a show. He stood up and started flipping a new Windows 7 slate in the air, spinning it. He wanted to know “when will the screen image also rotate?” He was right. Windows had no ability to do what the iPhone and iPad did so well, simply handle the rotation of the screen, essential for a handheld device. Supporting this first required integrating a sensor to detect the rotation, something that no PCs had though Windows 7 provided some early support. Second, the whole video subsystem needed to be reworked. While it was possible to switch orientation of a display in Windows 7, doing so was cumbersome and involved a great deal of flickering and prayers to the Windows control panel. With little fanfare, Windows 8 added this along with support in the modern platform for apps to easily manage the transition between orientations.

At the other end of the spectrum of screen sizes, Windows 8 built the correct architecture to handle the new high-resolution screens coming on market. These screens would come to characterize iPhone and iPad as retina screens. While they were available as external displays for Windows, they were always buggy and flakey. Buttons or text would show up super tiny or where apps would click would not match on screen where the click took place. This failure of Win32 was rooted in the inability to uplevel the whole installed base of hardware and software as the hardware advanced leaving the old software in the dust. Supporting these new screens was one of over 100 features in Windows that improved the desktop and one of many features that were newly native in the modern Windows 8 platform.

Most would judge the completeness of a new platform for how it enabled them to build the main features of their application. In many ways this was the equivalent of Petzold and included the platform for creating the interaction between a developer’s app and their customers. Relative to Win32 and to the chaos of the .NET world, Windows 8 arrived with an incredibly strong story. Much of this came about because of our own efforts building applications for Windows 8 and the scenario planning for the product. Windows 8 provided a palette of over two dozen “controls” or user interface elements typically used in apps. While one could find these and more via third parties or counting everything offered by all of Microsoft’s existing platforms, never had the Windows platform delivered the full set of required controls all at once. This resonated with me personally because of my own history. Back in the early 1990s when toolbars were invented and developers wanted to add them, Windows provided no support even though Windows itself had toolbars. For Visual C++ I worked with a developer on the Windows 95 team who wrote those controls and added them to MFC, using the Windows code. That developer was also part of the Windows 8 team, so kind of full circle.

A key part of modern apps was how they fit in with the design language for Windows 8 to provide a beautiful, aligned, and consistent experience. Such polish and attention to detail was not something Windows had historically delivered. By and large Windows deferred to the marquee apps like Word and Excel to define the proper look of Windows apps though did not support that look with code or APIs. Windows 8 provided developers with a broad set of tools for typography, animations, color selection, user interface grids to align applications, and more.

Fitting into Windows also meant providing the support for system-wide features such as Live tiles, notifications and alerts, as well as all the necessary infrastructure to easily install and deploy apps. These were also features that Windows provided piecemeal, if at all, in the past.

Finally, everything discussed above was designed from the start to be programmed from all of the programming languages and tools offered by Microsoft. Developers could build modern apps using web tools of HTML and JavaScript, C#, XAML, Silverlight, and even C++ or Visual Basic. Every demo we planned on showing at the upcoming conference included use of all of these languages. We were ready to atone for the lack of communication over the summer.

The platform as delivered to attendees at the upcoming conference was as complete as anything ever delivered by Microsoft all at once, and in the first version. We knew we had a good deal to learn and a list a mile long of what we could do in the future. That was a given. We were so excited though to deliver the future of the Windows platform.

We arrived in Los Angeles on September 12, 2011 for our Professional Developers Conference, renamed //build to be attended by 5,000 people and what seemed like the entire technical press community. Marketing for the new Windows 8 Start screen and the new //build logo was everywhere—those live tiles, colorful rectangles, and animation. It was a breathtaking sight. And we were excited to be there. Even the Denny’s across the street welcomed Microsoft for breakfast, with a sign. A pre-show tradition for me is breakfast at Denny’s.

Unfortunately, there was also a something of sense of dread about the languages and tools for creating new modern apps—our self-inflicted crisis created at the unveiling of the user experience and the omission of .NET before the summer. There was so much cynicism in how the various existing platforms had been talked about—always implying one worked well with the other when in fact they were all separate, all had limitations that were not said, and all had major issues. As a result, however, we created the opportunity for a set of people to spend the summer alternating between conspiracy theories and anger over the developer platform.

The effort to make every single Microsoft language a first-class tool for the modern Windows platform was an immense cross-division project. To say it was easy or lacked controversy would be a huge understatement. It was extraordinarily difficult because many inside Microsoft also either believed or even wanted to believe the conspiracy theories surrounding the deemphasis of .NET by Windows. In some sense they had a right to as they believed in their own work and lived through the alienation and schism that Vista created between .NET and Windows. Windows 7 did offer any relief though it also did not do anything to make it worse. In that sense it was hardly a conspiracy theory, but a fact of life in the .NET world.

Windows 8, however, was when the strategic issues of the past required resolution. There was no simple answer. Realistically, the answer would require a degree of subtlety that tested those on every side of the mess, myself included. We absolutely intended to move forward with the languages of the .NET world (C#, XAML, Silverlight, VB, C++) while at the same time there was no plan to simply move all the code created that used the libraries and frameworks of the .NET era such as WinForms, WPF, VB forms, or Forms³ or third parties. This “technicality” would prove to be an enormous barrier to not only acceptance but even acknowledging the strategy we were embarking upon. To many, not being able to simply port their code to new Windows 8 apps was a non-starter. We had accounted for this by describing the difference between domain-specific code (for example all the code that connects to a remote database or cloud service) and the user experience code that would need to be reimplemented. Most all apps written in this world were divided cleanly in this respect. Not only that, this transition was precisely the one most had gone through to provide web access to the databases and cloud services they built.

We had two challenges. First, within the Microsoft bubble it was clear “everyone” used these technologies. The Developer division had created a bubble of the .NET developer world insulated, as previously described, from the world of HTML and the web browser. Within that world it was of course true that everyone used .NET. Anything we proposed that was not about leveraging that investment was by definition failing to leverage something everyone used. Arguing over how much .NET was used as a portion of total development or skilled developers was futile, especially because even defining terms was impossible as we’d learned for several years of Mid-Year Reviews and Developer Usage Surveys. Even discussing the lack of commercial software would only serve to exacerbate the challenges.

Second, the existing .NET world was the one that failed to account for synergy with Windows or address the problems we set out to resolve with a new platform. When it came to consistency with Windows, safety, security, reliability, battery life, or even basic attributes such as performance or accessibility, the plethora of .NET tools failed to achieve a level of performance or quality consistent with our main competitor, Apple.

These two challenges were not just external to Microsoft. The .NET bubble extended to the 50,000 person Microsoft enterprise organization that were the tip of the .NET spear and also the massive Developer division itself. Many people had spent a decade building out these capabilities and all was going well until, well, I came along.

It was no surprise that the whole time Windows tried to create the connections to the .NET languages to use the new Windows 8 platform we ran into discussions about interoperability or conflicts with the existing .NET platform and APIs. Each new advance in Windows 8 was met with an opportunity to debate the reuse a .NET mechanism to accomplish the same—there was a near constant effort to work to insert the old .NET into the new platform. Windows 8 had a strong point of view about a platform for the future that embraced a new set of qualities entirely absent from the existing .NET efforts.

We intended to deliver on that point of view. The good news, actually great news, was that the vast majority of efforts between the teams supported this mission. That didn’t preclude grumbling along the way. There were some outright stressful times. The release of code would surface many of those, either internally or unfortunately externally via the press as well.

Since we know now that Windows 8 did not achieve the success we hoped, this is a reasonable time to point out that it is precisely at this moment that the efforts between teams created the “told you so” people. In Microsoft parlance this is done by opening up Outlook and searching through Sent Items and reliving these debates to prove that no one listened, or someone knew all along. Success has many parents and failure is an orphan. No matter what happens someone always said it would. This isn’t about bitterness on any side, but I can promise many more people contributed positively at the time than seemed to contribute in hindsight. We’ll return to this reality.

We had an incredible keynote planed for the first morning. It would feature a demo of Windows 8 experience from Julie Larson-Green, an incredible overview of potential Windows 8 devices from Mike Angiulo, for the first Chris Jones detailed the many cloud-based services integral to Windows 8 experience, and on-stage Antoine Leblond would build a modern app using HTML and Silverlight. Even I did a demo showing only features improved in the desktop. It was a two hour and fifteen-minute tour de force by the full Windows 8 product executive team.

I had been to a lot (a lot a lot) of Microsoft keynotes and conferences and launch events over the years. I participated in many as well. With as much sincerity as I can muster, the keynote for the 2011 //build conference was absolutely Microsoft at its best. The whole of Microsoft had never come together to deliver such a coherent and compelling message. It was all done live on real computers running real software. Nothing like it has happened since and it is clear we’re in a new era where that 2011 presentation might have marked the end of the PC era live event. Even Apple would cease to take on the kind of risks we took on during that demo when it came to real products, demonstrated by real executives, in front of a live crowd while streamed around the world. It scares me now to think of just how crazy we were. It was by far one of my favorite days at Microsoft.

Within that favorite day were two favorite moments. Technically, three if you count the walk-on music at the very top of the keynote that I chose. I walked on to Renegade by Jay Z (with Eminem)—“No lie, just know I chose my own fate./I drove by the fork in the road and went straight.” Certainly, over the top. But I felt we could have taken an easy path and just built yet another version of Windows doing more of the same, there were many options for how to do that the equivalent of going left or right. Instead, we created our own path and went straight. The short sound clip is not in the official video because of copyright.

Over the summer we had become increasingly concerned that developers would have no way to experience Windows 8 on the type of hardware we expected to exist in the future. We were working with OEMs closely to create PCs with touch panels, ink pens, and in a variety of form factors from pure slates to convertibles to laptops to all-in-ones. While we tried to have some of those machines for Windows 7, they were few and not commonly owned because Windows 7 lacked the value proposition to drive sales.

The Ecosystem team had been working closely with Samsung on an Intel-based PC that was a pure tablet form factor with an available docking station which could be used to connect a mouse, keyboard, external display, and wired network. The PC was powered by the latest low voltage Intel Core processor. Many of our demos and most all of the demo sessions (over 100!) would use this PC at the show.

At the 2009 PDC we were excited enough by the prospects of touch computing that we provided attendees a free touch laptop. It was a new “thin and light” form factor which was just starting to come to market to compete with Apple. This announcement stunned the audience. Therefore, by the 2011 //build attendees were certain there would be another free laptop. As a point of information that stunt in 2009 cost millions of dollars more than even the revenue from the paying conference attendees.

In the keynote, MikeAng, ever the showman, walked through all of the platform capabilities that the ecosystem and developers could bring to life with Windows 8. Showing everything from ARM-based devices to liquid cooled gamer rigs the size of dorm refrigerators. Then he began to describe a new Samsung device. He said, slyly, the device was being produced in small numbers right now as a prototype. I looked at him and asked “so how many will they make” to which he replied “well, I’ve been told not to bring a cool PC unless we brought enough for everyone so there are 5,000 out on the loading dock right now.”

And with that we announced the “Samsung Developer Prototype PC” to go with the “Microsoft Windows 8 Preview Build.” And everyone went nuts. The key value of this PC was precisely to demonstrate the value of Windows 8. With one PC running Intel developers could run and develop Windows 8 applications for both Intel and ARM devices. The Samsung came loaded with Windows 8 software, sample apps, Visual Studio pre-release, and more.

Little did the 5000 attendees know but over the previous week a team of about 40 Microsoft engineers had been unloading the Samsung PCs from crates air-shipped from Korea to install all this new software and configure them for distribution. In order to get them to Los Angeles in time, Samsung had to manufacture them before the software was complete. It was an heroic effort and made it all the more rewarding for sure.

If you’re interested in more about this, Raymond Chen (RaymondC) a member of the Windows team (UEX) and author of “The Old New Thing” wrote a post with some insider trivia, Some trivia about the //build/ 2011 conference.

Loaded on the Samsung were 17 new Windows 8 applications, the source of my second favorite moment of the day. In addition to the apps from Microsoft such as Mail, Calendar, Bing, etc. each visible on the Start screens shown throughout the week, these 17 apps represented a chance to have fun with the pre-release. The amazing feature of these apps were that they were built entirely by the interns over their 10-week summer jobs. We asked 17 groups of 2-3 interns to work together to build these fun apps from scratch and zero baseline understanding of Windows 8. Not only were they able to create these apps on their own, but they did so when neither the platform nor the tools were near ready and were constantly shifting. I was so proud to both announce and share their summer accomplishments. While for most school had already started we were able to find about 20 of them who were able to sneak away from school to attend the conference and even provide a scheduled sessions detailing their experience. It was as amazing for them as it was for me. It was a career highlight for me. They even made a video of their summer experience which we showed to all the show attendees in the keynote.

That this group took their ideas with an unfinished platform and tools to create new apps was a huge source of validation for the “Petzold” test we hoped Windows 8 would pass.

After providing attendees with a candid roadmap from this moment to final release, there was a short break. We were not done with amazing day one content though. There were two absolutely amazing presentations to follow. We overwhelmed attendees with depth and quality of presentations.

First, JensenH provided an overview from the experience perspective of what makes for a great Windows 8 app. This was the touchstone presentation that brought together all we had learned to date, since the unveiling and subsequent feedback as well.

Following this, AlesH brought things down to the metal and showed the developers in attendance the ins and outs of the Windows 8 platform. He wrote a ton of code and built live apps on stage ably assisted by John Sheehan (JSheehan) who was a senior software engineer on the platform. Importantly, they showed off building apps from scratch using Visual Studio, connecting to Windows 8 to share information and use devices, and also detailed the architecture that provided apps with a sandbox to run in for safety, security, and predictability. They even showed off how apps don’t consume resources when they are not visible on the screen. Of course they used all the .NET languages and showed the broad support for bringing forward that knowledge.

Even with all that incredible content, there was one slide we worked the most on and that was a boxes and b******t, or politely boxology, slide showing the new Windows 8 platform and its relation to all of the programming languages and APIs Microsoft had to offer.

This was not a slide I dreamed up in my office, not even close. Aleš in his role as distinguished engineering leading DEVX and the Windows 8 platform worked for weeks to create this diagram, collaborating with every part of the whole project across Windows and Developer division. I thought it was a work of art.

Aleš also made the slide a key part of his presentation. By the time he spoke the proverbial s**t had hit the fan and he knew he had to somewhat rescue his slide. People had already written instant blog posts and the live blogs picked up on the diagram as well.

So what happened?

Presented in all the glory of the Metro design style, huge and on stage, was as clear a diagram as we could have created describing the Windows 7 world being brought forward for desktop applications, including support for Internet Explorer, Win32, .Net, Silverlight, HTML, C++, C#, and more. Everything had a box, resting on top of the Windows Kernel (a.k.a. MinWin!). New modern apps were shown in boxes with all the tools and languages available to build “on top of” WinRT, including that same list (XAML, HTML, C#, C++, VB, and JavaScript).

The diagram, created by dozens of people from nearly every team in the company, proved incredibly popular, but not in a good way.

To support the diagram, Antoine’s full demonstration of building a Metro app went through all the languages and tools, in real time on stage, by building an app. He built several apps. He built an app in HTML. Antoine took sample code from Developer division vice president (and previously manager of Silverlight) Scott Guthrie’s (ScottGu) famous (amongst .NET fans) XAML sample, and with no changes ran it as both a desktop app and a Metro app on WinRT. The new Metro apps were touch-enabled, integrated with search and sharing, and even showed off the beautiful graphical qualities of the platform by displaying nicely alongside the rest of Windows 8.

The problem?

Before I even got off stage, people were taking the image and redrawing their view of the architecture. Some were critical of precisely how their favorite tools were rendered. Others challenged the technical integrity of the diagram. Within the developer press there were even news stories and a quite a few blog posts dissecting the travesty that was this image. It all happened in real time before we had even finished.

There were blog posts that dissected the diagram and rewrote it. It was the technical buzzsaw applied to a conceptual diagram. The weirdest part for me was that this was a diagram we had created about our own technologies, but the .NET community thought of them as their technologies. In reality, they wanted Windows 8 to work like Windows 7 while further adopting their .NET technologies. They wanted Windows 8 to fulfill the .NET promises they believed were made, and even more so now that we were indeed delivering a new platform. There was little accounting for what we believed we needed to accomplish in righting the Windows platform or the necessary steps to modernize the Windows platform.

Some of the blogs centered around how much code was actually Win32 though repurposed, not because that would be bad but because of a theory that would undermine our argument about the modern platform being native or completely new. Others took aim at the use of the .NET languages versus the .NET runtimes or libraries. This issue was the whole point, unfortunately. Ironically for me this point also was one I made to BillG for years when it came to the value of owning a proprietary language versus owning the API. Now all those championing a language were learning the value was really in the runtime. Yes, that was always my point.

Emotions were running high. There were deep concerns about investments in existing code and porting it to modern apps. We didn’t make this promise to the degree developers wanted and, as a result, there was a wave of feedback over Microsoft abandoning them and costing “millions” of dollars of lost revenue. That’s what people said. To me, this had shades of past transitions, specifically, the major mistake Microsoft Word made in trying to reuse the code for character mode Word to build Windows Word. It did not work and cost the team years. It also felt like the carnage caused when much-loved Visual Basic switched to .NET.

The biggest mistake in platform transitions is attempting to deny that a transition is taking place or to believe a dramatic platform shift could be managed by incremental changes.

Not everyone writing about this diagram took such a negative approach. Several provided thoughtful views pointing out that there was a good deal to be excited about. In an in-depth view, Paul Thurrott wrote on his SuperSite for Windows blog:

WinRT solves many of the problems of Win32, from an apps perspective, though it can't be used for certain things of course (writing NT services, drivers, and the like). Apps created for WinRT are safe, secure, and sandboxed, can't wreck other apps, can't cause "Windows rot," and all install in just 2-3 seconds. They feature isolated storage, single folder installs (as per the Mac), and require user consent to access the general file system. When Microsoft says it "reimagined" every aspect of Windows, this new runtime, or application model, must be included as well. This is part of it, a modern, truly different app platform that is far more different, and far more capable, than many people understand right now.

And in the same vein of blowing past peoples' expectations, virtually no app could not be written as a WinRT app. Many are imagining very simple, HTML-like apps, and while I'm sure there will be plenty of those, you need to reset your expectations up. WinRT is amazingly full-featured and not constrained to goofy utilities and simple games. The next "Call of Duty" could be a WinRT app, complete with support for Edge UIs and Charms.

And here's something interesting: Virtually all of the Microsoft WinRT apps--Mail, Calendar, People, Chat, and so on--are all written in HTML and JavaScript, not C# or another supposedly superior language.

And you laughed when they repeated "Windows reimagined over and over again in Tuesday's keynote. I'm starting to think they didn't push this point enough.

Our main aim for //build was to put forth the message of a bold reimagination of Windows from the chipset to the experience. That was what we wrote in the press release.

So many of the reviews of the pre-release product articulated the bold design, the attractiveness, the functionality across different types of PCs, and the compatibility with everything in Windows 7. The note of caution was always about the amount of change and how some users might be skeptical. Overall, the press and bloggers were excited and impressed with the leap we had taken, excepting those still debating the diagram.

After a month with the pre-release code, ArsTechnica in its detailed review had the following to say in “Turning to the past to power Windows’ future: An in-depth look at WinRT”:

Microsoft is taking a risk with WinRT, as developers may not follow it, but it's a calculated risk, and it's a low risk. The re-use and modernization of existing technology gives WinRT instant familiarity for developers, but also an easy path for Microsoft to extend the reach and capabilities (and ease the restrictions) should it need to. It's at once the embodiment of Windows' future and the embracing of Windows' past.

I shared how I thought this event was Microsoft at its best. The press coverage following the event generally agreed. I recognize in hindsight this might seem to be a combination of delusional and revisionist. It was neither. There were over 1,000 original stories of which nearly 700 were what we called PRIME, an acronym defined by the PR agency for stories appearing by top writers in top publications. On average the stories were extremely positive. In a system the agency used to score the tone and message pick up of stories where 100 is neutral, we scored 124 in 386 news stories, 118 in 293 blogs, and 117 in 11 product reviews done in real time. Microsoft events routinely scored a negative sentiment during this era, meaning less than 100.

The agency put together an End of Event recap that ran for over 120 pages. These were tremendous results, not solely because of the content by any stretch. Achieving these results required an amazing marketing and communications effort around the world.

With no intention of shaming any writers who subsequently revised their views or chose to come to different conclusions later, some of the quotes that came along with the availability of code and the Samsung PC press loaners were positively effusive:

“I've never witnessed this much excitement in a Microsoft audience at a keynote before. It's electric.” –Tom Warren, WinRumors

“I might just become a developer considering how easy #Microsoft has made it to write things for Windows 8.” –@reese305

“my iPad suddenly became old fashioned #win8 #bldwin” –@martinsih

“Hello, Windows 8? This is iPad. You win." - @thurrott

“the Metro UI stuff is the best thing Microsoft has come up with in years.” @thurrott

“Here’s the real feather in Windows 8’s cap: Write once, run (mostly) everywhere software.”, PC World, Nate Ralph

“the experience still felt magic, and that’s what really counts. Well done Microsoft.”, RedMonk, James Governor

"Apple bloggers were apparently so flustered by the platform that they resorted to bombarding Twitter with jokes about cooling fans and Silverlight instead of stopping for a moment to realize that Microsoft is showing us the future of computing.", BGR, Zach Epstein

Obviously, it wasn’t all positive. Surprisingly, some still questioned whether we would release “on time” though we did not provide a date we knew we would hit the fall. The real lingering question, and one that did not come up all that much at the event, was the “two modes” of Windows. Speaking for “users” many press would rhetorically ask if users would be able to understand the two modes of using Windows, the desktop, and the new Metro experience. Owing to the developer audience, they were not yet concerned about ARM and simply saw it as an opportunity. They would be running Intel because that is where development tools existed.

The issue of “two modes” was the one we needed to tackle. I wasn’t sure of what else to do. Given the history of Windows “modes” and what we designed for, the complaint and answer were not easily reconciled. Would this become the focus of the release?

With all that, including the protestations around our box diagram, I had wrapped up one of my happiest weeks at Microsoft. It had been a long time since the whole of Microsoft came together as a team and delivered a strategy and produced an event with such clarity and developer excitement.

In under 24 hours we had 500,000 downloads of the Windows 8 Developer Preview Release. At the time there were perhaps three million professional software developers worldwide, total.

It was Microsoft at its best, but the reactions turned out to be relatively fleeting. The developer community was but one audience. For all the dustup over .NET they were the home crowd at //build.

We had a nagging issue of competing with Apple not just on iPads but on laptops. Could we work with the ecosystem to muster something to compete with Apple’s MacBook Air, finally after years of failing to even try?

What would mainstream consumers say with a much more polished release? What would developers say about the new Windows Store which we had yet to show them? What would we tell developers waiting to see how Microsoft Office would build for Windows 8?

On to 105. New Ultrabooks, Old Office, and the Big Consumer Preview

The last months of a product development cycle the scale and length of Office10 are moments of calm punctuated by moments of terror. The calm comes from the lack of code changes as thousands of people test the product while hoping not to find anything requiring code changes. The terror comes from issues that arise when you have little time to change them because we’re still dealing with the physical world. Something that seems so trivial like a product name requires a month of more of work to get right, then rolled out around the world. Office10 did not have a name just three months before we would finish. Office10 was also one of the first product releases for Microsoft where when the product made it into customer’s hands there also needed to be live and working web sites that extended the product, for over one hundred million people on day one. Other moments of terror come just after the product ships and those first reviews—it is not just if they are good or bad, but will there be a recall class issue, be it a design choice or product defect. Such an issue could tarnish the entire product cycle. What if our marquee feature—the one in all the printed brochures and print ads—ends up part of a scandal rapidly spreading to Windows XP?

This post brings you inside the last months of a project that was the first Office product to ever finish on time, and perhaps one of the first Microsoft products ever to do so. As it would turn out 2001 might be viewed as peak execution for the middle-age of the PC journey. The Windows release under development which would become Windows XP would also ship on time, a first for Windows. It makes sense that the major products would learn to ship on time just as the world was moving on to the internet.

Back to 067: MYR-CDG: Product Meets Sales

In early 2000, branding and naming the next release of Windows was all gummed up and that slowed down Office, which needed a name in order to release on time in March. Whistler, the code name for Windows, was scheduled to ship about six months after Office10. An August ship date for Windows was achievable, and no one wanted to mess that up. The name, perhaps to the surprise of many readers today, was a long pole in the release as it touched code in many places and could impact localization, manufacturing, printing, and packaging. We needed a name. How hard could that be?

Windows trying to settle on some variant of “experience” because the main thrust of the release was to finally bring the Windows 95 experience of peripherals and consumer software to the enterprise-focused NT code base of Windows 2000. In addition, we collectively concluded the year names were not working (hence Windows Me) because of the difficulty of keeping ship schedules and customer confusion over what products worked with each other, both issues were entirely predictable and frequently discussed at the time. The branding team was thinking of something like Windows EXP or Windows XPR, and finally Windows XP. My concern in an endless email chain was not this product but the next one. Would the next name have a roman numeral, go back to adding version numbers, a superscript, or add descriptor Edition branding? At one point, someone mocked up Windows XP ² which made me wonder if I was being made fun of, especially in the Spanish release.

The corporate teams settled on and cleared the name Windows XP, and what immediately followed was the question as to whether Office10 should be named be Office XP. The corporate branding team and sales teams were in favor. The Windows team, however, did not intend for other products to add an XP suffix. This seemed to be another .NET in the making, which was still nowhere close to being resolved. The branding powers demanded evidence in the product that supported co-branding.

We held many meetings during development about aligning the releases of Whistler and Office10, but the products were on wildly different schedules. From our perspective, Whistler was about finishing Windows 2000 without much new for Office. Besides, Office was going to run perfectly well on the new corporate desktop of Windows 2000 anyway. Windows 2000 had been years late, so it was not unreasonable early in the process to doubt the next Windows schedule. Whistler was making a ton of progress and we were self-hosted, so any worst thoughts were not going to happen. This was a first for Windows! Still, there was no significant release synergy. Office ran on Windows XP, and realistically not even as well as it ran on Windows 2000 PCs with the same amount of memory.

At one of these meetings the topic of naming them the same became heated, if not awkward. BillG wanted to know what was interesting in Office10 and what was unique when it ran on Whistler. Baked into this assault was the belief that Office was not exciting on its own and more importantly that Office failed at exploiting the latest Windows release. This was the view that came from the perspective that innovation from Microsoft emerged first from Windows.

My answers were not satisfying as I restated the series of meetings, lack of APIs, and our system requirements. I chose to highlight the work we did to align with Windows Server for SharePoint, totally irrelevant to the conversation in this context. BillG expressed frustration at “another release of Office that relies on Windows to make it exciting,” which honestly didn’t make much sense and bordered on insulting. By and large we were not looking to the Windows desktop to innovate for Office. In reality, many innovations in user-interface flowed from Office to Windows for years already. That wasn’t interesting to Bill in this moment.

Windows really wanted the XP name to be unique to Windows. Office really didn’t want to look like it required or was matched to Windows XP. We learned that lesson when Office 97 arrived and many consumers at retail were wondering where the matching Windows 97 was or even if Office 97 ran on Windows 95. After more time back and forth, Office marketing and corporate branding agreed to, no surprise, a compromise of a name—Office XP with a “Version 2002” prominently displayed on the box. The apps were called Word 2002, Excel 2002, etc., not Word XP or Excel XP because branding didn’t want to overuse the XP moniker. Windows did not have such a version on the box or in the software. Also, the boxes didn’t look at all similar. This meant customers calling product support or using the web site would need to search for “2002” and not XP, unless they used Google which got it right. I can’t make this stuff up, but just wait until the next release of Office.

We had a name. We were on track for March 2 and we had a date for launch (and boxes for Germany). We signed off on 3/2/01 just like we planned. It was magical to do that. We beat the Excel record from more than a dozen years ago and hit our planned ship date. I know this sounds ridiculous—product development schedules are supposed to work, but it simply did not happen with software projects. We were so happy.

For launch, marketing planned one main US event, which we expected to be covered globally. BillG headlined the event at New York City’s Manhattan Center Ballroom aimed at getting broad media coverage, while around the country and world there were hundreds of local events targeting enterprise IT professionals. There was no effort to get people lined up at stores or any sort of midnight madness, though local offices around the world did some of that and we did have BillG greet the early buyers in New York. A fixed launch date is a great forcing function (there’s that phrase again) to get everything ready for press tours, reviewer workshops, and enterprise product information.

For enterprise customers the main features of the release going back to the original product plan were collaboration and integration with the just-shipped Exchange 2000. SharePoint Portal Server 2002 (there’s that naming again) released a few weeks after Office XP which included SharePoint Team Services and also served as a collaboration platform. Our collaboration story was as complex as predicted in our vision statement, a result of targeting the same scenarios to two different back-end infrastructure products.

For system administrators, we enabled new scenarios, such as installing Office XP from a website and ever-more controls and customizations for deployment. There was a lot there and it was all new for enterprise customers. Industry analysts were having a great time digging into the idea of Office shipping servers.

Through some incredible outreach efforts by marketing and the field, more than 500,000 enterprise customers used the product in pre-release. The internet made it easy to distribute the product, and because of Watson we not only knew (anonymously) that people were using the product, but we were fixing bugs based on their usage and knew the release was high quality. We really knew that, not just hoped. Shipping software had radically changed using Watson. The availability of data forever changed what we worried about when shipping.

These are the Office XP consumer data sheets. These were used at retail outlets, tradeshows, and by sales people making calls on potential resellers.

The traditional tech press and mainstream media continued to struggle with explaining, or making broadly interesting, heavy enterprise features like collaboration. I was still smarting from the reviews of Office 2000 and was determined for us to get credit for the personal productivity features. We built a great set of capabilities that worked with or without servers, and as was common at the time with or without a broadband internet connection, though by that point most every customer was connected.

Office XP introduced several novel features we believed gained notice including the first features that worked seamlessly using an internet connection from within the apps. Building such features was a fascinating lesson in team transformation. With many stories from the early days of the internet about traditional print-based offerings unable to transition to the web, we set out to do something new and innovative with the thousands of pages of training materials and the vast library of content we shipped on CDROM. Jeff Olund (JeffO) began his career in “user education”, creating the written materials that accompany a product. He became a leader in building reference and training materials for Office and then led the worldwide localization team based in Dublin, Ireland. With JeffO’s leadership, content went from a cost center to an asset for the business. The Dublin team went from taking almost a year to localize Office into a dozen languages to localizing Office into 100 different languages in just a month or so.

The next step in content to help customers was to use the internet to provide endlessly growing features such as adding images or clip art to a document, templates, how-to, and more. As an example, before Google pioneered image search, it was luck that enabled an author to find suitable clip art. Especially in large corporations, most of the clip art we shipped with the product was eliminated to save disk space. In Office XP we introduced an Insert ClipArt feature that used an ever-expanding and easily searchable collection of internet images much larger than anything on a CD. The idea of tens of thousands of images available for free was quite cool for business users of PowerPoint tired of angry person and idea lightbulb over head person.

In hindsight, a product having a website seems obviously trivial. But at the time, we were deeply concerned about adding a website to a product used (and liked) by hundreds of millions of people. The web was still flakey (and slow) and while novel, sites routinely did not work. We did so much work in quality, the thought of having toolbar buttons or menu commands leading to strange errors from unavailable sites was horrifying. Websites needed to be new and fresh all the time, and always work.

The help system was no longer limited to what was written and shipped with the product but could also search a large and growing library of how-to articles on the web, including an under-the-radar hit called Crabby Office Lady who offered tips with an irreverent tone (“advice with attitude”), authored by a professional writer on the team Annik Stahl (AnnikS). Annik’s column was wildly popular with hundreds of millions of views. She was interviewed by local newspaper tech columns (often writing similar content) and even had television appearances (as herself, not the character). The character and personality Annik created even drew some inquiries from the VP of Human Resources over concerns of stereotyping. Annik’s goal was to take aim at the perceptions of the Office product, not the Office customer and she had full control over the project she initiated. We saw this approach used to great effect with a series of books such as Word Annoyances, that had become one of the most popular books on using Office products. So popular was the Crabby column on the site that Annik also went on to write a book and was part of several behind the scenes stories.

We created a new online services team under JeffO’s leadership. AndrewK moved from OPU to lead program management to help focus on content working for JeffO, who reported to me. Seasoned managers Mike Kelly (MikeKell) and Randall Boseman (RandallB) had to create new processes and tools to go from zero to a one hundred million web visitors seemingly overnight. The Content team developed schedules for creating, localizing, and releasing content at regular intervals, something we had only previously done on multi-year release boundaries.

Between online content, Crabby Office Lady, and the introduction of a new sidepane user-interface, plus the ongoing ridicule aimed at the Assistant we also made some big changes to Clippy. The plan for the product cycle was to provide even more options and administrator controls to reduce Clippy’s visibility, including making sure that by default Clippy no longer appeared, though it could be summoned if desired. Importantly, the message for Office XP was that it was so easy to use that “ . . . Clippy is no longer necessary, or useful.” That might have been spin, perhaps.

Lisa Gurry (LisaGu) in marketing thought up a clever idea to make the most of this change, and to embrace the opportunity to be self-deprecating in the process. She planned a formal retirement for Clippy. Instead of tacking the feature change on to the press tour in April, she planned a web-based celebration. Gilbert Gottfried, comedian and voice of dozens of animated characters, was enlisted in a set of internet Flash videos (these were all the rage then) of Clippy trying to insert himself into the daily lives of people. On retirement day, Lisa issued a press release and dressed another member of the team in a giant Clippy suit as we strolled Union Square in San Francisco, complete with a cable-car ride.

While this was the least corporate approach to PR, it set a high-water mark for intentionally cool viral marketing. To this day, the “retirement” still gets a laugh.

Laughs, however, were not part of the marquee feature, known as Smart Tags. Smart Tags were a set of buttons shared across Office applications appearing when and where the user needed them (such as when a user made an error in an Excel formula, when Word automatically corrected a user’s action, or when a user pasted some data), providing options to adjust the chosen action or fix an error. Smart Tags appeared when pasting text into Word, giving a choice of whether to match formatting or not, a common need with the rise of taking text from web pages. Smart Tags made it easy to undo (or never do again) when Office autocorrected something incorrectly, like convert a row of dashes to a typeset line.

While there were many different features across the product, Smart Tags provided a single and consistent unified interface. From a marketing perspective, Smart Tags felt like toolbars in their ability to be a visual symbol of innovation in the release. The screen shot was used all over the place.

It was Office at its best. We thought.

In press tours and reviews, Smart Tags proved a novel interface approach and were demonstrably innovative. Surprisingly, it took us several years to achieve—this idea was in the works going back to the original Office interoperability work in 1994, but before we could execute new ideas we needed to clean up the old implementations of menus and toolbars, which we did.

Smart Tags were also extensible. A corporation could recognize an order number or a shipping code and make it easy to link directly to those websites or systems. Browsers, especially Internet Explorer, and tools like free email programs or websites, were not yet universally inserting automatic links by recognizing the text of http://, phone numbers, dates, or other common strings. The most well-known was the use of 1Z as a prefix for a United Parcel Service tracking code (tracking was a new thing for consumers), which with a Smart Tag enabled that text to act like a link to UPS, if Internet Explorer or Outlook used Smart Tags extensibility. Phone numbers, addresses, dates, and more were all candidates for Smart Tag actions. We computed the time saved by the use of Smart Tags to be an insane number of millions of hours—pure marketing.

We thought this such a clever idea and an opportunity to show off synergy with Internet Explorer that we created a Smart Tag add-in for IE that recognized many common potential links. It seemed useful and synergistic and was included in the Internet Explorer 6 beta test. The IE team thought this was clever too—this was before browsers could be customized with add-ins and web pages were mostly static HTML (except for the occasional blinking or marquee text).

It wasn’t long before JimAll (the leader of Windows) called to tell me that people were freaking out. By this he meant that the press tour for IE was not going well. Concerns about Smart Tags were expressed within the context of IE. While there was some hyperbole, the concerns boiled down to feedback expressed stridently by Walt Mossberg, who wrote in the Wall Street Journal, “In effect, Microsoft will be able, through the browser, to re-edit anybody’s site, without the owner’s knowledge or permission, in a way that tempts users to leave and go to a Microsoft-chosen site—whether or not that site offers better information.” The terminology isn’t aging well, but the idea was simply that links would appear on HTML pages that were not authored by the site owner. This in effect could be viewed as editing the site, where editing means adding new links to a page authored by a third party.

This notion of “re-edit” went beyond what we considered or even thought of the feature. There’s some irony in that today browsers and mail clients (and many products) do this for a whole host of special strings and even Apple computers provide reference lookup to Apple sources. At the time, it was routinely pointed out that the climate of 2001 was filled with concerns that Microsoft might leverage one part of Microsoft to benefit another poorly performing or just poor part of Microsoft. Smart Tags in IE surfaced those concerns. Perhaps exactly the right feature, at exactly the wrong time, from exactly the wrong company. Conspiracy theories felt real to many perfectly rational people in the industry.

To make that point, Mossberg concluded, “Microsoft’s Internet Explorer Smart Tags are something new and dangerous. They mean that the company that controls the Web browser is using that power to alter others’ Web sites to its own advantage. Microsoft has a perfect right to sell services. But by using its dominant software to do so, it will be tilting the playing field and threatening editorial integrity.”

We did not think through the potential abuse of the feature, though even in the worst case it was not precisely what was suggested by some. Sites were not being rewritten and links were not getting replaced. Neither was it benign nor free from potential exploitation. We did not consider how someone with bad intentions might develop a Smart Tag add-in that could at best be annoying and at worst recognize text and offer a link to a nefarious web site. As a result, IE removed the feature, which spared us the challenges. It appeared as capitulation, and the press was not shy about expressing that. As a broader point, the company, particularly under the new leadership in our corporate legal group, preferred and encouraged capitulation, especially for anything that might catch the attention of its constituents, the regulators.

Office XP and the press materials still had this marquee feature, using the name Smart Tag everywhere for consistency. Was the name tarnished, though? There wasn’t anything we could do other than downplay the name and issue Q&A and FAQ documents to the marketing teams around the world. This was an unfortunate side-effect of not having thought through the implications in the browser.

The Smart Tag incident took place at what was perceived to be the height of Microsoft’s power and potentially negative influence on the industry. The fact that we relatively quickly backed down has been viewed as a milestone moment. The incident was even portrayed in a widely read profile of Walt in WIRED, May 2004, titled “Kingmaker.” It was an example of “dozens of companies that have redesigned products in response to Walt’s unsparing criticism.” Walt was right. I viewed this incident as the system working—the reviewers acting as a check on poor product choices.

Finally, we always reminded people we made the product more stable each release. With Office XP, however, this was provable. We equipped the press and field with statistics and descriptions of the Watson curves and buckets so they could understand our new approach to improving product quality. Watson was industry-leading and pioneering. Every time I represented this work I am sure I beamed with pride, even though showing it off meant using a tool we wrote for demos that forced the product to crash (again).

The reviews of Office XP generally reflected the positives of the product for both consumers and businesses. The industry was going through a post-dotcom consolidation and, while tech was still enormously popular, the slow but certain decline of print journalism (and the dotcom bubble) affected reviews. First, the budgets in time, people, and hardware for the kind of testing we used to see at Byte and PC Magazine were reduced or gone. This led to a decline in reviews based on usage of new parts of Office, especially the hard-to-test parts like SharePoint. Second, the web itself favored shorter and faster takes on what was new. People wanted reviews at the time of release. While we gave ample lead-time and supported embargoes, other pressing demands made it difficult to spend time in research mode prior to a product release. With the PC deep in middle age, in-depth reviews of technology products were replaced by more instant analysis of meta topics, such as the impact of the product to the company or a take on whether the product should be deployed or not. (Hint, they always said to stick with a current version unless that was old.)

In that context, Office XP provided a glimpse of what was in store for the business. Every review evaluated the product in the context of the value of the upgrade. The assumption for Office was that everyone with a PC owned it and, while this was far from true, it might have been true among those reading tech press with their up-to-date PCs at work, but not all PCs by any measure. Enterprise customers already owned Office XP and were by all accounts only upgrading with a PC refresh cycle. Reviews almost always included benign comments about the product from IT managers along with a quote about not being clear if there was enough value to upgrade at the time, but certainly the future looked good.

The decline of awards like Editor’s Choice and in-depth 10-page reviews with benchmarks was, honestly, sad. It was as though the world cared less about what we did. The internet was the new focus for consumers and businesses. It was no longer the PC and new desktop software.

The enterprise field fully engaged on an XP desktop motion, meaning Windows XP plus Office XP, even with Windows months from finishing (as an aside, Windows XP was the first Windows release to have a plan and schedule that remained steady and the product finished on plan late summer). Office XP and Windows XP were better together for the enterprise. That reduced the sales surface area for the field from two products to one, so to speak, which was greatly preferred. In that sense, the timing of the two products together reinforced a core belief of BillG’s, that new applications provided excitement for a new OS, which created demand for new applications—a virtuous cycle.

Our glitzy launch event in New York at the end of May 2001 featured BillG leading an enterprise-focused event but with enough consumer demonstrations to capture headlines. The focus on productivity was illustrated by a broad though relatively unsupported statement, that by “making Office just 10 percent better we can save hundreds of millions of man-hours.”

We were joined by some special guests that day. Chief among them was the founder and CEO of a relatively new Seattle-based company called Amazon.com. Jeff Bezos joined BillG on stage to demonstrate searching for Office XP on Amazon and buying it with Amazon’s new One-Click ordering feature. A box even arrived on stage for Jeff and BillG to open.

But my mind was already deep in navigating what should come next for the product and the team.

On to 069: Mega-Scale, Mega-Complexity (Chapter X)

Microsoft was often viewed as a Borg-like structure though we’ve already seen when it came to product development it was decidedly of two cultures. The huge and growing global sales force so dominated by SteveB (now CEO) represented a third, one completely defined by the unique combination of massive global scale and local empowerment and respect for culture. What happens when a Redmond-based software engineer-turned product group executive meets this culture head-on? What about when that happens in front of his new boss who previously ran the field and created the process we’re about to see unfold?

This is a story of culture. It is also a story of growing and maturing as an exec. Most of all it is a story of how a product leader is not really complete until they’ve lived and breathed the efforts of the sales people that connect with customers and bring in the money. Below is an early experience. A few years later I would pack up and live in China to experience firsthand on a daily basis what it was like to sell every day.

Back to 066. Killing a Killer Feature (In Outlook, Again)

In the classic book Flow: The Psychology of Optimal Experience, Mihaly Csikszentmihalyi demonstrates that a genuinely satisfying experience takes place in a state of consciousness called flow. During flow, people typically experience deep enjoyment, creativity, and a total involvement with life. While the book uses many examples, the concept of getting in a groove resonated with me. Flow is how programmers spend hours writing code and how our best customers spend hours creating satisfying documents with Office.

Reading Flow helped me, but my job was changing. . .a lot. The demands to be present in the newly added building 34 executive suite overwhelmed me at times. The pressure to spend so much time ruminating with other executives ran counter to what I came to believe and what I experienced as flow. It didn’t used to be like that. I know because I used to see the execs I worked for most every day, casually.

Flow was how I felt writing a vision or the interactions I had as I walked the halls. This was especially important at Microsoft where everyone had a door. The criticism of private offices was that people get shut out of collaboration and spontaneous discussions (in favor of concentration and quiet focused work, apparently). I never believed that to be the case, because we had a culture of door open/door closed that implied a willingness to chat spontaneously or a need to focus. Since my first days at work, the richness of hallway and drive-by discussions were most useful and memorable.

The idea of connecting spontaneously and learning what was on the mind of a member of the team was something I viewed as my job—so much more than sitting in a conference room with other executives or reading slides presented by managers but prepared by people not even in the room. Making eye contact, not in a hurry, discussing someone’s work and seeing if I could put it either into context or simply offer perspective on something going on in a bigger picture—that was flow for me. Everyone was always wrestling with something—bugs, recruiting, implementation choices, and more—and while I didn’t want to walk around fixing things, I could support, learn, and connect. Most importantly, this was a way to connect with less senior members of the team 1:1. Even today, I can recount some of my favorite moments and best connections coming from people I was able to learn from by walking the halls, a phrase made famous at least in the tech world by Intel’s Andy Grove.

Doing so was not the norm for many execs, especially outside Apps or the product groups. The vast majority kept to a Microsoft exec workflow of a reserved conference room across from their office and a steady stream of meetings all day. Even 1:1s were often held in bigger conference rooms.

The 8 a.m. meetings, the meetings to prep for meetings, the emails written by staff to communicate the meetings, the rescheduling of the same, were all starting to pile up. I felt I was becoming detached from the team—I was losing flow. I was uncertain of whether I was a poor fit for the role or if my role was defined wrong. I struggled trying to understand what changed in the landscape that required such a change in how to manage. We weren’t facing new problems or new concerns—there were no new competitors or competing technologies. We had ideas to grow to new areas and were executing, and the enterprise sales process was yielding absurdly good numbers. What was I missing? Or, how could I convince people that managing 2,500 people was an investment in time that might be different from how a huge subsidiary GM or marketing VP ran things? Others in similar positions felt differently. They seemed to gravitate towards this new Microsoft culture. Perhaps I was wrong or underestimated what was needed to operate at scale and that was the driving force behind this perceived shift.

The field’s annual Mid-Year Reviews (MYR), the process JeffR pioneered, were the most coveted meetings for field teams to attend. If there was a culture-defining element to the growing and incredibly successful enterprise field it was MYR, and it could not be more different than anything we did in the Redmond BGs (Business Groups, as we were called to imply we were separate businesses rather than mere product teams). BG was the new term for the teams in Redmond and everyone loved to say it as a differentiator to the field. Everything seemed to come down to the BG versus the field. It was as if Microsoft was a constant struggle between a BG brain and a field brain.

To say MYR was a production would be like calling the Olympics “some people playing sports.” Over the course of three weeks or more in January, the company’s collective leadership focused entirely on syncing up at various locations around the world and presenting mid–fiscal year results. Each year the process became more elaborate, took longer, involved more people, and became more all-consuming with ever-increasing import. Every country, though some were presented in regions, marched through a standardized slide deck slicing and dicing sales budgets and forecasts, finding holes, ferreting opportunities, and sharing best practices. These meetings were tense, terrifying, and a test of thinking on your feet under the harshest of business conditions.

To be extremely clear, this seemed an absolutely fantastic way to run the sales force. To me, this was their version of vision meetings, bug triage, and daily builds. The field was scaling up to tens of thousands of people pushing with a relentless focus. The military precision and standardization were obviously brilliant. My own love of flow was exactly what made me appreciate this process. The scale was mind-blowing.

But I didn’t need to see it to appreciate and understand it, any more than I thought the field needed to attend spec reviews or triage meetings. Product groups saw each other every day and maintained a tightly integrated effort in continuous adjustment starting and ending with Redmond. The product teams integrated across many levels almost constantly.

The field was a geographically, linguistically, and culturally dispersed organization of massive scale tuned to be with customers operating on its own, focused on goals decided at the start of a twelve month execution process. The field was the definition of an organization tuned to thinking and acting locally. Each fiscal year, the global team regrouped and realigned for the next. MYR was the halfway point, checking in on all the assumptions and results that defined the fiscal year and fixing what needed fixing.

The connection between corporate and field was essential. There are many ways to connect—MYR was not the only time to see the field. I visited subsidiaries, connected with PSS routinely, (still) attended executive briefings, and we engaged marketing and planning essentially full time with counterparts in headquarters and subsidiaries, and directly with customers in forums like the OAC. The field headquarters staff was where the planning and coordination of the subsidiaries and regions coordinated full-time. Issues and resolutions bubbled up from the field to HQ for solutions in real-time with the BGs. Every year since becoming a vice president in 1998, I made a point of attending some MYR reviews, just not all of them. In the latter part of the 2000s, attendance became tightly controlled and required an invitation and resulting assigned seat. Failing to show (thus wasting a slot) was deeply frowned upon and clearly visible by a name placard and empty chair. For many, attendance became mandatory, and despite the protests, attendance was viewed as career progression.

What was an MYR like?

Meetings were usually held offsite, often in an airport hotel meeting room, and started at 8 a.m. Wherever we were, the room was always filled to the brim and oxygen was soon replaced by stale air, usually extremely cold air with that breeze of hotel air conditioning. Seating was assigned around a big rectangle of worktables. SteveB sat at the head of the table and fanned out from him on either side by rank were the field executives, followed by leaders from sales segments such as enterprise, education, small business, OEM, retail, and others, along with an army of finance people from corporate and the subsidiary and the region. Across the room from SteveB sat the subsidiary leadership guiding the meeting, with the GM sitting in the center and then a mirror of subordinates on their side, also by rank with the exception of a chief of staff or business manager right next to the GM as owner of the MYR Deck of slides. There was a gallery of the HQ business divisions on one side—usually the head of marketing and the senior product leader (such as, me). Outside sat (or loitered) everyone else who could not fit into the room but was on hand ready to provide backup materials should they be urgently summoned.

There was a slide deck, but it was not made of slides so much, but rather posters printed in 8- to 10- point type on 17 x 22-inch paper, spiral bound. The pages were fully packed with rows, columns, bullets, numbered callouts (“as you can see at callout number 7. . .”), and a lot of heat maps (mini spreadsheets with cells colored coded red, yellow, and green to indicate severity of issues). Every year brought innovations to the decks from better data integration on the back end to the use of color. A most prized possession was the databook, which was essentially a cheat sheet for the whole process that was available to the field executive leadership and SteveB—it contained global and regional summary tables, making it possible for comparisons to be discussed mid-meeting.

Each page was easily eight slides worth of data. Deck preparation began in the fall and was practically a full-time job for a team of people—in the big subsidiaries, dozens were deep in preparation. The slides were almost all data—data pulled from sales systems and reconciled across, and up and down, all the subs. Once all the numbers were right, the teams went through the decks and compared the actual numbers with the start-of-year budgets. Preparation was knowing exactly why for every variance, positive or negative. Outlying data was identified with a callout and a concise explanation was at the ready. Why did you sell fewer education PCs this year? Why are enterprise renewals behind budget? Why have you not met your hiring goals? Why did you rent such an expensive venue?

Every. Single. Number.

Intellectually, I knew for me to sit in this meeting watching what was going on was akin to a salesperson pondering the endless discussion about a single code change in a bug triage meeting. Emotionally, it was another story.

SteveB and the sales leaders were relentless and disciplined about accountability. An inability to explain a number credibly, or worse missing that a number was off, was bad, really bad. Every GM knew that this was not a meeting, but a performance review. Meetings that went poorly were legendary. Everyone was aware of the story of that time a meeting went so badly that when it was finally time for a 15-minute lunch break at 3 p.m., upon returning the seat the GM held before the break was vacant and his name placard was gone. Did that happen? Not quite. But the legend was all that mattered.

When a page turned in the book and the speaker changed, on to OEM sales for example, everyone briefly looked at the page (with a ruler and magnifying glass) and noted the circled numbers and carefully placed arrows. Then suddenly, usually, SteveB pointed to some specific number amid a giant grid of numbers and asked, for example, why business PC laptops were so low last quarter. Missing an outlying number was a crime, and it was shocking to watch what happened as a result. Panic ensued. An important skill among sales leaders is the kind of inherited capability the cheetah has to pick out the camouflaged prey from among all the small creatures in the veldt. Picking those outliers are the small prey of sales executives. SteveB was Jedi master of finding out what was important or determining the opportunity in a grid of otherwise indecipherable numbers.

This, unlike a standard meeting, was an ultramarathon. For a major subsidiary, like the United Kingdom, France, Germany, or Japan, or an important growing one like Korea or Russia, a MYR meeting could go on for 10 or even 12 hours, even though they were only scheduled for half workdays. And when it finally seemed over, the next team showed up. Jetlagged, suited up, hungry, and tired, they could have been waiting half the day in the lobby, but then they were on. We sat there the entire time, and while we broke for a meal, we usually brought food back to the table (which made the whole room smell of food and tired humans). We finished most days past midnight in the early hours of the morning and were right back hours later for 8 a.m. or earlier if the next meeting was already looking like it would go long.

An MYR was to me like what being on a space flight must be—long stretches of nothing and then a moment of terror when some instrument buzzer went off, warning lights strobed, and then the everything turned a red hue of emergency situation. That was these meetings. The buzzer was a subsidiary saying something about Office, the product or business, that was either negative or non-supportive. Then all heads turned and looked right at me. If my head was down in a laptop (or flat on the table asleep, “Bueller . . . Bueller”) then everything about that moment of terror was amplified. The cardinal sin: “I’m sorry. I did not hear what you said.” Leaving to go to the bathroom or to get a drink at the wrong time escalated into a “bad MYR”.

While most of the slides were financial and focused on clear, sales-oriented accountabilities, for many years there was a qualitative section called Feedback to Corp. Usually offered by a GM, the feedback was candid, addressing areas that needed improvement that only BGs in Redmond could fix. Topics ranged from a single product bug that cost a big EA contract, to marketing materials not appropriate to the sales motion, to resource allocation guidelines that were not right, to broad product feedback usually connected to a big and challenging customer. The field was run diplomatically, so ambushes weren’t supposed to happen.

The months-long preparation provided time to socialize the feedback so the BG could have a properly prepared response to recite at that point. These meetings were, in many ways, theater—for both sides. As an example, at the end of a meeting SteveB and the execs offered feedback, which was usually a series of messages about how to approach the second half of the year. By the third major subsidiary, messages were not only honed, but the subsidiary staffs shared them with the downstream subs and everyone knew what to expect and was on the lookout for even the slightest variations (variation was the real feedback). Dedicated staff judiciously tracked every question and potential follow-up, entering information into a tracking system that later pinged the relevant parties with email until an issue was resolved. Over the years this tracking system was automated and targets of feedback received reminder mails for months until an issue was marked as resolved.

MYR 2001 for major EU subs was at the Hilton at Charles de Gaulle Airport. By day three, I had my fill of French hotel food and was longing for the McDonalds that I knew was in Terminal 1. I knew I needed to find time to hop on the shuttle to get there. The shuttle circled from the hotel to the gates and back at regular intervals, taunting me each time I imagined it passed. It was cold and dreary outside. I had no idea what time it was as we’d been in meetings for days on end. Modafinil wasn’t in use yet (Provigil a non-narcotic prescription drug originally used to treat narcolepsy now a favored pharmaceutical for traveling executives). We’d already gone through the United Kingdom and France. Germany was up. Germany and a dozen other countries loitered anxiously in the lobby for two days, in the hopes of picking up some G2 about questions and drill-downs.

The NASDAQ crashed one year earlier, and many countries were in rough shape. MYRs reinforced the adage that “when the United States sneezes the world catches cold.” Still, PBS was generally doing well, though there were concerns that growth was slowing. In reality, we were going through a transition from choppy retail licensing to greater and smoother revenue through Enterprise Agreements. We were riding the year of deploying an enterprise-standard desktop of Windows 2000 with Office 2000, and Exchange 2000 just released. There was plenty of exciting enterprise software and strong initiatives.

The other thing that became clear was that changing the whole world market takes time. While the United States moved to enterprise licenses, the rest of the world was lagging. At the extreme, another decade would pass before Japan was fully enterprise licensed. Germany was in the middle, especially because its market dominated by giant manufacturing companies moved deliberately, meaning slowly. The implications were twofold. First, the enterprise section of the review was tense—HQ was putting pressure on sales to get big customers signed to EAs. Second, most of the Office teams in subs still viewed a retail launch as the big driver, something HQ made second fiddle for Office 2000 and which for Office10 was even less of a priority. While Office planned a single big worldwide launch event, the primary effort was on 100 local North American enterprise events. The strategy was to replicate this in each major market at appropriate scale.

When it finally came time for the PBS section of the meeting, I tried to perk up, still thinking how much I wanted to get on the shuttle. There was some back and forth conversation happening over enterprise selling and the difficulties of customers in the manufacturing and autos sector. There was some friction over the ever-troubling state governments who wanted lower prices on Office and perennially threated to switch to Linux and open source if they didn’t get it.

Everything seemed normal. Then it was time for Feedback to Corp and, with it, an ambush.

Germany decided to make a big deal out of an Office10 retail launch. Our BG guidance was to spend marketing dollars on the enterprise launch (with the large number of local events to drive IT awareness of SharePoint and business value). We planned a global launch event in New York, with BillG in attendance. While the event proposed by Germany was different, if the field made its numbers (all of them) then it was empowered to do what it believed was right. For all the top-down planning, execution was remarkably empowered with the field.

The rub was the German team was in contract negotiations with an expensive venue for the retail event and needed a solid commitment for software availability. They literally needed an immediate certain date for when volume quantities of German Office10 could be available through all German retailers. This was January 2001 and we were scheduled to RTM three months later. They knew we could commit—how could we not? They didn’t like our scheduled date, though, and wanted an earlier one. Our actual boxes in stores date was May 31, which gave us buffer and was the plan.

We scheduled down to the day for everything, but we were not operating the team as though this was a date–driven release at the level of manufacturing. I was 90 percent certain of RTM on March 2, 2001 (3/2/01). Our worst case, we thought no later than March 16 which was only two extra weeks. We could slip because of a bad bug that took time to track down, or if there was a production hiccup (a bad master CD, a virus in an image, a delay in collateral for the box). Beyond that there was time needed to complete localization. We were not yet to the point where English and German versions were done on the same day, but we compressed that difference down to a week or so, especially for German (we always did German early because the words are really long and that was a good test for the product visuals, plus GrantG leading testing was a native German speaker). The final step was manufacturing the CDs, which happened in Japan, and then getting those assembled into boxes and distributed. Any time lost on this step could be made up by spending money on air freight and expedited shipping if really needed.

Such logistics steps and concerns raced through my head in the fraction of a second it took the entire room to turn and look at me like I was the last human in Invasion of the Body Snatchers. Then I committed a fatal error. I did not say, “Yes, book the venue for that date and we’ll make it.” Instead I said, “I can’t be certain of that [earlier] date. We have a schedule, but we are not operating to guarantee retail boxes in stores in Germany on that date. Given what I know and how we’re working, I would do this at the end of May as planned.” I suggested we might finish early (that was the single worst thing I could have done on top of my first worst thing). We already communicated our end of May date in the leadup/socialization phase MYR, but they wanted an earlier date for local reasons and chose to make that case in the MYR forum—it was that important to them. I said a lot of words I should not have bothered saying.

My words were met with silence. I felt like that moment in outer space disaster movies when the alarm is off and all that remains is the silence of space and the red emergency lights. I’m certain I was perspiring.

Because of their venue choice, none of what I said was “acceptable,” I was later told. They wanted that venue, on that date, and were forcing the issue—managing me in front of JeffR (whom they knew super well) and SteveB (whom they knew sided with them). The back-and-forth continued and I kept digging myself a deeper hole—at some point my spirit rose above the room and I watched the mess unfold.

Most of all, what was on my mind (that I could not share) was that we were still in the middle of figuring out a product name. The corporate branding team was working to come up with a name that spanned Office10 and the next Windows release. Without a name we could not finish the software and we could not make boxes, marketing materials, or even announce the product to retail partners. The lack of a name was becoming a sore spot with the engineering and localization teams. We were three months out and literally did not have a product name. Shocking for Microsoft, I know.

As of MYR, there was no name and corporate was suggesting we slip the Office product so they could have time to come up with one. They were working on a Windows timeline, with scheduled end of summer ship date. It bugged me that they were nonchalantly considering a slip of Office so Windows could have more time to come up with a name. As if I needed a reminder that Windows was the lead dog. I was being a good citizen and not throwing that team under the bus at MYR. In the process, I stepped in front of or under the bus myself. Heck, I threw myself off the bridge at the bus.

Neither of us could see the other’s point of view. They were asking me for a favor: Make it happen. Germany could not see that I was trying to avoid an embarrassing event with no software and had no idea that I was working to avoid embarrassing corporate branding or shifting blame to them. I kept thinking that the team back in Redmond was doing so well, the last thing I should do as the manager was come back from a three-week hiatus to create a fire drill over the retail launch in Germany when we prioritized the worldwide enterprise launch for two years, especially when they were in a holding pattern on naming.

Germany and HQ called a truce and accepted the feedback, and marketing agreed to work out the details. The body language directed at me from the SteveB side of the room was painfully clear.

Following the conclusion of the meeting, JeffR pulled me out into the lobby of the hotel where I stood longingly watching the shuttle bus to Terminal 1 roll by every 15 minutes of this ad hoc 1:1. He was obviously livid though maintained a calm delivery—we had only been working together for a few months. Without asking any questions he said, “That cannot happen.” He said we were obliged to deliver. He told me I handled it wrong. This went on for what felt like an eternity—look, there’s the shuttle again. The entire time I assumed my name placard was being removed.

In that moment, I welcomed being put out of my misery.

When we returned to the main room, my name card was still there. I sent some mail back to the United States to say we needed to make Germany happen. Grant believed we could do it, but he could not guarantee that date. We told them to go ahead. Everything was fine.

Except me.

The biggest cultural difference internally was that MYR was the field’s shining moment. It was a chance for them to overtly manage the HQ organizations, so long as they had the facts straight. The field took direction from HQ on good days and put up with shoddy work and poorly executed marketing and product on bad ones. For 50 weeks of the year, they absorbed everything. Each country wanted its chance to be in charge and their meeting was when they had the upper hand over the BG.

Until this MYR in 2001, I hadn’t grokked the power dynamic. The idea of being managed in front of a room was so opposite the old Apps product group culture that for the longest time I simply thought I was being bullied. JeffR taking the side of Germany in the meeting was him taking part in the ritual of the culture when he sided against me in front of everyone. It is always weird to experience your new manager not supporting you in a big public meeting. I wondered if this dynamic was different or crazy or a bit of both?

One thing was clear: My job was different. Same software. Different job. I had some learning to do.

On to 068. The XP eXPerience

Enterprise software customers learn about roadmaps and plans long before the development team has robust execution plans. That’s part of the business. No matter how much these discussions with customers and partners are caveated, a failure to deliver is a big deal. Customers, partners, and salespeople all have a vested interest in those slides (promises!) coming to life when we said they would. When a project is spread across two separate and large development teams, failing to deliver or “cutting a feature” as we called it as if to minimize accountability, the cross-team dynamic is brutal. When BillG gets involved, the temperature rises even more.

Thank you again subscribers. For many readers, you will be receiving a renewal notice about a week before your subscription is automatically renewed. I am incredibly appreciative of your support this past year and look forward to another year of amazing stories: Office user interface, Windows 7, Windows 8, internet services, Surface, and more. So much to dive into. Again, thank you for your ongoing support. It means the world.

Back to 065. SharePoint: Office Builds Our Own Server

JeffR, my new manager and executive vice president, send me a note “LIS: Wow, the story just gets worse and worse. . .Let’s kill it.” He pushed to resolve this festering issue and suggested a meeting with BillG. This would be the second time we cut this feature, having shipped Office 2000 without it.

It was December 2000. In a hastily arranged lunchtime meeting (a BillG must was to always have hot lunch at noon), we sat in the Board Room where we normally met with him. It was a deeply technical meeting, the kind he liked. There were senior people from Exchange, Outlook, and the company experts on data storage that have been meeting as part of Bill’s project to improve storage. The meeting was to decide whether or not to abandon the work on LIS, or the Local Information Store, feature of Outlook and Exchange. The meeting was very tense. The broad view was that this feature was absolutely key to competing with IBM/Lotus Notes. The Exchange Platinum release was late with an uncertain ship date. Office10 was less than three months from being complete, and the code was essentially frozen.

After a tense hour that ran over, BillG said he would think about it, leaving everyone in a state of limbo. It was unusual for him to not reach a conclusion immediately. That meant he was either going to take an unpopular stance, perhaps try to keep the feature alive, or he knew it was a pretty grim situation and was going to avoid confrontation in the room. Counter to what many might have believed, Bill did not like to get involved in binary decisions that leave little room for optionality or win-win outcomes.

An hour later he sent mail saying it was a difficult decision but “I am for killing it because less than 5% of customers would end up using it.” That conclusion was based on the state of the feature as presented.

What followed was the rollout of a brutal cut, which included drafting mails for another month, communication with the field sales group, and removing dependencies on the code.

This recounting made the process seem straight forward, but in fact it was one of the most challenging last-minute product changes I experienced. Going through this surfaced many of the most difficult product strategy and cross-company execution challenges Microsoft exhibited.

During the meeting with Bill, I was not worried or concerned. I was frustrated (and it almost certainly showed). There was no need to have this meeting. The feature basically cut itself. There were no options other than delaying products for perhaps a year to complete this feature. This was the “physics of shipping software”.

Even though the classic by Frederick P. Brooks, Jr., Mythical Man-Month, was over 25 years old and found on every Microsoft engineer’s bookshelf, when decisions made it to the executive ranks, especially when they involved cross-group and strategic initiatives, the lessons from the book were forgotten.

BillG would ask if we could allocate more resources from either team to speed things up. We all knew that there was neither the expertise nor the available resources to do that. Plus, we all knew what the mythical man-month said about that, “The bearing of a child takes nine months, no matter how many women are assigned.”

BillG would offer suggestions on how we could scale back on some of the features or scenarios in order to require less work. We had been doing that for months. The feature had been scaled back so far that even if we shipped what we discussed at the meeting, it would not have moved the needle on competing with Notes. Quite the contrary, it would have disappointed.

BillG would say it would be acceptable to simply add some more time to the schedule, perhaps three months. Physics of shipping this amount of software meant that three months was hardly any time at all. Given all the work to test, stabilize, and for servers getting feedback from customers, adding three months was about the same as adding a few weeks of engineering at best. Besides, even without this feature Exchange Platinum would likely not ship until the end of 2000. Office10 was all but complete and “re-opening the patient” as we said was not an option. It was just physics.

There was something about how the company was working that we permitted ourselves to go through this sort of exercise when there really weren’t any options. Generously it was a process to come to grips with a difficult failure to deliver. Alternatively, it was a way of spending energy exploring options that didn’t really exist anyway. That’s why I was frustrated. It was decision theater. The bottom line was we didn’t deliver and there was no rescue mission.

There are times when these meetings can yield a new outcome. Projects have constraints and if BillG (or anyone in a position to do so) could relax some constraints—the broadly-defined trinity of ship date, features, or quality—then there is a new path to take. Usually, teams that forgo examining and changing these assumptions on their own tend to have other problems as well. Shipping software is managing the trinity and adjusting along the way, not blindly following constraints that aren’t working.

What was this feature and why was it so important? LIS was a new way to store all the email on a PC. This of course seems crazy today because no one wants email on their PC where it could be lost or stolen or worse. LIS was a new model of email where the PC would maintain a copy of the email that was on the server and keep the copies in sync. This made it possible to work without an internet connection while also enabling a rich level of capabilities to build apps on top of email that ran on the PC. This replicated storage was a key feature of Notes.

Underlying the feature was a new data storage architecture. Here’s the challenge. This model of software requires the code on the PC with the exact same capabilities as the code on the server in order to realize the benefits. Notes accomplished this with a smart architecture designed from the start. Exchange and Outlook evolved without such an architecture, and we were trying to retrofit a much more elegant architecture on top of Exchange. To do so would have required building a PC-based system with the same capabilities as the one running on big servers, but able to run with PC-level hardware not the much faster and more capable server hardware. The result: even by December 2000, LIS in Office10 was very best case 20% or more slower than Outlook 2000 and required a high-end PC. No one was accusing Outlook 2000 of being speedy, so this was a significant negative.

There were many other features that were slated to be delivered. Some of them were highly requested by customers. One was the ability to store email using the new UNICODE characters so one email storage file could easily have mail from any language. One feature that might be strange (or poorly architected) was that LIS was going to make it possible to connect from Outlook to the mail server using the web protocol HTTP and not the Windows networking protocol, which was really important for scalability and security. LIS aimed to provide a badly needed search capability that Outlook completely lacked. Another was the ability to store more than 2GB of email on a PC. This might sound crazy, but the cost of storing email on servers was so expensive that most Exchange customers were limiting email to 25-100MB (megabytes!) The rest of email could be stored in a separate file that existed only on a PC. The implication of such an architecture was that Outlook needed to be unbelievably rock solid and never ever damage that mail storage file. Any bugs or fragility in the code might mean a customer would lose all their email, permanently. The idea of inserting an entire new data storage format into the product at this late hour bordered on crazy.

Developing this feature was never going to be easy. It was another case of two major products with different processes, approaches to work, and schedules trying to align. Kurt DelBene (KurtD) was always calm and a great partner with the Exchange team leader Gord Mangione (GordM), but the tension over this work was palpable the entire release. The two products, while built by separate teams, were inescapably linked. Microsoft’s email strategy relied completely on both teams delivering an integrated product, while also serving another larger strategy (Exchange working with Active Directory, Outlook as part of Office).

The bet was even bigger for Office beyond Outlook. We had made a major bet on delivering “Office and Exchange for Corporate Groupware” as a significant pillar of the vision. While our vision process was still new (this was the second time we used it), the idea of losing a whole top-level focus area really hurt. In addition to Outlook, Office created a new tool called Designer, staffing an entire team of experienced engineers specifically for end-users to create applications like those in Notes. It was to be the cornerstone of Notes compete. Without LIS, there was no Designer—the work of that team would not ship at all.

The marketing team briefed important customers about the whole set of LIS deliverables including the features, Notes compete, and the new Designer product. There was a lot of excitement. It was easy to generate excitement with slides and mockups, especially when it made closing a big Exchange deal easier. Unwinding that excitement was brutally painful. Each customer meeting is incredibly difficult for the account and sets the relationship and business back. Immediately discussions turn to potentially turning to IBM for a solution to collaboration. Customers were tuned to escalate these failings straight to SteveB who in turn would again ask if there was anything to do or what he could say or offer. There was nothing. It was physics. The field hated physics. Customers did not understand physics. The press equated a missing feature with vaporware—software that never really existed except to muddy the competitive waters. How could Microsoft, the largest company in the world with the best software engineers anywhere not deliver? What did it mean for the future?

There were no answers, easy or otherwise. One way to say this was we failed to deliver. The lesson is not as simple as a failure to execute. Israeli military postmortems remind soldiers that there are no failures in battle only failures in intelligence. In software, failing to deliver was not a failure in writing code, but a failure in planning what code to write and how to write it. We were still planning products like the primary audience was retail customers or hobbyists who were more than happy to work through messy details, wait a little longer, or have some bugs as long as there was new stuff. Enterprise customers with their huge spend, multi-year planning horizons, and 5-10 year usage plans, were in no position to absorb this sort of attitude. We failed to plan, so our plans failed.

It took most of holiday season 2000 to make rounds with customers and all the teams to let them know we had cut the feature. The reactions across the company were varied depending on the team. The different cultures make quite an appearance at times like this.

The Office team already knew the feature would be cut by the time we told them it was official. More than anything they wondered why it took so long for Kurt and me to admit, finally, what they knew to be the case. Even our marketing team was somewhat relieved as this simplified our collaboration message to SharePoint and our email message to Exchange, without any redundancy. The Designer team, a whole new team, took it in stride as they knew it wasn’t coming together. I do not want to downplay the stress and strain on the individuals who committed a product cycle to the work. It was not their fault—they were at the receiving end of this failure.

The Exchange team was in a different state of mind. They tended to see things through the lens of Office decommitting at best or at worst Office was never committed. When a consumer of a dependency cuts a feature, it was often perceived as though they never really believed or somehow did not try, any evidence to the contrary. The presence of what was seen as a backup plan (SharePoint for collaboration) only made it seem as though there was a plan all along to “fail.” Exchange had a right to be anxious because they owned the Notes compete story and this was a big blow. It would take another couple of years, but Exchange would handily win in the market. The idea of building applications moved to the browser as quickly as customers decided they simply needed great email and scheduling more than applications, and Exchange plus Outlook was superior there. Competing with Notes, by 2000, was about skating to where the puck was as hockey legend Wayne Gretzky might say.

There was no escaping that the wounds were deeper on the Exchange team. Cutting LIS surfaced years later in a story highlighting Microsoft’s perceived morale difficulties. In the story in Forbes Magazine, “Microsoft’s Midlife Crisis”, a former Exchange engineer was quoted "They sent me a 200-page document that said our technology had to be 100% better than the current stuff. Then it failed, of course, so they did it themselves." The Outlook team would say (and did) that it just needed to be the same, not 4-5 times slower and bigger. Nothing was easy and when it doesn’t work and when failure is poorly managed, people can remember the worst parts in the worst way as they seek accountability.

There were hundreds of technical account managers who were anxious to begin to build Notes-like applications who reacted horribly to the cut. To them this was another case of Redmond not understanding what customers needed and worse failing to deliver what we said we would deliver. In the field, where salespeople have quota that they make or not, where general managers either make their numbers or find a new company to work for, failing to deliver what was promised was a first order failure. I attributed much of the enthusiasm and support of SharePoint for collaboration and Notes compete to the lack of an Exchange story. The enterprise team in marketing spent the better part of the next six months smoothing over each country and market, one at a time.

BillG was disappointed of course. Something he always did extremely well was bounce back from these setbacks and not put the team or leaders in any sort of penalty box. I previously shared the story of AFX, my first project, and how we wasted a year and got nothing done while Steve Jobs’s NeXT was on the rise. Bill was as anxious then as he was now and in a similar way—was there anything we could do sooner, more people, or a little more time? I bounced back. We bounced back. In this case, it is fair to say Bill re-doubled his efforts on the major project of the early 2000’s, data storage. In his eyes the failure of LIS only made it more critical to solve the company’s “storage problems.”

We held a big meeting in the atrium and announced the cut to the whole Outlook team. Everyone knew. This was a formality. As we were easing the team into the final decision, I thought of Andy Grove’s Only the Paranoid Survive. In the book he recounts the long process it took to come to grips with the need for Intel to exit the DRAM business only to come to understand the middle managers had long ago realized what was inevitable and made resource allocation choices in that direction. It was as if Grove was the last to really know. The team knew. We all knew. It just took a while to get there. It was the physics of cross-group collaboration, not just the physics of software.

A final reminder to the team was that we don’t market the features that didn’t make it into the release. No one was going to know there was something we did not do. In fact, the list of things we did not do was infinite. We did what we did, and it was going to be great.

I learned a lesson (again) about pre-committing to customers when basic engineering prudence said otherwise. With LIS out of the way, and Watson streamlining development, we were on a path to ship. We were feeling good. Like the end of every project, we were in the period where most people came to work and did nothing but make sure no one else did something rash. For a change, this holiday was going to be enjoyable and free from any project time crunch.

Cutting is shipping. We proved that once again.

Countdown to RTM blast-off and 3/2/01. At least I thought so.

Subscribers, share your story of the most difficult “cut”. In hindsight, was all the pain to make the cut worth it?

On to 067. MYR-CDG: Product Meets Sales

I admit up front this will be one of my favorite sections to offer. SharePoint was a remarkable point in the history of Office as we expanded the product line from desktop Win32 applications to include servers, a prelude to services. Within Microsoft this was by many accounts not only heretical, but also impossible. How could a team made up of “UI programmers” develop a server? Strategically, the inherent conflict between a server tuned for information workers and the actual server business was intense and fraught with difficulties. I would learn another lesson in bundling versus stand-alone product, and endless lessons in just how much the analyst world struggled to make sense of Microsoft’s product line, even when it just didn’t matter.

While I could spend many pages on the features and my love of SharePoint as a product, the transition Microsoft was going through while we developed SharePoint is equally important to the overall story being told. We will start there.

Back to 064. The Start of Office v. NetDocs

“We need an ‘Office’ server” was another one of those driveway lunchroom conversations with SteveB before he became CEO. It was a concrete expression of an abstraction. What he was really saying was that Office needed to think broadly about how to solve the problems information workers were having. That business card he used to make a note of “find me all the stuff about France” was now looking like a product issue for Office. We were all-in on the opportunity and were well ahead of Steve, having been thinking about this from the moment we saw FrontPage. We made it through the 97 and 2000 product cycles and FrontPage had established itself as a favorite tool of Internet Service Providers. We were ready to build on that foundation and expand the little web server we had been using to share product documents on the team. An Office server was a key part of the Office10 vision. The path from vision to RTM was not going to be a straight line.

The first half of the year 2000 was nothing short of eventful:

* Microsoft and customers survived the looming Y2K apocalypse. Despite dystopian fears, except for a few trivial and humorous problems, nothing went wrong at midnight.

* Windows 2000 shipped.

* Microsoft rose to an astronomical $500 billion market cap.

* Then the NASDAQ dropped more than 2,000 points with the Dot Com Bubble becoming a defining event of the rise of the internet.

* Judge Jackson declared Microsoft a monopoly that violated the Sherman Act (causing a 15 percent post-bubble stock price drop), and then later ordered the split of Microsoft.

* Office was attacked by a massive virus, resulting in the disabling of core product features.

* Capping this off, Forum 2000 was a landmark event in the evolution of Windows Server and introduction of what would become Hailstorm in an effort to rebuild Microsoft as an innovator in the internet era.

* PaulMa retired from Microsoft after having had an incredible influence on the company’s operating systems, platforms, and enterprise transformation.

It was also the start of SteveB’s tenure as CEO. Many believed this would mean little or no change given how SteveB was known widely as the “third founder.” SteveB would lead sales and marketing leadership and overall company execution. BillG would lead on technology vision and strategy. This seemed a formalization of what we always felt was the case. On the other hand, how could someone so different keep doing things the same way?

Earlier in the Spring of 1999, there was a BusinessWeek cover story about the remaking of Microsoft. It featured a photo of Bill and Steve together and the subheading “While Bill Gates plots strategy. . .Steve Ballmer shakes up the culture.”

With so much going on, Steve’s first reorganization as CEO seemed relatively minor even expected given how the sales force he created reorganized almost yearly. It didn’t seem like much of a “remaking of Microsoft” as the headlines touted months ago. There were some new people, but the big changes were in financial reporting.

Jeff Raikes (JeffR) returned to Office in the role of group vice president of the soon-to-be-renamed Productivity and Business Services (PBS) division. It was noteworthy that the name included services as per the end of 1999 strategy mail from BillG. JeffR was among the most tenured executives and led the original “Office” organization, the Office Business Unit, OBU, home to Word and Mail. Jeff joined Microsoft in 1981 when the company was 100 or so people, recruited from Apple by SteveB for a product role in Apps, where he led marketing for the original wave of Macintosh applications (and also shared a house with Steve for several months). On his PocketPC he used to keep a “days at Microsoft” Pocket Excel sheet he would open up when talking about how long he’d been at the company. Jeff was frequently mistaken for BillG, as both sported the requisite Microsoft uniform of loafers, khakis, and collared shirts, but it was the ’80s plastic-rimmed glasses that sealed the deal. He grew up in Nebraska, often describing his beloved family farm, an aerial photo of which hung in his office. Before Apple, Jeff attended Stanford. Jeff was the earliest of advocates of pen and tablet computing, leading those as part of Microsoft’s first foray into what was then called Windows for Pen Computing, which was also my first booth duty demonstration using C++ to code for a pen. Jeff also wrote an early memo describing the scenario that would become Excel pivot tables.

Prior to leading PBS, JeffR was the leader of the global sales force, having taken over for SteveB upon his transition to president. He pioneered the mid-year sales review process, which became a staple of the fiscal year planning process with its all-day meetings held through the entire month of January, all around the world. Among the sales team, Jeff was a legendary leader and stood shoulder-to-shoulder with SteveB in the evolution of sales at the company.

With his success in the field, Jeff was more a product of the SteveB perspective on problems and solutions owing to his most recent experience scaling the enterprise field sales organization. As Bill’s longtime friend, he was probably the only executive that was equally well-versed in both BillG and SteveB.

Jeff brought with him a team of support personnel. There was even a chief of staff, a role standard in the field but foreign to the product groups. This was hard to escape notice as we had quite a few offices and a big conference room taken offline (reserved) when in 2004 we eventually moved into the new building 36 that we had fought hard to occupy. Part of assembling the staff ended up taking a good chunk of the top floor of Building 36, which was designed to maximize space for the team, including window offices and already maxed out with the dev team. Space was always the subject of intramural skirmishes.

As part of the staffing of the PBS organization, for the first time, the Office group had substantial and dedicated finance and HR teams front and center of the organization—a seat at JeffR’s leadership team meeting. Some little things that were normal in the field seemed awkward or at least different in the product groups—like routine emails drafted by a staff member to be sent by Jeff for various planning or process tasks or scheduling meetings months in advance. JeffR scheduled everything, so spontaneous chats or walking by the office to talk became less the norm. Instead of PeteH stopping by my office, CollJ (our executive assistant) would get an email from JeffR’s assistant “Can you make sure your exec is available for . . . ”

It was natural though not necessarily mature of me to be skeptical of seemingly trivial changes, but these took place in the larger context of SteveB changes. I was not sure the new processes were consistent with a product-development team culture that was casual, ad hoc, and direct, but perhaps that was the point. During the transition I recalled a story that a former SteveB field staffer told me after he moved to Office marketing. He described how when SteveB moved from the Windows HQ product group to lead Sales, SteveB shifted his hardcore perspective on budget accountability. He changed to believe the field should be responsible for marketing dollars rather than the headquarters (product) group that needed additional discipline, a complete reversal from his days in HQ. As SteveB changed perspective, the problem area moved too. I started to feel we were a problem and Jeff’s role was to fix something. I wasn’t sure what or who was the problem.

Almost right away, JeffR pushed us to better equip the field to sell a big vision for the future of knowledge workers. This had been a long simmering tension point around Office, where I always felt squeezed between making sure we did not cause problems with customers timing Enterprise Agreement (EA) sales and customers wanting to know the future so they might sign up for an Enterprise Agreement. There was always that looming problem of future releases sounding so exciting, customers would choose to wait. Office was under a lot of pressure to get customers to deploy the current version and not wait. It seemed logical then talking about the future would only slow down deployment. This was clearly something that needed to be fixed. In fact, there were echoes of the SteveB 100 one-on-one meetings where he pushed me on this topic. Overall products were still late to market, and we’d just put ourselves out there massively with the expectations set by Forum 2000.

What the field wanted were more materials like Forum 2000, not better demos and whitepapers about Office 2000. The new head of Office marketing explained to me “when I used to work at IBM, we sold more products today based on slide decks about the future, then on any demonstrations of what today’s products actually did.”

I still admit I have a difficult time with that logic, but I am grown up enough now to know it is the reality of enterprise selling. I was uncomfortable selling the future. I was forever hung up on making promises we could not keep, or at least were not sure we could keep. I also felt selling the future was fraught with opportunities for misunderstanding. I’ve seen customers extrapolate features in directions we’d never go. It is obvious in hindsight I was just an engineer and naïve to the ways of sales. I was stuck feeling too high integrity to sell. I was silly.

There was one exception. We found a way to craft our own version of the future that was so far removed from product specifics, that it could not be mistaken for future product versus a futuristic vision.

To show customers (and JeffR) what Office was going to be like, we created a whole experience, almost a Disney-esque Future World of Productivity. MikeAng (now leading product planning) and the design team set up an Office of the Future. The team literally built an entire onsite immersive experience called the Center for Information Work. It occupied several large rooms (2600 sq ft) in a space next door to the Executive Briefing Center. Inspired by the soon-to-be blockbuster film Minority Report starring Tom Cruise (dystopian vision aside), the CIW offered guests a giant wall projecting status of the business—metrics for manufacturing, orders, and more. By a careful combination of scripting and clicking of wireless remotes, the demo revealed wall-size status reports, alerts, problems, and resolutions.

The CIW had a mock-up of an airplane cabin, long before there was Wi-Fi. There was a car of the future, where work and important decision-making continued en route, something that was just starting to take hold with wireless headsets, BlackBerry phones, and PDAs. Mike had listened to me go on and on about my new Toyota Prius hybrid and how futuristic it felt with an oddly mounted gear shift and big touch screen, so he secured a Prius dashboard and front seat, making the auto portion of the exhibit forward-thinking (and for me, super cool). Mike briefly regretted humoring me when SteveB’s main account, Ford, showed up and gave us grief over the car choice.

There were several workstations at the CIW with a wraparound, curved, 180-degree-view display, with the screens partitioned for monitoring activities, work, and collaboration. Curved displays weren’t available to buy but, working with display manufacturers, a curved perspective was created by stitching together flat screens with no bezels—innovative at the time.

The centerpiece was a Microsoft Research project called RingCam developed by Anoop Gupta’s team (AnoopG, who was also a BillG technical assistant), which was a combination of hardware and software for conducting remote meetings, in 2000! The camera sat in the middle of the table seamlessly capturing the audio and video of all attendees. It featured a fancy array microphone that combined with software to detect the speaker and switch the video image to them. At each chair in the conference room there was a Wi-Fi-connected Tablet PC. The PC was an integrated part of the demonstration—documents were signed, spreadsheets were examined, and notes were taken on this device of the future. As if to emphasize the permanence and paramount importance of tablets, the conference room table featured integrated, angled stands for the tablets designed for hands-free viewing and notetaking.

For the first time, I felt like we had an opportunity to get ahead of the constant demand for the future of Office. We revealed no dates, no specific features, but successfully put forth a vision for the seamless use of technology to enhance collaboration, improve decision-making, and integrate data into daily work.

Over the next months, CIW became a meeting place for CEOs, heads of state, VIPs, press, and customers considering Enterprise Agreements visiting Microsoft. Soon there was a team that ran tours nonstop. Over 1000 customers per month made their way through the exhibit.

We found success for the field by creating a story about what we might build one day presented like a World’s Fair exhibit that in no way could be confused with a product roadmap or plans.

JeffR’s new leadership team embarked on its first group project—to identify areas for growth in the business (the business was growing high double digits, but we were forever paranoid about peaking and the bottom falling out). JeffR and the new finance and business development team engaged a major consulting firm to develop a market map for the whole of the business productivity space. Where was all the money on business software going? This project became known as the opportunity map as we crafted a vision for PBS—not a vision like Office or CIW but a plan for determining what new categories of software to enter or serve.

Outside of Microsoft broad horizontal tools like word processing and spreadsheets, the software industry was in an expansion phase driven by the rise of server computing and the web. Businesses were building out data centers and adding server-based applications for sales, marketing, finance, human resources, and more. These tools were domain-specific capabilities that often featured integration with Office, particularly Outlook and Excel, and were generally much more expensive per user than Office, though used by fewer people. The opportunity map was designed to capture the amount of revenue flowing to the rest of the productivity software space.

The map, unsurprisingly, looked as much like a set of opportunities as it did like a set of all the tools that integrated with Office or all the tools that weren’t Office. Categories like Customer Relationship Management (CRM) were highly dependent on using email and integrating with Outlook as the user interface. Business intelligence for finance analyzed vast amounts of transactional data from SAP, or Oracle products to be sliced and diced in Excel, even if they worked to provide analysis in a web browser. While the market need existed to solve these product areas and scenarios, we always struggled with bringing to market domain-focused products while also running the risk of competing with partners who were telling their customers to buy Office.

The question arose as to how we would sell any new products. Would we add new dedicated salespeople for new products, bundle those products with the existing EA, or just add features to Office? We could add features to Office, but charging more for them rather than leveraging those features to drive EA renewal and upgrades was something we faced many times. The pull of bundling more and more into the core value proposition was relentless and the path of least resistance. Even creating an upsell SKU by holding back specific features was a battle against just making sure the customer renewed their EA. Equally difficult was marshaling a new field sales process should we have an entirely new product to sell. Everything was a tradeoff against either finding new EAs or ensuring renewals. I had run into this buzzsaw before and was skeptical, even with Jeff’s command of the field, that we would be able to find ways to sell whole new products.

It also didn’t help that most of these market map businesses relied heavily on consulting and professional services, something Microsoft steadfastly avoided. BillG was not a fan of consulting just as he long disliked product support or anything that could scale by only adding more people. As we kept learning, most of the integration with Office was less about the strengths of Office and more about trying to be part of the sales momentum and ubiquity of Office—using Microsoft’s distribution channel potentially afforded by Office. The makers of these tools did not necessarily want more software integration from Microsoft. Rather they wanted to find a way to insert their products into the massive Microsoft sales engine. If this sounds at all familiar, it is the dynamic we hear today time and again from SaaS companies.

Document Management was a market map opportunity that served customers such as law firms and pharmaceutical companies producing huge numbers of documents, requiring a detailed history of changes to those documents. Customers were always clamoring for a solution from Microsoft in the hopes it would be cheaper, or even free with Office. The existing market was a typical domain-specific product with high prices, low volume, requiring consulting or value-added resellers.

Aiming to enter this market while also broadening or redefining it, a server product under development in a different organization since 1998, Tahoe, planned to cater to the new space of knowledge management, a growing category of software for white-collar workers. The capabilities planned for the first version included managing a company’s Office documents, collaboration, versioning, profiling, and security. These features were to compete with products used in document-heavy professions such as legal and research. Tahoe was also going to be a server for an intranet that supported professional content management tools, web search (like Yahoo but for your own information), and more. Tahoe was going to do quite a bit, perhaps too much. Jeff Teper (JeffTe) led Tahoe and this new product team.

Tahoe, a codename, was a good example of a product arguably designed from the field sales organization out. As an example, at one tumultuous presentation to sales leaders I attended, Steve was anxious backstage to deliver a message to the field that Redmond had heard his calls for an Office server. The work we had done with Office Server Extensions and FrontPage in Office 2000 was not enough. We needed a product for the new generation of Chief Knowledge Officers (a new job big companies were creating) to compete with Lotus/IBM Notes (now called Domino). He knew of the Tahoe plans, but it didn’t seem like enough. There were existing plans for other products with codenames (Grizzly, Polar) and even a side project known as “Digital Dashboard”. In a classic reaction, he was saying we needed more, and sooner.

In what I can only remember as a blur of a tension-filled few moments, all the roadmaps for those products were realigned with components moved from one to another. It was confusing and I had only the vaguest idea of what would get produced. I just knew deciding backstage at a sales meeting probably would not stick. There was a confusing clarification issued after the meeting which remains difficult to parse. I struggled quite a bit because I knew we were in the space with code, dates, and a plan for Office10, but it lacked a certain strategic glow that the other products had. Our execution focused plan could not compete with big visions to dominate an entire ambiguous category of knowledge management. We just wanted to help people share and collaborate with Office. Our products were simple and, effectively, non-strategic.

That glow was that the new product relied on and connected our entire server product line: Windows Server, Active Directory, Exchange (including the new release codenamed Platinum), and SQL Server. What the field and strategic people loved was that the knowledge management from Microsoft used (or required) all the servers too. Such strategic connections were great for efficiency of sales resources and messaging. The whole package could be bundled up as knowledge management and the sales process focused on that high-level message, and not product-focused messages across five different areas. This approach spoke to CIOs and their strategy, not to line executives and execution. In a sense, this approach solved for knowledge management by creating another bundle, but not one designed and built together.

That such a product would be next to impossible to deliver and almost certainly fail to work well, was unfortunately a secondary concern.

In parallel with Tahoe (and the other products), the Office server we were building for Office10 had already survived a tumultuous run-up to get to solid plans. We based the project on FrontPage and the solid market foundation we had built. To handle key scenarios, we needed an additional place to store data beyond standard Windows file servers. For example, customers might want to label a document for marketing and another for sales and then quickly sort or select documents for only one category. The obvious solution to this was SQL but we were organizationally much closer to Exchange, the mail server, especially because of Outlook. Selling Exchange was slightly more important than selling SQL, owing to the battle with IBM/Lotus and the long-term advantage we would gain from an Exchange win.

We spent months going around in circles trying to make Exchange work. At one point I had a showdown with the development manager leading the incubation, MikeKo (an original Excel developer working in the FrontPage team), who was dead set against using Exchange. He would have known, because he was also the original development manager on Outlook. I couldn’t even get him to experiment with Exchange, which left me to defend our non-use of Exchange to the various executives involved. It was part of my job but not pleasant. Of course, I knew he was right, and I was trying to at least bring data to our decision. He thought I was foolish for even considering pushing Exchange on him.

The innovation underpinning our server product was a simple database, a list. Everything was going to be a list. There were lists of people, lists of dates, lists of announcements, lists of documents, lists of comments about documents, even a survey/poll feature for developing custom questionnaires to use, and more. Each list had all the same capabilities in that lists could be customized with different columns, sorted, filtered, and in general treated just like one would treat a list in Excel (or the Access database) while doing all of this from the comfort of Internet Explorer or Netscape Navigator.

We also had features being developed separately to publish office documents to a web server and maintain discussions about them, receive email notice when documents changed or were added (today we call these notifications), and more.

Though we started off with multiple teams, we reconciled the different approaches and arrived at one single plan. We called the product OWS, for Office Web Server (no exciting code name). We were deeply concerned about cost and complexity to deploy it, so we also made sure it worked with the free version of SQL, thus maintaining the free distribution of the Office Server Extensions from Office9. Backed by a full server and the full version of SQL, the product could support hundreds of users (including the entire Office team) but was easy and lightweight enough that groups of 5-10 could easily use it.

OWS was incredibly simple, yet wildly powerful. Even today in researching this section, I ran “SETUPSE.EXE” from the Office XP (“Office10”) CDROM on a standard Windows XP computer. With just a few clicks I had a full team web site up and running. Playing around with the resulting product brought waves of great feelings for all that we had built. Office built a server, a really good one.

Much of this simplicity obscures a remarkable program management effort in addition to the engineering work to build OWS. Program management started in the FrontPage team where JulieLar led the creation and incubation of the original efforts. In order to achieve the breadth of features and tight integration with Office, she partnered with another team in Office (the Office Product Unit) that delivered on integration with applications (for example opening and saving files to OWS) and other features already planned by them—this team was led by Richard Wolf (RWolf), an original champion of the concepts behind an Office server going back to the FrontPage acquisition. The connections across the team also included features built in Word, Excel, and PowerPoint. Creating such a highly collaborative PM environment to deliver integrated products was a hallmark of the new Office team, and OWS exemplified the work.

The full set of features would fill a whole other post. The full set of features would fill a whole other post. Even during pre-release press briefings, we would show up with a single laptop to show off a server at a time when server demos required multiple hefty computers. Many demos started in the server and flowed to Word and Excel then back to the browser. The excitement was such for the product that we ended up (through no small effort) connecting Word, Excel, PowerPoint, and Outlook to the server in a variety of novel ways—no one had really connected desktop productivity tools to a web server. When it came to mail, document authoring, presentations, and spreadsheets—the core of business productivity—those desktop files were like islands the internet could not reach. To the readers that wonder why we did not finish the job and do everything in the browser, I would note were still more than 7 years before Google would acquire its first web-based editing tool (Writely) and the Office team starting the web browser versions of Word, Excel, and PowerPoint. The web browser was not yet up to the task.

Apologies for a bit of indulgence by including the following list. Marketing’s final product guide for the release listed four pages of features including:

* Team Web Site

* Lists with sorting, filtering, custom views, notifications via email, import from Excel, and support column types including single line of text, multiple line of text, numbers, currency, date/time, multiple choice, checkbox Yes/No, internet link, picture, and the ability to choose from an item in a separate list

* Announcements

* Events including Outlook integration

* Contacts including Outlook integration

* Tasks

* Links

* Surveys

* Discussion Boards

* Document and Web Page Discussions (discussions within Office documents or about any web page)

* Document Libraries

* Save/Open dialog integration with Office

* Search using Windows web server built-in Search

* Full customization with the new FrontPage

OWS worked easily through a web interface. It even worked with Netscape Navigator, which drove a lot of Microsoft people kind of crazy.

Below is a demonstration I put together. It is running on a Windows XP Dell Latitude laptop from the same era (with typical specs). Everything was installed using the DVD that shipped with Office XP Special Edition (Office + FrontPage). Keep in mind this is state of the art HTML user experience from 1999-2000.

There was a big problem though, particularly with the document library feature. OWS and Tahoe overlapped quite a bit. Where Tahoe targeted IT managers with enterprise infrastructure, Office10’s OWS targeted teams and individuals, though required IT to set up a server and deploy it.

While Tahoe was progressing through its development cycle, Office10 was finishing up. We began deploying OWS to teams and the feedback was incredibly positive. We knew we were on to something.

Despite being asked to, there was no way to reconcile the strategic overlap. Office10’s server was small, lightweight, and had few requirements. It was designed like an Office product in that it implemented a focused set of features, simply. Tahoe was big, had significant infrastructure requirements, and required a lot of work to set up, customize, and integrate with the rest of the infrastructure. It was complex and not particularly suited to end-users. That was exactly perfect for what the field wanted—a big investment to get something working and integration with all the other servers they were selling seemed far more strategic than Office’s previously free server download.

During a one-on-one with BillG he really let me know how he felt. The meeting was set up to push me to reconcile the Exchange versus SQL storage debate. As CSA, Bill’s most critical project was achieving what he called “storage unification” across our products. He wanted to get everyone to use a single data storage engine, eventually called WinFS (a story for another section). In the meantime, deliberately shipping collaboration that did not fully utilize one storage system was a high crime. In the heat of this discussion, Bill said that it wasn’t that OWS lacked strategy, but rather it was “anti-strategic”. It was as if OWS was a net negative for what we were trying to accomplish.

Ugh.

The more we talked things through, the more we found an opportunity—and by opportunity, I mean opportunity for me to avoid a drawn-out battle between conflicting products that created nothing more than grief and a lot of meetings and no happy customers. The more we found an opportunity to avoid simply shutting down a project for lack of strategy and leaving us exposed in the market for what (at least I believed to be) an enormous space in web-based collaboration for regular information workers. The most useful parts of Tahoe, from my perspective, were the ability to search across a company’s disparate information sources, and to manage published intranet content sites and dashboards. We could thread a needle between otherwise overlapping products.

At the market map offsite, having had several heated email exchanges prior, Tahoe and Office (JeffTe and I) crafted a strategy, a napkin strategy—literally. Every company should deploy Office10 OWS for any team to use. All IT needed to do was set up a small server or two, and people in a company could create a team site—inside a company someone could visit a web server and, in a few clicks, have a custom team site up and running in a self-service manner. We started using this internally and it was instantly a hit, so much so, Microsoft IT became worried about the proliferation of all these sites. Just a year or so after shipping, we had over 3,000 SharePoint Team sites inside of Microsoft.

Enter Tahoe.

Every company could buy Tahoe and use it as the portal to all the OWS team sites that would proliferate around a company. The Portal category was gaining steam and came to represent the implementation of knowledge management. The more OWS sites a company created, the more valuable Tahoe became in order to search across them, keep a directory of them, and so on. For huge companies, Tahoe had other capabilities such as published sites for the company with news, information, the ability to search other important corporate information, even emails stored in Exchange, and an architecture to build corporate dashboards that were all the rage with IT. We navigated our way to a strategy of freemium with an enterprise upsell, like so many products in today’s SaaS era. Looked at another way, we created a classic enterprise arsonist-firefighter strategy whereby we at once distribute a free product that proliferates and another product, a revenue positive one, to manage that proliferation.

The SharePoint name, created and secured by the Tahoe team, proved easy to use for both Tahoe, now SharePoint Portal Server (SPS), and SharePoint Team Services (STS), formerly OWS. SPS provided synergy with the server strategy and hot features like dashboards that CIOs wanted. STS provided the departmental and end-user appeal where work happened. I thought this naming to be particularly clever—SPS and STS. I was horribly wrong and when combined with the full name was unwieldy (Microsoft SharePoint Portal Server 2001 and Microsoft SharePoint Team Services, where legally we could not use SPS and STS). This was a classic example of Microsoft product naming. My apologies.

We agreed that SPS would ship at the same time as Office10 as well, which was exceedingly important. Throughout the release we worked to have a unified experience to the degree we could. SharePoint would become a symbol of JeffR’s new organization and the broader value of Office products to corporate customers.

SPS was a perfect product for an era of complex server products. The industry was blossoming with products from companies such as SAP, Siebel, Cognos, and more. Microsoft spent tens of millions of dollars and hundreds of person-years, including consultants, to roll out SAP. The same with Siebel. Such heavyweight products were state of the art in enterprise software. SPS embraced and reflected those attributes.

STS was an emotional product for me. It was the end of a journey that started with making a web page with our specifications for Office9 and using FrontPage running on a server under my desk. The FrontPage team enhanced the server extensions to create the foundation for STS. The product was pulled in many directions for strategic reasons, but we stuck to it. More than once, I had to go to meetings where we debated killing STS because it conflicted with some strategy (Windows Server, Exchange, bCentral, etc.).

The idea of Office extended by a website for each Office user and team was incredibly important simply because it made using Office better. It was also a vision we had from the time we acquired FrontPage—everyone should have their own place on the web where it is easy to keep their work and share it with others. We were clearly too early. As we will see it was not just that the world was not ready, the world was anti-ready. SPS fit with the products of the era that remained top-down, complex, and under the full control of IT.

We struggled to turn what we built into an asset—the company, or mostly the field, thought of Office as the desktop EA. Getting the right skills to communicate and sell a server was not part of the Office sales motion. It was frustrating to watch companies introduce products that did the things we did and receive credit with analysts and press, or even customers asking if they should use them. We were inundated with requests to do business partnerships with team collaboration products all while, essentially, building a good one in relative silence.

The expression my former managed ChrisP used was “magic beans.” It was a way of describing how some people in the company, no matter what they were doing, seemed to be able to summon magic beans and make products look much larger than life. There was something about STS that lacked magic beans.

We had big plans for STS down the road in the next release. STS was the foundation for extending Office to subscriptions and software as a service.

STS was not without controversy on its own. The company had not yet warmed up to web pages, especially as user experience. I realize how crazy this must sound. In 2000, the company was still of the view that the web is the type of experience for “reach” and the “rich” experience is what happened on the desktop. BillG especially was still hoping for a Win32-like experience for everything we did that used the internet. As an example, the discussions feature of STS also worked from directly inside the applications. It was a ridiculous amount of work we took on just to reinforce this view. Other features such as a Tasks list and Contacts List, which were simply trivial lists in STS, were viewed harshly by BillG because those were supposed to be in Exchange and Outlook (we also did the work so they could be accessed from Outlook).

During the traditional demos with the team, Bill got to see SharePoint (SPS and STS) of course as it was a pillar of the release. We left that section of the demo with him grumbling to me in person, “I hate that UI”. Years went by with him saying “SharePoint? That thing I hate.” Every time someone mentioned SharePoint or sent him a link to a SharePoint document (oh, the links did have horrible URLs that were crazy long and meaningless) he would grumble if I was there or forward me the mail complaining about the link or the UI. I concluded this was much more about the idea of a commoditized HTML-based interface than any specific choices for STS, that even today are fairly benign.

Regretfully, STS was oddly lost in the shuffle. CIOs and thus our field were far more excited by the prospects of enterprise-wide dashboards and other SPS scenarios. The team collaboration was almost backburnered. Where SharePoint really made a name was with an army of consultants who saw SPS as a big opportunity for value-added reselling. The fancy web interface for digital dashboards was both slick and required custom programming for every customer. Combine that with the purchase and management of server hardware and there was a great business for consultants. JeffTe and the new SPS marketing team started a SharePoint conference which turned out to be a cornerstone event for the PBS organization and the field loved everything SharePoint.

Internally during the beta of Office10 we worked with Microsoft IT and created a self-service STS. With a single click, any person in the company could create their own STS site. IT would manage it, back up the data, and keep it all running. It was an enormous hit. Every time a team had a project or an event they would create and STS site. Teams that were already managing their own internal web sites with custom hardware and web development were switching. STS was a huge win for IT, who had a new product they could offer their internal Microsoft customers. We had hoped to replicate this at every big customer. Why not? The rollout of SPS, while exciting to MSIT, did not go as smoothly. The search capabilities were slow, limited, and frustrating to use. The dashboards were difficult to create and slow. It would take some time to transition content publishing sites to the SPS model. The high-end document management features did not replace the domain solutions in place. It was tough.

Even as we came close to shipping, all was not so great. Sometimes it can be difficult to really understand success and what was actually achieved.

Around the internet today, Google Drive, Box, and Dropbox are all products in which I see STS (not literally of course). There are a dozen start-ups building products today with the features like those STS had in 2000, even using the “everything is a list” metaphor such as Notion. The foundation of STS remains a key part of Office 365 today, but still more than likely underutilized by customers given the rise of so many viable alternatives or even the difficulty of finding SharePoint capabilities. Of course, a great many people and organizations rely on modern SharePoint as a key place for storing documents and files. As BillG used to say in exasperated moments, “yet another place to put files.” The potential for tools to improve team collaboration beyond file sharing was mostly obscured by the complexity and weight of the whole offering.

Being early is sometimes the same as being wrong. Being in a bundle is sometimes…not being at all.

A bit after launching the whole wave of products, at the annual sales mid-year reviews SteveB was pushing one country on their Office numbers. As I recall, the country manager began to complain that they pushed SharePoint, but it wasn’t landing. The manager said they are doing a bang-up business and the channel (those value-added resellers) and CIOs love SharePoint, but customers aren’t using the product. I froze. I knew for sure I was about to get pounced on by SteveB in front of everyone. Instead, Steve looked at the me then the room, and agreed. He said, “I get it, no one anywhere is using SharePoint.” Others in the room disputed that, perhaps out of concern for leaving a bad impression for the SharePoint brand they loved.

The conversation continued and Steve turned to me and mouthed again “no one is using it”.

He knew. He was right. As popular as the product was, the part we were selling and what led the conferences, the excitement from industry analysts, and reseller activity, just wasn’t what people were using inside of companies. The team collaboration parts of the product, STS, didn’t receive the attention or visibility so those were under-utilized as well. Was the product a failure?

No, the business results were clear. SharePoint all up had succeeded competitively and by expanding the overall push of servers into the enterprise. This wasn’t the only time customers were buying what we used to call shelfware. The Office business benefitted enormously from the upsell of Office Standard to Office Professional. Office Pro added the Access database, another wonderful product with an incredibly fierce and loyal following. The only problem was that it was used by a single-digit percentage of users, even though half and soon nearly all customers purchased it. We didn’t intend for that to be. It was a win, but bittersweet. It can also confuse what success is in a big company.

Microsoft had a talent for creating a success out of a product that still wasn’t quite a success, as if through sheer force of will and the power of distribution. We issued momentum press releases citing statistics in the millions. A single major company logo deploys a mission critical application which we reference relentlessly. We can even garner support of resellers around the world who will gladly take the business we send to them, even if the result is simply a showcase application. SharePoint was even touted as the fastest product to one billion dollars in revenue, which given Microsoft’s revenue mechanisms is an awkward datapoint. These were the tools of the era. Today, the techniques of growth hacking are the norm such as user-interface that triggers use of a feature that may or may not be intended, or defaults that drive apparent usage of features. All of these are used with bundled products, because absent the specifics of customers directly acquiring a product, Microsoft had no genuine indication of market success. The nature of the big enterprise bundle makes knowing reality difficult.

What really matters is if people are using the product naturally (organically) and the usage is improving (not necessarily more, but decidedly more valuable). We lacked the tools in the early 2000s to really know, but SteveB’s intuition was never doubted. Today we think of this as lacking a clear understanding of product-market fit, a state of existence when the market literally pulls the product out of the company.

We did have exciting moments with STS to be sure. We had an inbound support incident from Japan where a customer was hitting limits for how many documents could be added to a single folder. We had not tested it with more than thousands and learned the customer was unable to add over 100,000 documents while converting all their file servers to SharePoint. Yikes.

The lesson of the bundling things together (STS bundled with SPS, SPS effectively bundled with Exchange and SQL) should have been clear to me by now, having lost the battle over Outlook and soon some other products. I should have admitted defeat and recognized that new things go in the existing product bundle and the economics always make sense—meaning that not charging more doesn’t matter because customers continue to value what they paid for already. We just really dislike building shelfware. Winning with shelfware doesn’t feel like winning.

Every time we were deficient competitively it was to an unbundled product. Even our own unbundled businesses of Visio and Project were almost one billion dollars. Even worse, the unwieldy size and scope of the Office bundle all but guaranteed most customers would never know or experience most of what we do. That’s the fate of most every successful bundle in business software from Microsoft, Oracle, Adobe, SAP, and more. Any success, or defeat of a competitor, comes from an overwhelming mass of software. I was simply naïve to think customers don’t appreciate free, which after all is the same as adding more to the bundle means. I eventually came to think about this as customers paying $300/year for Word, Excel, PowerPoint, and Outlook and everything else was just free and of little ascribed value. The very reason new or startup competitors can win is because there is a price attached so customers know about a product.

With a bundle as features are added and customers keep buying, the value of the bundle appears to be reinforced. The act of bundling is correlated with growth, but there’s no causal link. Conversely, when something is not bundled but the entirety of the sales motion is with the bundle, then the company concludes the unbundled product was a failure on its merits. Again, that is only a correlation not a causation. The presence of growth hacking and so-called vanity metrics distort available metrics, causing even more clouded judgements. Bundles make for great value and efficient sales engine but make it extremely difficult to know if you’re doing the right thing or building a good product. Bundles make it easy to be lazy when it comes to building a fantastic product. Bundled products don’t have to be great to win, just good enough.

I once vented to BillG about this, and his view was more sanguine. He said to think of the whole as a portfolio and to just make sure each release that the total value was what it needed to be. Bill was big on the portfolio approach to management.

In a similar conversation, SteveB was also right about the fact that sometimes the bundle wins, even with an inferior product, because the winning product is not just a product but the value of the product, distribution, and ecosystem around it.

The product confusion did not end. The Windows Server team that sold file sharing servers was deeply concerned they were being pushed out by STS, which did provide a much better way to share files. After many rounds of discussion, the best course to solve this strategy problem was to include STS in Windows as well. More distribution is better I thought. Due to antitrust scrutiny of any bundling choices, we ended up renaming STS to WSS, calling it Windows SharePoint Services. What seemed very clever only further served to marginalize or fracture the product.

This was killing me. I could not figure out what was going wrong or what I was doing wrong. It seemed to be so hard to get traction bringing this to market. I know not everyone shared my view of how cool STS was. What was cool was being measured differently. It was like we valued momentum or strategy more than usage. It couldn’t be that building more complex products that were harder to use and more difficult to deploy and manage was the right answer?

At times I wondered if I personally lacked magic beans, but I didn’t obsess about it. I was able to guide large products, lead teams where people were generally happy (as measured by the ever-present MS Poll survey on employee satisfaction, which SteveB re-emphasized significantly), and to get done what was promised without much dirt flying. None of my managers ever commented on the innovative work the team accomplished—things like SharePoint—or the risks we took, like how we shifted the team to build Office, or even the Office Assistant (“Failure is good,” BillG said often). Rather, the conversation was always thanking me for keeping the trains running on time. Yes, it was great Office shipped on time when almost nothing else did, but it was so much more. The team deserved credit for more than just good at shipping.

My mentor Jeff Harbers and I were once talking and he offered me a way to think about this. Leonard Nimoy’s autobiography, I Am Not Spock, detailed all the things he did besides that one role—that one role everyone knew about. Many thought he begrudged Spock and was not appreciative of the role like fans were. I felt as though shipping was cool, but the team, and I, were so much more. A decade after his original book was published, Nimoy wrote I Am Spock, in which he embraced the role as part of him and explained how people misunderstood the first book. Later Jeff Raikes even lifted my Spock analogy in one of my performance reviews. It resonated. I reached peace thinking about that duality.

Later, working on Windows, I completely embraced it.

On to 066. Killing a Killer Feature (In Outlook, Again)

Microsoft went through so much in the first year of the millennium. It began with SteveB taking on the role of CEO and BillG taking on a new role as Chief Software Architect. Over the first months of the year a new set of technical leaders convened under the direction of Paul Maritz leading all of the product groups to define essentially the next Windows. The group was producing the plans for NGWS, next generation Windows services as outlined in memos from BillG and SteveB. The DOJ trial was complete, and we awaited the verdict, but everything we did was looked at through the lens of the implications of the trial. At every step we were asked if what was going on was a result of the trial, anticipating an outcome, or designed to work around what comes next. Personally, I was just getting my footing as an executive and the leader of Office and just figuring out what it means to be leading such a big part of Microsoft. I still had so much to figure out and was definitely worried about leading the train off the tracks.

NOTE: I really want to offer a big “Thank You” to all the paid subscribers. It takes a lot to take the time to support the work materially and while the proceeds of this work go to registered non-profits in the US, it still means a great deal that you’re paying for the work. Many subscribers are about to hit their one-year renewal and I wish to thank you in advance (and welcome new subscribers). As planned, there is almost exactly another year of posts planned—and for many this is the extra-exciting stuff including what’s coming with SharePoint, Outlook, the Ribbon, Windows 7, Windows 8, Surface, and many controversial (at the time) topics like Courier, including today’s section on NetDocs. THANK YOU!

To celebrate the anniversary, please consider sharing this link for a discount on the yearly subscription. https://hardcoresoftware.learningbyshipping.com/anniversary

Back to 062. Antitrust: Split up Microsoft and 063. Managing a Verdict

The demonstration within the multi-hour series of keynotes was billed as a “sneak preview of something that hadn’t been demoed before. . .technology that embodied the dot net user experience. . .this is real code. . .this technology will apply very broadly in the future across Microsoft products such as Windows.NET [pronounced Windows dot net], Office.NET as well as the consumer subscription service.” What followed was a 15-minute demonstration of word processing, spreadsheet, email, calendaring that looked like Office. The demonstration was easier to use, sleeker, and more connected. It featured enthralling technologies like “universal canvas” and “XML”. What’s not to like?

Within a news cycle the technology demonstration had ballooned to Office.NET and was the future of Office. Within Microsoft, especially in Systems, nothing was higher praise than being the future project and conversely nothing was worse than being the past. The world of dueling code names had been brought to Office, except now it was Office.NET and whatever I was working on, aka Office10. What had been shown was being built by a separate team, an organizational peer of the newly christened old Office.

What was this and where did it come from? Was anyone building a product called Office.NET? Was this planned? I certainly knew the code being demonstrated, but the idea that it was presumed to be the future of Office was newsworthy, even though we did not say that directly and had not intended to leave that impression as far as I knew. Nobody wants to Osborne the most profitable part of Microsoft (a reference to a well-known microcomputer company that went bankrupt preannouncing a next generation product). Weird.

Starting in early January of 2000 coinciding with SteveB’s promotion to CEO and BillG assuming his new role of Chief Software Architect, BillG and PaulMa began working on a series of strategy offsites, meetings, brainstorms, memos, and more called Next Generation Windows Services, or NGWS. There was even a new leadership team formed called the TLT, Technology Leadership Team. Everything was kicked off with memos from both BillG and SteveB highlighting NGWS. BillG explained in a memo Opportunities in the “Software Decade” that NGWS was a bet on par with the graphical interface in both the transformation and opportunity. By now, I was seeing this as a familiar playbook. If you want to say something is big, then compare it to the graphical interface. SteveB also had a memo, Changes and Opportunities.

These memos, Bill’s detailing the technology at a very high level and Steve’s articulating a customer and business focus put forward an innovation agenda for the company. The goal was to let Microsofties know the company was committed to innovation, especially with the rise of “dot com” companies and the huge valuation of anything internet in the public markets. It would be a few months until the market corrected itself, but Microsoft at this juncture was generally in a defensive posture. A broad re-branding was intended to create a new narrative for the company, supported by a next generation of technologies designed for the internet from the ground up, at least starting from Windows.

Just days after Bill’s memo, there was a call for participation in the NGWS planning sessions. A detailed series of offsites and meetings were scheduled. Literally, the invitation stated the work was to figure out the details of NGWS as introduced in the memos.

Please consider subscribing. New subscribers can use this link for an anniversary promotion discount.

In other words, we had a brand before we knew its meaning. That is not entirely fair because there were at least two key strategies under development. A series of projects defining consumer internet services such as email, calendaring, and identity were being developed by a group of the most senior leaders previously of Windows NT and others from around the company, an effort that would later become known as Hailstorm—consumer-focused experiences that also provide a platform for developers. A second effort encompassed the creation of a new programming platform for building internet applications on the server, which was just becoming known as .NET (dot net). This initiative included a variety of tools and platform work that built on the lessons from the first generation of internet applications.

To confuse matters, the .NET branding was starting to be picked up by a range of groups and products, including the next release of Windows NT Server which was sometimes referred to as Windows.NET (originally codenamed Whistler, then later Windows Server 2002, then finally Windows Server 2003). The .NET name was also used for the APIs and programming tools which would collectively be called the .NET Framework, for programming both servers and desktops. If you’re confused reading this, then you were not alone. NGWS was an umbrella term for everything, and .NET was intended to be a technology term, but we sort of ended up with two umbrella terms. The .NET branding was one of the more chaotic and self-inflicted product naming efforts (Was it .net, .NET, or .Net? Before or after the product name? With a space or without?).

Like BillG’s previous memo on software as a service, this memo also lacked any mention of Office. I was beginning to see a pattern. Only now that I was managing Office I started to wonder if I was somehow contributing to this. Whenever I reviewed drafts of these memos, I did not seek to include Office out of a reflex to fly under the radar and to avoid making promises for work that was not even underway, a strategy reinforced by my time working as BillG’s technical assistant. The team always noticed, and I found myself doing my best to explain the virtues of being left out of the strategic fray. Should I have lobbied or been more forceful about including Office? Many would be naturally inclined to run towards the limelight, but so far in Microsoft’s history that proved to be less than helpful. The Cairo OS project was a top-of-mind example.

PaulMa and the platform teams planned a strategy presentation for the press and industry analysts detailing Microsoft’s internet-centric developer strategy. Originally scheduled for early June 2000, the event was delayed several times because of the looming court ruling in the antitrust trial. The NGWS working groups welcomed the extra time. The evangelism efforts did not slow, however, and the first half of 2000 was a steady stream of stories about what NGWS might be along with the implications of the looming court ruling on NGWS, or perhaps speculation that NGWS was an effort to end-run the potential court ruling.

The Windows team generally loved these strategy days as a key part of the culture. PaulMa would often describe them to me as a “forcing function,” which meant a way to coalesce disparate groups into a shared plan. In this case, the planned event would force upon us a collective definition of NGWS.

The industry loved these events too. These were made-for-press events. Stories would run describing what could be announced in the lead-up (called curtain-raisers) and after the event there would be ample analysis. As was almost always the case, the event would gain a nickname or acronym. The event almost always included a new strategy with its own name or acronym. On the heels of Internet Strategy Day and Windows DNA (Distributed internet Architecture), the press was anxious to learn what else was on the way. Frequently, such event days would get scheduled with only a vague idea of what would get talked about and shown. This was one of those events.

The weeks leading up to the event were chaotic and high stress. While the goal was to present a coherent strategy, the process of creating the strategy was more important—the forcing function. This was how Platforms came together as a team. Whether a PDC (Professional Developer Conference), a workshop, or a strategy event, Platforms used the process of creating the presentations the same way Office used memos and the vision planning process. Only Office spent months and involved a broad cross-section of the team across disciplines whereas Windows spent weeks and usually involved the key people, however that might be defined. Instead of detailed plans and schedules like we created in Office, the output consisted primarily of bullet points and architectural diagrams in PowerPoint.

Dubbed Forum 2000, the event proved a seminal moment in the evolution of Microsoft’s platform and quickly came to be known as .NET Strategy Day or .NET Day, and SteveB would refer to it as “most ambitious undertaking since Internet Strategy Day in 1995”. The event aimed to be almost a “mother of all demos”, in reference to the legendary 1968 demonstration of the first graphical interface, hyperlinks, video conferencing, and mouse.

At this point, Microsoft’s approach to strategy presentations was adept at mixing a combination of BillG-style architecture slides with short and slickly produced video vignettes complete with keyed in screen mockups. The series of scenarios envisioning the future of software enabled by .NET formed the heart of the strategy articulated at Forum 2000. They featured the gamut of nascent technologies that were frequently talked about including tablet/pen computers, handwriting, wireless, voice control, video chat, location awareness, presence awareness, notifications, mobile devices, and so much more. The scenarios and designs had a decidedly consumer feel including the bubbly buttons and logotype used in MSN.

There was a slight problem in that the gap between what the audience saw in those demos and what any team might have been working on was, well, significant. It was not that many technologies were decades away from possibility, but only bits and pieces of a product were being worked. The role of a platform strategy is to inspire, however, not necessarily detail everything that is available in short order. Like the 1994 Information at Your Fingertips keynote, these sketches of the future were prescient and designed to create a north star for the company (a favorite expression) and even the industry. So while it was a challenge to be so far out, it was intentional. Unlike previous visionary presentations, Forum 2000 was far more specific in terms of product and roadmap. That was the problem.

Today many look at these presentations and the underlying products that emerged as evidence of many ideas where Microsoft was early, but for one reason or another fumbled in the transition to the modern world. It would be fair to say Microsoft was early to many shifts over the years, but as was so often the case being early ends up being wrong as well. When one is early and fails, the problem was usually that the culture or technology underpinnings are not yet mature enough to support the vision or the market was simply not ready. One could go through each of the technologies shown to realize the decade that would be required to bring them to market. Tablet PCs required screens and processors that did not exist. Handwriting recognition had been stuck at a level of reliability that was more frustrating than useful. Mobile devices would undergo a huge transformation with touchscreens and ubiquitous data connectivity. The services talked about would ultimately arrive with an entirely different architecture than Microsoft was building out at the time. Technologies such as XML would be widely used, but as commoditized as plain text files have always been and confer no real proprietary advantage as Microsoft hoped. Other technologies, such as virtualization that were key to the early cloud era had been rejected and would not play a part in Microsoft server strategy for another 5 years. Early efforts tend to be pointed in the right general direction, but the small errors or incorrect initial assumptions compound over time and ultimately diverge far too much from what eventually makes it to market.

Strategically, the comparison to the transition to the graphical interface was front and center and was used several times throughout the presentation. Our shared desire to repeat that transition and the success that followed provides evidence that being early is good. Windows arrived before the computational power and memory capacity could run the software we built. Taking time for technology to catch up did not deter us. Perhaps what would ultimately trip us up, however, was the grandeur and interconnectedness of our collective plans that left little room for execution error or for influences from the outside world and what was transpiring on the internet at a rapid pace. As many would note critically following the event, it was still about Windows at the center and to truly be a new strategy the conventional wisdom held that Windows needed to be abandoned. It is not at all clear to me that was the mistake, though it does make a simple narrative.

This was the peak moment for the catch phrase developed in response to the antitrust complaint of integrating software into Windows—integrated innovation. We overachieved on integrated innovation in that everything was integrated with Windows as we thought we should be permitted to do. Our defense was also our strategy, and also our technology foundation.

Nevertheless, the industry was excited by all this big talk. If there was a theme to the day, it was innovation. Every section of the day featured an explicit slide calling out innovation. This was a subtle jab at the critics and regulators who felt Microsoft achieved a dominant position and grown subsequently complacent. Innovation highlights were provided for .NET Services, .NET User Experience, .NET Programming, Small Business, and Business Users. That’s a lot of innovation! In addition to the videos, we showed live demonstrations of code: the earliest TabletPC prototype and handwriting recognition, a new browser-based service for small businesses, and the technology demonstration described earlier.

Perhaps more abstractly, the day was about a new era for Microsoft. There were the existing products and from this point forward there were new products built in new ways that would solve the problems the old products had built up. Everything was going to be faster, take less memory, reduce administrative burdens, and provide new levels of capability and convenience for customers. Microsoft clearly divided the world into old and new. That was bold and companies almost always lack the fortitude to make such statements clearly.

Competitively and concretely, .NET (using the term broadly as everyone did) was Microsoft’s answer to Java for server programmers. That was the big battle driving the platforms strategy. Java had captured the hearts and minds of developers building web server applications. The .NET technologies for enterprise software development would go on to create the platform that dominated in-house enterprise IT software, creating a generation of .NET programmers who today are more than comfortable with Microsoft as a provider of cloud infrastructure, even if it is Linux and not Windows. While the .NET programming tools would launch over the next year, this was the first real stake in the ground. On the PC desktop and client, we had won with Internet Explorer, which allowed the vision for the user experience portions of the presentations to move forward with fewer constraints and a focus on what was done on the PC but also supported in the browser—a desktop-first strategy.

It took 18 months before the first product release with the .NET architecture, Visual Studio .NET which was the first product to use the .NET name. The server product line underwent a pivot to support the new capabilities. Ultimately, .NET and its companion and proprietary programming language C# were enormously successful for Servers and Tools and came to define the era of enterprise client/server computing—so much so that most of today’s leaders in IT were products of the .NET era and, as a result, Microsoft created a generation of business IT leaders strongly connected to the company. Much of Microsoft’s strength today in enterprise accounts can be directly tied to IT leaders that rose up the ranks by betting on .NET.

Closer to home, the session on “User Experience” which was really about Office featured a presentation by a group building what instantly became known as Office.NET even though there was a clear demarcation of “technology demonstration”—we loved to think these small changes in wording brought us air cover or permitted distinction between products and directional demonstrations. To clarify, the technology demonstration did not claim to be Office.NET but the roadmap slide of product releases we presented at the time used the name and provided a “2002+” ship date.

The technology came from BrianMac, creator of Outlook, who upon leaving Outlook started up a new team called NetDocs, for network documents. NetDocs reported to BobMu, my manager at the time as well, though Brian and I had not crossed paths all that much since Outlook. We were both focused on what we needed to get done separately.

BrianMac formed the NetDocs team much the same way he built the Outlook team, growing the team to over one hundred in short order. The vision for the product was expansive and included many hot, new technologies. It was also being written in the latest technologies, including the latest magic technology XML (eXtensible Markup Language, which was becoming increasingly popular as part of programming for the browser) and, more importantly, it was using many of the new capabilities in Internet Explorer. XML was also the latest magic beans technology that took on capabilities much greater than reality. Brian had a knack for constructing expansive visions assembled with the strategic technologies as we saw with the creation of Outlook. As with Outlook these technologies were new, unproven, and unfinished. Outlook did quite well.

The scenarios enabled by the NetDocs vision subsumed Office, particularly Outlook, Word, Excel, and more, but with a decidedly modern take. By modern, the implication was that people no longer needed to worry about which Office app to use as there was one single document type, the universal canvas, that worked equally well with words, numbers, graphics, and email, and was easier to use because of that. This was not a new vision and in fact the idea of integrated packages had a history of attempts from both Lotus and Ashton Tate in the pre-Windows era, as well as Microsoft’s Works app (a modest success for price sensitive customers). The all-in-one application was a favorite among the first generation of PC users and BillG in particular who routinely complained about overlap and redundancy across the various “modules” in Office, modules being his favorite way to describe an app in the suite. Would this time be different? Did the processing power and memory finally enable this? NetDocs set out to prove it could.

I was skeptical, but from my position in Office skepticism was viewed by others as defensive and territorial. I wasn’t being defensive. I just didn’t think it could work. Others projected it could be a $1 billion business within three years.

A running joke at the time was that every new product idea somehow included digital photos, and Forum 2000 was no exception. Every demo included digital photos in some form. Digital cameras were the hot consumer item and sharing photos on the internet was becoming mainstream. NetDocs not only included photos, but to illustrate the importance of photos, a product that was extremely innovative but languishing at retail without sales and marketing support, Microsoft PhotoDraw, was reorganized into the NetDocs team. This method of building a new team by acquiring other internal teams and jettisoning their existing product was a strategy employed with Outlook as well. I was a big fan of PhotoDraw and to me it was one of many examples of innovative tools Microsoft created that we were unable to capitalize on because it was too small on its own and too niche to be part of Office—this will become a familiar theme shortly.

There was another running joke that every new product idea being dreamed up somehow also included electronic mail—email was the anchor of the internet and became a big deal for AOL, Yahoo, and MSN. Microsoft was a clear email leader with Exchange, but that was for business. For consumers, Microsoft’s MSN division acquired Hotmail in 1997, the first web-based, viral, and free internet mail. The number of email users on that service was approaching 100 million, when the entire internet population was roughly 300 million. NetDocs also became email. That should not be a surprise given the roots of the team and leaders.

Photos, email, calendaring, XML, word processing, spreadsheets. . .that’s a lot, a lot to like.

NetDocs also enabled a new subscription business model. There was nothing particularly technical about doing this work, though convincing customers to rent software (as people thought of it at the time) was new. The team was working on a new technology to provide seamless updating of the NetDocs Windows desktop application over the internet. Seamless updates might convince customers of the benefits of rental over ownership as the product could be enhanced without purchasing anything new. Customers were struggling to deal with updates, most of whom were not yet able to use the Windows Update service that is now standard on every PC.

Given my early experience getting the first version of Outlook to customers, I remained skeptical of NetDocs achieving all that was sketched out, especially without the kind of constraints being part of the Office release imposed on Outlook originally. The amount of code to write, the ever-changing scope (and resistance to constraints), the huge challenges of building some compatibility and interoperability with Office, as well as the fragility of the technology foundation—as the latest and greatest always seem to be—were not usually a recipe for success and seemed familiar. The success Outlook achieved, due in no small part to being free and bundled with Office and more importantly the only client for Exchange email, provided a halo of sorts for NetDocs. This is a good lesson in how success in a big company can take many forms beyond customers laying out their cash for a product.

I had not paid attention to NetDocs (nor NetDocs to Office) and now suddenly and without warning, NetDocs was front and center strategically for the company. NetDocs was filling a void in the strategy, at least internally which was that for the .NET platform to be successful it needed a killer Office application. I should have internalized that strategic point going to the NGWS meetings, but I did not. I managed the Office10 project aware of the costs of choosing to lay low—that people would view Office as failing to support the platform or even to acknowledge the future. In an industry (and especially a company) where the next version is always way better than the current version and new platforms always require the leading apps to support them, it was challenging to take this approach.

This old versus new dynamic always creates tensions in a large company. Echoing Innovator’s Dilemma (again), a series of press stories played out over several months. While there were grumblings, overwhelmingly people on the respective product teams were not consumed with potential overlap—Microsoft had a long history of next generation projects that fizzled. When will NetDocs replace Office? Will Office stand by and allow NetDocs to replace it? Will customers be confused? How will the market deal with two kinds of Office products? This was a far cry from the Cairo versus Windows NT, or the Windows NT versus Windows 95 battles that played out over years, at least I thought that to be the case.

During these times the negatives the market perceives of the incumbent are amplified irrationally—software bloat, nothing left to add, slowing growth in the business, and more. Simultaneously, the perceived positives of the new product are amplified irrationally: sleek, modern, simpler, faster, lighter weight, innovative, and new. Microsoft was great at setting up this dynamic. I had been the poster child for old technology and resistance to change more than once (Java Office, component Office, web Office), and while I could brush it off, in the case of NetDocs and Office there was quite a bit of bashing externally of a product that was half of the company’s profits. The internal tension was significant, but not because of a deliberate product competition or organizational competition for resources, but because there’s no way to constructively align the past Office with an ever-expanding vision. Regardless of the strategy, NetDocs could have laid low and first spent a couple of years building a product. It just wasn’t in Microsoft’s culture to do so at this time given the demands to put a big vision out there.

Nothing could stop the Forum 2000 train. This was exactly what NGWS needed. There was broad satisfaction with the event, even though ongoing legal challenges clouded the strategic presentations and strategy. The future was .NET everything, including Office.NET.

Deciding to show NetDocs at Forum 2000 was controversial, at least with me, and probably not many others. I was usually the most conservative about showing products or features with an uncertain path to shipping, let alone version 1.0 products built on version 1.0 technologies accomplishing new scenarios that often didn’t pan out. There were also legitimate concerns that word of a modern Office.NET could slow or halt progress on enterprise agreements, in an extremely touchy post-dotcom bubble business environment.

After many email threads prior to the event, NetDocs ended up showing some basic features, such as typing into a word processor-like screen, summing a column of numbers without launching a spreadsheet, and a calendar scenario that used XML technology to merge a personal calendar with a Seattle Mariners calendar. The session painfully reiterated the “technology demonstration” aspects of the demo and never used the phrase Office.NET, though the prominence of Office.NET on the roadmap left few dots to connect.

To mitigate the risk to enterprise agreements, the demo was said to be relevant to Microsoft’s new small business offering, briefly called bCentral. For almost another decade, the Office strategy for the web and internet targeted small business starting with bCentral and always using branding to show a distinct separation from Office for enterprise. This compartmentalized a new approach to the less risky market segment where Microsoft had more upside than downside. For big business, they were pushed to see things through the lens of Windows Server and the software housed in company data centers along with desktop Office, all available with an Enterprise Agreement. This was a defensive approach but was consistent with how customers thought about Microsoft products. Word and Excel were indispensable tools for small business, and increasingly Outlook, especially with many add-ins, was the preferred tool for small businesses to manage sales and customers. Customers could not buy Exchange and set up Windows Active Directory and file/print servers fast enough. In practice, operationalizing the transition outlined was more practical and somewhat defensive, echoing the Innovator’s Dilemma.

The Wall Street Journal was quick to pick up on the potential challenges as well in a story by Rebecca Buckman shortly after the event “Microsoft Readies a New `Office' While Renovating the Old Standby” where she wrote:

What does a company do when its single-biggest product is in danger of being eclipsed by new technologies?

If that company is Microsoft Corp., and the product is Office, it sets up a stealth team of crack engineers to dream up a brand-new version of the software suite -- while continuing to crank out the old standby. It's a tough, two-track strategy that has pitted a "today" development team against a "tomorrow" team, as one person close to the teams puts it -- and it's still unclear, he says, "how today and tomorrow will meet."

As we know now, the danger of being eclipsed did not materialize. We deliberately and somewhat nervously made that bet, as previously described. The teams were not pitted against each other, not yet anyway.

PCWeek reporter Mary Jo Foley loved the NetDocs story and wrote about it many times. By the end of the year, a few months after Forum 2000 she said in a story “Netdocs: Microsoft's .Net poster child?” where she described the product as:

Netdocs is a single, integrated application that will include a full suite of functions, including e-mail, personal information management, document-authoring tools, digital-media management, and instant messaging. Microsoft (msft) will make Netdocs available only as a hosted service over the Internet, not as a shrink-wrapped application or software that's preloaded on the PC.

Netdocs will feature a new user interface that looks nothing like Internet Explorer or Windows Explorer. Instead, Netdocs will deliver an integrated workspace based on the Extensible Markup Language (XML), where all of its application modules are available simultaneously. This interface is based on .Net technology that Microsoft, in the past, has referred as "Universal Canvas."

There was nothing sinister or even that playful about what was going on. It was just. . .going on.

We were busy, and well into building Office10. At the very least, until NetDocs was usable (self-hostable) by more people, the best thing to do was let them keep writing code and hope they stopped trying to recruit people from Outlook.

NetDocs versus Office was just going to simmer for a while. There was no way around that. Because we were in the midst shipping (eight months to go) and NetDocs now had a deadline of sorts, there wasn’t room to attempt to reconcile the products, have them relate strategically, or really do much of anything. I was happy to work heads down and not worry about it.

Putting Forum 2000 in perspective, SteveB sent an all-company follow-up email briefly laying out the strategy and timeline we were undertaking. He reinforced the huge change by referring to the strategy as “Microsoft .NET” (the space after Microsoft was important), coming very close to rebranding or even renaming the company around this new strategy:

Microsoft .NET will be delivered in three forms: a new user experience; infrastructure and tools; and a set of programmable .NET Building Blocks. This is a long-term strategy, one that will take years to execute fully, so it is critical that we all stay focused - not only on our goal but also on the daily steps it will take to achieve it.

The Office team was focused on Office10. We would worry about NetDocs later.

On to 065. SharePoint: Office Builds Our Own Server

PS: Many readers lived through Forum 2000. Some have shared their own experiences from the event, like this wonderful post from Charles Fitzgerald, Exploring Alternative History. Please share your experiences on twitter or in the comments, especially if your personal experiences bring a different perspective as they well might.

Some additional moments from the Forum 2000 video:

Back to 062. Split Up Microsoft

We received little guidance regarding how to talk about legal matters. I was never under orders to avoid speaking about the trial, though that seemed like common sense. Once the verdict came down, teammates were starting to ask questions, wondering what the case meant for Office. I knew enough to know that absent anything official, people made up their own reality. I was worried that this could become a local press issue, with people talking to friends and friends talking to friends, ending up in the Seattle Times.

I organized an impromptu all-hands in the atrium of building 17. Anyone who wanted could attend. This was the largest space we had without going off campus (also where we presented the Office10 vision). Using a single speaker audio system, I spoke into a handheld corded microphone like a lounge singer. I walked the team through the trial and what had happened, not adding anything that was not already available to the press and public, but simply tried to casually explain the facts. What was Microsoft accused of? What was a monopoly? What does a breakup order mean? The trial team was so focused on the external press that we did not have an internal process, so I did the best I could.

I had little to offer by way of details. I took a lesson from a former test leader on the Windows team—a management lesson that permeated Microsoft, perhaps to the point of becoming apocryphal. David Maritz (DavidMa) was formerly an Israeli tank commander during his army service. His unit of tanks out in the desert would sit there in a defensive posture in the dark of night. If the radio was silent for too long, each of the tanks started to worry something was wrong with the other. Panic might sweep across the unit. David said the way they avoided this was for him to check in with the other tanks and periodically let them know that everything was okay—even though he didn’t know himself. He taught us with that anecdote that even when leaders have no information, communicating something was better than nothing.

In between describing the intricacies of the legal process that would play out over years, people were worried that we were being immediately broken up, as in over the course of the coming weeks a spouse, partner, or roommate might work at “the other Microsoft.” I reiterated that there were still many things that could happen before this order could become a reality, and that much was still unclear.

At least there was humor in the situation. No one in the atrium was clear on the legal goal of splitting up Microsoft between Windows and Office. As engineers and employees on the ground, it seemed kind of nuts. Presumably, the issue was that Windows and Office were working too closely, even illegally, together and that needed to stop.

In reality Office and Windows could barely get anything done together. That situation was literally the topic of every meeting across the executive team. Different schedules, different customers, different system requirements, and more reinforced how far-fetched this idea was. More than crazy, by some measures this could have the potential to be a huge relief. Office might finally be treated as a vendor, like Lotus, which we always believed received better placement at Windows developer conferences!

For a decade there were rumors that the Office team accessed secret Windows source code that no one outside of Microsoft could see and that somehow that was an advantage. There were rumors of APIs in Windows that were secretly used by Microsoft to make Office better than competitors. There was no proof of any of this, though it made for a conspiracy theory. Back in the earliest days of a tiny Microsoft, with just tens of developers on big projects, we didn’t even have the technology to secure code from each other even if we wanted to. Ironically, many on the Office team remember diving in and trying to make Windows products work, not the other way around; whether it was Windows graphics for charts in Excel or printing in OS/2, it seemed that the advantage flowed to Windows. In the atrium, people were asking about this topic, and it brought a sense of levity to an otherwise unique situation because most were not around for the early days of Windows 2 and 3, or even Windows 95.

After a brutal series of motions, briefs, and other legal warfare, a year later on June 28, 2001, a federal appeals court reversed the breakup order, reprimanding and removing Judge Jackson and appointing a new judge. As often happens in these complex cases, the judge, Colleen Kollar-Kotelly, pushed to have the parties resolve their differences outside the court. By September 2001, the plaintiffs withdrew their effort to seek the breakup of Microsoft. By November, the case worked out a settlement, which Judge Kollar-Kotelly ruled served the public interest. There were no issues in the settlement regarding Office directly, though later when I moved to Windows in early 2006 some of my immediate responsibilities included complying with the terms of the settlement, which was scheduled to end in November 2007. We voluntarily extended that by two years, which meant the first release of Windows that I worked on included making sure it followed the consent decree.

While much speculation has gone into how the legal issues impacted Microsoft execution and product strategy, my view, even on the front lines back then, was that by far the biggest issue was not in the workplace specifically, but outside of it. Even though they had nothing to do with them, everyone on the team endured the negative comments about the company and its business practices. That’s where the litigation and scrutiny truly caused difficulty. Consider those holiday dinners and family gatherings where an engineer on the team was called to the carpet to explain or defend Microsoft. It was those endless news magazines that piled up in every household. Similarly, when recruiting college students, I frequently found myself on the phone with parents of candidates walking them through the case and the culture of Microsoft while also defending us.

Those side effects of litigation were more difficult than the specific structural and regulatory remedies.

In just a few years I would find myself on Microsoft’s other side of this case, working on Windows. I would manage the last years of the consent decree, but the real challenge was cultural and bringing us back to the days of doing what was best for customers and not pre-judging every action through a legal process we on the development team were hardly expert in.

On to 064. The Start of NetDocs v. Office