Personal stories and lessons from inside the rise and fall of the PC revolution as narrated by the author. Sinofsky joined Microsoft in 1989 as a software design engineer on C++. Over the next 23 years he worked across many major products and teams including C++ and Visual C++, Office for six major releases ending as SVP of Office, Windows 7 and Windows 8, as well as most major internet services as President of Windows.
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.
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.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit hardcoresoftware.learningbyshipping.com
107. Click In With Surface
dimanche 20 novembre 2022 • Durée 01:26:36
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.
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.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
098. A Sea of Worry at the Consumer Electronics Show
dimanche 18 septembre 2022 • Durée 32:10
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.
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.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
008. Competing With Steve Jobs (the First Time) [Ch. II]
lundi 22 février 2021 • Durée 10:45
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.
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.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
007. Windows 3.0 Buzz
vendredi 19 février 2021 • Durée 13:02
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.
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.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
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.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
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.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
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.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
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.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
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.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
Apple Podcasts
🇨🇦 Canada - management
19/02/2026
#67
🇬🇧 Grande Bretagne - management
18/01/2026
#100
🇬🇧 Grande Bretagne - management
11/01/2026
#96
🇬🇧 Grande Bretagne - management
03/01/2026
#62
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-80SoftCard, 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.
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.
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.
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.
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.
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.
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.
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.”
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.
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.
Découvrez des podcasts liées à Hardcore Software by Steven Sinofsky (Audio Edition). Explorez des podcasts avec des thèmes, sujets, et formats similaires. Ces similarités sont calculées grâce à des données tangibles, pas d'extrapolations !
