Hardcore Software by Steven Sinofsky (Audio Edition)

One of the main challenges in leading a big team is that nothing ever seems to finish—there’s always more to building a team. Even at milestones, one looks ahead and sees more work to do. In the first few months I had been working on Windows so far, we re-organized the team in a huge way and shipped Windows Vista, only to then have to figure out how to plan a product release with this entirely new organization, while building an improved engineering culture. The planning work began in earnest in December 2006 and concluded July 2007. This is the story of those months and what it was like and what management tools we used to develop a product plan for what would become Windows 7.

Back to 087. Reorg! Why Are We Together, Exactly?

SteveB loved to talk about his discussions with engineers as he tried to better understand the company’s execution and culture challenges. He would say “I talked to this engineer on the team, and they told me ‘Look, everything is completely screwed up and everybody telling you how to fix it is wrong.’” Steve would continue to listen to a litany of problems and why everyone was being “dumb” wondering what he could possibly do. Then the engineer would look up and say to Steve, “But I [emphasis on “I”] know exactly what to do and how to fix it.”

My problem was I was also that engineer. I saw the problems and “knew” what to do. Except it was my job and I had to lead the team to fix the problems.

Fortunately, early on there was a set of like-minded engineers who were willing to sign up and take on the challenge of building a culture and now a plan for what comes next. From the very start it was not just me driving the cultural changes, but the set of leaders put in place from our big re-org.

Change across thousands of people, each of whom knows exactly what should be changed, is not a one-time event. Change takes repetition. It takes calendar time. It takes making some mistakes and using those as learning or teaching moments. While everyone was anxious for change, thousands of engineers must be given time to think and reach the point—on their own—of agreeing to a certain kind of change.

Every step over the next few months, from the time of putting an organization in place to starting the real building of products, we (the leaders) would be confronted with two realities. First, we had to remind everyone on the team consistently and repeatedly of the process we were using and how we aimed to work together. Every. Single. Communication. At times it felt like we were reading the inside of the box of a board game at every meeting. Second, every time we made a mistake and didn’t ourselves follow that process, expect someone to point that out and for that to become a moment of humility.

It was a constant push-pull with so many wanting to know what we were telling people to build while we were busy pushing back and saying how we needed them to figure that out. At the same time what we wanted to do would look radically different from the past. It wasn’t a top-down plan. It wasn’t a disconnected set of innovations. It was not about consensus of design as in design-by-committee, but a coherence of a plan. The investments (as we would say) were going to fit together into a holistic product plan across our new organization: WEX, LEX, IE, and COSD. After every step in the process, we regrouped as a leadership team and not only talked about what parts of the process we needed to improve, but we turned that into coaching and more outbound communication such as my Office Hours blog. At the same time, we were continuously adapting to what was understood, misunderstood, and especially challenged when it came to process.

An example of cultural change that was front and center was a desire to match the old Windows team in terms of scorecards or KPIs by automating or operationalizing key requirements. I would be out there talking about vision and scenarios and collaboration—abstract concepts that need to be made concrete by the team—only to find out some people were trying to make a vision scorecard or building an automated testing tool to check if scenarios were complete or tools to red/yellow/green dependencies between different teams. We’d come across this and then would need to course correct and talk about how accountability works without constant monitoring by others nor overwhelming bureaucracy.

Every email and memo, every team meeting, every 1:1 was a not just an opportunity to reinforce the new cultural norms, but a requirement for us to do so. The first and most important test was developing a product plan for the next release following Vista. For us to get to the finish line with a coherent product all at the same time and all on time we would need to get to the starting line at the same time.

First, we needed a product name. By now you know I was never a fan of codenames.

Windows had always had somewhat clever (too clever) code names with layers of meaning. As a consumer of these code names, they neither made for secrecy, as one could routinely read about the release code names in trade press, nor did they make it easy to remember what someone was talking about. “Is that in Nashville or Memphis? I can’t remember.”

Windows Vista was the sixth major release of Windows and it was version 6.0.6000 for techies. So, by fiat I christened the code name of the release Windows 7. I thought I was being the opposite of clever and we could simply move on, as we had done when we picked Office 9. Oops. Immediately I made two mistakes. First, did I reach consensus on this name? Second, did I even understand the ramifications of the name I picked unilaterally?

This sparked a debate that only geeks would participate in (at the time and once the name was made public), which was: How did we count versions of Windows? Technically, this was not the seventh major version, as some would debate. My view: Windows 1.0, Windows 2.x, Windows 3.x, Windows 95, Windows XP, and Windows Vista. But wait, there was Windows NT, and there was Windows 98, 98SE, and Millennium edition.

It turned out there were lots of ways to count and lots of ways to have more than six previous releases or fewer than six. Essentially, everyone could be right. I probably received two dozen emails with different algorithms for counting how many releases of Windows had been done, ranging from “well, it was really only four” to “at least a dozen.”

I stuck with seven.

Crisis averted by executive authority. Temporarily.

The test and engineering system team informed me that we could not possibly “bump the major version number,” as this would cause a whole slew of problems for application compatibility. It turned out many existing Windows programs were bad at checking what version of Windows was running and failed to run if the “major version” (that would be the first digit) was incremented. I knew this from Office 95 when we skipped several version numbers to align all the apps.

Marketing had input too: that we had to make it version 7.0 because if not the press would think we were doing a minor version and then enterprise customers would not see the need to upgrade. So even though the engineering system did not want the major version number changed, the marketing team did.

This whole notion of “major” versus “minor” as the press characterized releases would drive me nuts. It seemed as though a major release was one that broke a lot of stuff and finished late. A minor release was one that worked because it polished features and finished on time. My view, no surprise, would be based on resources. Did we have everyone working on the release or did we peel off a subset of people to work on something less for less time than a normal release? Windows 7 had everyone, 100 percent. And we were determined not to break things. And we were going to finish on time. It was a major release.

I had an urge to quit before we even started. If this trivial thing was going to be so consuming, imagine what the whole release was going to be like. Yikes.

Despite the uproar, we stuck with the Windows 7 code name, and the ultimate irony turned out to be that we eventually stuck with the name for the commercial product as well.

Planning moved forward, but it became clear that there was a new challenge at every step of the journey. There were two sides to every situation we faced.

Some people on the team wanted to be left alone, confident in what they would be working on and that there was nothing to be gained by delaying the start of the work. In some sense this was true because some parts of the product were known. We knew we needed to improve the engineering system, for example, and we knew we would do another turn of the crank on many areas, such as performance, device drivers, and security.

On the flipside, there were the people who wanted to be told precisely what to do, simply because they had frequently and repeatedly come up with ideas only to have the rug pulled out from under them by new strategies, scheduling, or resource constraints. Those people wanted to know what success would look like for them as individuals and on a granular level. The big picture was not their concern.

This made things tough.

It was tempting to remove constraints on the “correct” people and tell others what to do. It would feel quite good to be making progress and to be able to report work is happening, especially to the anxious executive team above me. Even identifying the right teams along these lines would fall into old behavior patterns we wanted to break, mainly, that there were always the elites in Windows who were given freedom to do what they felt was right, while other too often teams fell victim to management processes. I believed that we could do better if we followed the old Shipping Software adage and got everyone to the starting line at the same time. The goal was to get the maximum number of ideas on the table via broad participation of domain experts and create a holistic product plan from that—a Windows version of our Office approach to participatory design.

The planning memo was a tool developed in Office to begin the process of the release and to kick off a participatory design process. Over several iterations we came up with a format that provided a structure such that people could investigate what to build, without having the conclusion in advance and without necessarily having organizational ownership or structure in place. It was planning but without a pre-ordained plan arrived at by execs beforehand or retrofitted from known technology efforts already underway. It was a tool for empowering the team to ensure the best ideas came forward.

The organization needed to transform before we could transform the product and culture, but we would still need to avoid the perils of shipping a product defined by an org structure. Perhaps the biggest change we would make was the transformation of the next level of the organization away from the history of product units to a large group of feature teams of development, testing, and program management. Windows 7 (WEX, IE, and COSD) ended up being about 45 teams with about 1400 software engineers. In addition, there was a design and research team of about 100 people and about 20 product planners dedicated to Windows and reporting to JulieLar. We had a large team responsible for international versions of Windows coordinating the work with translation resources around the world.

The idea of less than 50 teams was important because each milestone would involve a meeting with teams and that needed to be manageable. I didn’t think we could scale beyond that, but frankly I thought we had more than enough by way of resources to build a great product. If we could better organize, we could simultaneously tap more creative energy from within the team while improving efficiency and causing the whole to operate smoothly and pleasantly.

In the process of organizing the team we moved several significant-sized teams to the division that makes Xbox, including the Media Center, music rights management, and the non-platform elements of gaming. Some other teams, notably what remained of Windows Presentation Foundation (Avalon) moved to join with the rest of the .NET Framework, putting an end to a cross-division skirmish. A small subset of Avalon that also moved was building a cross-platform browser-plugin that supported video playback and conferencing, codename Jolt. That plugin would eventually be renamed Silverlight and offered as a competitor to Adobe Flash while also serving as a developer platform for a new Windows Phone. The resulting Windows team became much more focused on delivering and building for Windows and these divisions were excited to have more control of key technologies that did not need to be part of the Windows platform. I was very happy to do these moves.

While some were amazed that we could create $150 billion in market capitalization with only a few thousand engineers, I still thought the team was a bit large. Office created as much with 20 to 40 percent fewer people. I wasn’t there to cut costs and never even thought about reducing headcount. Bloat, inefficiency, and lack of clarity in a product, however, come from too many people especially when poorly organized.

In the abstract, it is easy to see the attraction of small-focused teams tackling problems independent of each other versus a flexible and agile (though perhaps monolithic) group that adjusts to changing needs at scale. In practice, and especially at any scale, the small, multidisciplinary team rarely has an outsized impact in the context of a big business and always finds itself challenged to hire and grow deep engineering talent. Furthermore, when organized in such a manner the teams do not share in a larger mission and as a result the overall product loses the ability to shift resources around as needs arise. If a key feature team needs more resources, the head of engineering (AlesH or BenFa) can load balance across the whole organization without disenfranchising a multidisciplinary manager who would feel undermined by losing their resources to another manager. I was certain this would be important with Windows 7 because the teams had not previously done rigorous scheduling or hit a ship date.

This was a truism based on what Microsoft had achieved, not a theory or abstract concept, and was my rationale for why a structure of flexible feature teams wasn’t a management fad that would swing back in the other direction down the road. Windows was one product, and we would organize and operate like we were building one product.

JonDe, JulieLar, and I, with important contributions from marketing and product planning, wrote the December 2006 memo, Planning Windows 7, outlining the state of the business and putting forth product and business priorities. The planning memo puts a large bounding box around the release but is not yet the plan. It kicks off a process, inviting participation from everyone on the team. Using the familiar Harvard product development funnel, we were opening up the funnel to ideas.

Who knew that hitting Send could be so stressful? Again.

Julie and her counterpart in COSD, ChuckC, would drive the planning process and own the resulting plan, which would be a document called the Vision for Windows 7. Julie, having been part of the process in Office several times, would be the key owner. Julie also wrote an outline of the overall vision process, a primer basically, that was sent and resent many times throughout the next few months. The first challenge was that a good portion of the PM team believed the planning memo was the plan, when it was a framework to think about what the plan could be. To others, this memo and process seemed to be bureaucratic or arbitrary process getting in the way of what everyone knew we needed to do. Out of the gate the need to talk about building a coherent and cohesive plan where everyone on the team was accountable to promise and deliver was our key leadership message.

The planning memo was over 30 pages, but the first two pages were essentially instructions for how it works or “the inside of the box” as we described it—another example of the ongoing repetition of how we will work.

The planning memo is where the business enters into thinking. With most of the team and audience engineers, we would use every product start to reiterate the business fundamentals and what levers were being explored.

It is in the planning memo we talk about the kinds of challenges the financial side of the business face, as we did in Office with respect to enterprise sales. In Windows there were multiple constituencies: PC makers (OEM) representing a huge portion of Microsoft’s business concentrated in just a few customers, developers who make use of API innovations in Windows, ecosystem hardware partners who supply components to OEMs and peripherals to end-users, enterprise customers that run their business by deploying Windows desktops and laptops, and of course consumers and end-users. Also critical was the role the core Windows operating system played for Windows Server. Nearly every aspect of Windows impacts two or more of these directly and generally speaking it was not the type of challenge that had been pushed down to teams the way we were working to do.

The first section of the memo focused on the need of Windows to bring energy and health to the PC business, especially by finding scenarios where home users would have more than one PC and where business users would see value in more feature-rich editions of Windows. Unlike the Office business, the Windows business was much more sensitive to the sales of new PCs rather than the core value proposition to enterprises.

It is worth keeping in mind that “renewed growth” and “health” were somewhat counterintuitive to any business metrics readily visible to the team—Microsoft’s history of paranoia was definitely present in our planning, and that was a good thing. There were no material signs that the PC expansion was slowing. We still had not seen the giant leap Apple would make in “personal computing” with the iPhone that was announced in January 2007. In the coming months (exactly 3 months) Steve Jobs would announce that there would be an SDK to build apps for the iPhone and iPod. Phones were getting smarter, but people were decidedly still reliant on PCs for the internet.

About three-quarters of Windows revenue came from sales directly to PC makers. While we talked about one billion Windows users, they were only our customers in an indirect way. People bought PCs and those PCs came with Windows, which was purchased by the OEMs. Even if a person had a problem with Windows on their PC, support was provided by the OEM and not Microsoft. Effectively, Windows is a business with fewer than 10 customers, but those happen to be Microsoft’s largest customers by orders of magnitude. This idea of a buyer and a user being different parties with different influences on the product development process was quite familiar to me from the rise of enterprise customers in Office. Where in Office we had an ever-present struggle over the needs of the enterprise versus the needs of individuals across the product, Windows had a much more uneven approach. Some teams were extremely focused on OEM customers while others were entirely focused on end-users.

Contrary to most perceptions, the cost of Windows on a new PC (that is the price to OEMs baked into the final consumer-visible price of a PC) was a fairly low percentage of a PC price and the price had remained largely unchanged for years. This would soon become an issue with the introduction of Netbook PCs (to be discussed in Chapter XIII), but by and large the Windows license was both unchanged and a constant source of frustration from PC makers because of that inflexibility. For a variety of reasons, Microsoft lacked the kind of pricing power one might have expected in such a market. This was in contrast with the price of the Intel portion of a new PC, which was much higher and had increased over the years as Intel provided more and more integrated capabilities and provided more pre-assembled parts of a PC with each new processor generation.

PC sales in 2006 were about 240 million units worldwide. That was an astounding number and our responsibility to do the right thing and better things for all those units. The predictions for 2010 and beyond (from analysts such as Gartner and IDC) showed no end in sight for PC growth, breaking through 400 million in the years to follow. However, as frothy as that might have seemed, there were concerns that the growth rate was finally starting to slow. In fact, 2006 appeared to be the first year since economic downturns when the overall growth rate slipped and never reversed that trend with any staying power. Nevertheless, PCs were forecast to grow about 10 percent (adding 25 million PCs, or about the size of the entire global PC-installed base in 1990). The most interesting trend was a bottoming out of sales of desktop PCs—the laptop had supplanted the desktop PC in work, and totally dominated the home PC market. Computing was becoming ubiquitous, and laptops represented both mobility away from home and in the home. Gone were the days of computers taking over a whole tabletop permanently.

As a reference point, worldwide PC sales for 2019 were forecast to be slightly above 230 million following a pandemic surge approaching 325 million that appears to have receded.

To say the business was entirely dependent on OEMs would vastly understate the potential with business customers who would add the enterprise version of Windows to both new and existing PCs, which represented a substantial uplift in pricing (and that translated directly to profit.). As important as this was, it was much more a matter of packaging and pricing as the company had long ago shifted to developing a wide array of business-friendly features for Windows, starting with security and business networking, with much more in the works.

A significant evolution of the Windows business, rooted in both upsell and competing with Linux, was the release of a low-end SKU, called Home, and a more expensive SKU, Professional. Where Office had different applications (or modules), Windows had different features. The emphasis on these SKUs began with Windows XP but was put into full force with Windows Vista. This is a classic product strategy, but due to the nature of the Windows business the financial upside is enormous. A small percentage in unit upsell from Home to Professional is a price increase of tens of dollars multiplied by tens of millions of units, and all of that is essentially zero incremental cost to Microsoft. The leverage was magical. [To those keeping track of present-day Microsoft quarterly earnings, there’s a consistent talking point about the role of business SKUs in Windows revenue.]

Unique to Windows was the desire to make sure developer APIs were consistently available in the most broadly distributed SKU. Everyone wanted every API to be in Home. This constraint is what made specialty SKUs like Windows Media Center or Tablet PC destined to fail with third-party developers—the APIs developers would use to target those PC form factors were only in those narrowly available SKUs (with expensive hardware.) Seeing the tiny sliver of market, developers would rather attempt to roll their own solution rather than ride the tiny coattails of a niche market. This would become important as we broadened Windows 7 to include touch, where most of that support existed only in the Tablet PC specialty SKU.

The Windows Ecosystem could be thought of as four sets of deeply dependent yet independent entities, each believing that they contributed an outsized effort when there was success while each believing the other parties had more than their fair share of responsibility when things were not going well: Microsoft, Intel making and selling CPUs and associated chips and storage, PC OEMs and hardware makers (Independent Hardware Vendors, IHVs), and software developers (Independent Software Vendors). The mutual dependencies are illustrated by a cycle:

* PC and hardware makers depend on Intel and Microsoft to deliver a complete PC experience.

* Microsoft depends on Intel to continue to drive demand with faster chips and new capabilities while enabling PC makers to take advantage of those.

* PC OEMs depend on IHVs to enable all sorts of new hardware capabilities that will excite consumers and drive demand.

* Microsoft courts the fourth leg of this stool, the independent software vendor (ISV or “Developers, Developers, Developers” as SteveB would calmly state) such as Adobe, Autodesk, Intuit, or PC game makers to make applications for a new version of Windows with new APIs or that require new hardware (such as faster graphics cards), which in turn require new PCs.

A new version of Windows without cool new PCs or new PCs without cool new chips or hardware or new software that didn’t take advantage of any of those were all reasons why the ecosystem could become unhealthy. This codependency created an enormously tense network made up of a small number of large public companies, each with quarterly earnings reports. Also, at the time, in the United States, Japan, and Europe, PCs sold through a large number of retail stores so companies such as Best Buy, Dixons, or MediaMarkt were also part of this equation, and they were ruthless champions of low price and opportunity for margin.

The second section of the planning memo outlined what were called big bets. We hoped this would engage the architects and long-term thinkers by laying out significant challenges that we knew would need to be scoped and refined. Intentionally, there was only a small number of these so as to scope them to a single release. The constant discussion on bets was about how to define a bet as a set of steps that could be accomplished over reasonable time periods and incremental success, rather than one giant leap a decade later.

One of the unique things about Windows being part of the PC ecosystem while also being an open platform was that when new hardware was available to integrate into PCs, PC manufacturers could build PCs with support for new devices or peripherals without built-in Windows support. OEMs would write their own code from device drivers through user interface to support a new hardware gadget (for example WiFi or a fingerprint reader.) Unfortunately, this created a problem. Too often, such support did not have great APIs for developers or was not always integrated into Windows in a way that allowed others to make the most of it. But with Windows releases not being so reliable and PC makers always looking for an advantage over the competition, waiting for Windows to figure out support for new peripherals never really happened. With Windows 7 we set out to get ahead of some classes of devices (such as printers, graphics, storage, and so on) with a big bet on hardware-driven innovation but would leave it to the planning process to identify areas where such an approach would work.

There were two other big bets of note. Virtualization was becoming a huge push across the industry. But on that front, Microsoft was falling behind. Interestingly, at many team levels, there was a deep resistance to virtualization because of security concerns that the whole system could be compromised. There were also business concerns due to the Windows business having a foundational belief of one Windows license for every CPU. All the while, virtualization was growing rapidly and on every CIOs radar precisely because of security. Their belief was that virtualization was inherently more secure. It was also the core technology that would enable cloud computing and as such it was critical that we get it right. Competitively, virtualization was critically important for the Windows Server business. VMWare, the inventors of virtualization, was rapidly becoming a technology powerhouse under the leadership of Paul Maritz—yes, the former leader of Windows. Ironic moments such as this were in no short supply.

We also wanted a big bet for the typical Windows consumer, which would give us a chance to incorporate Windows Live services as a key part of the overall value proposition for Windows. Historically, Windows had duplicated services provided by MSN (the predecessor to Windows Live), ostensibly for a whole variety of reasons from legal to performance to security, and at the same time the MSN services did not do any work to shine on new versions of Windows. The ultimate achievement of this was the debacle when Microsoft shipped both Windows Messenger and MSN Messenger on new PCs and both had different sign-on, networks, and features. Another example was when the Windows Mail program did not do a good job connecting to Hotmail. This gave us a chance to say, “We will plan on not duplicating work,” at a minimum, but also push to do great work that could potentially compete with Apple or maybe Google.

In order to account for the heavy lifting that would be required to build on the Vista foundation and yet also fix it to the degree we needed to, we defined a big bet that we called “continuing bets.” This provided a catch-all to plan on the needs for improved PC security, 64-bit computing, and overall cleanup work. The fact that the release ultimately succeeded in cleaning up or completing this work led to the frustrating belief by some that Windows 7 was, in fact, a minor or cleanup release.

The traditional Windows view loved big bets—that felt like the kind of work we did for Longhorn. Many on the development side were perfectly happy to define a release by making progress on big bets, even if the manifestation of big bets would take years and the visible features not particularly visible.

From Julie’s perspective, the plan or vision for Windows would be start with planning themes. Rather than a plan itself, the memo contained ten planning themes. A planning theme was a precursor to a specific main pilar of the release. Themes are an invitation for brainstorming and creativity within that theme. Prior to this there is a step to even pick these themes, but that is a small group and done relatively top-down. The planning themes were broad strokes. The introduction of those themes was really an invitation to begin a process whereby the specific groups of engineers (feature teams) work together to define what it might mean to deliver on that theme—a literal call to innovate and be creative. The themes for planning Windows 7 included:

* Refining the Vista User Experience

* Building Customer Confidence

* Embracing the Best of Web Development

* Helping OEMs and IHVs Win the Hearts of Customers

* Turning IT Pros into Windows Evangelists

* Making it Easy to Add or Replace a PC

* Lighting Up Everywhere with Servers and Services

* Finding Everything Easily

* Connecting Multiple Devices to Multiple PCs

* Embracing Hardware Advances for Better Multimedia Experiences

Over the next three months there were countless offsites, meetings, design sketches, and more to arrive at more detailed views of what features might be built. It was this part of the process that is both the most uncertain and nerve-wracking for me. I not only had no idea if the ideas being generated were good, but I didn’t even know if the teams were converging. There’s no way to even measure this. In the back of my head, I was also wondering if there were developers writing code for new features that we won’t even want to ship while PM was off figuring out what to make. If the goal of the planning process starting with the planning memo was to bake a cake, then I just couldn’t open the oven every 15 minutes to check without ruining the cake.

Over the three months from the planning memo to the creation of a product vision the team is not producing code. The PM team was producing slide decks, PM prototypes, design sketches, and even a little bit of prototype code. The development team participated in this part of the process but was also tasked with watching the market telemetry for Vista and fixing a lot of bugs. The test and development teams together were working to improve the daily build and test process—an enormous undertaking that GrantG referred to as building out “the factory floor.” The 6 years of Vista development and the numerous side releases of Windows had made for a neglected engineering process. There was plenty of work to go around. Having the time to address these pain points and to do so together without a crisis enabled even this type of work to become part of the culture change. JonDe dug into every aspect of the daily development process, which he had become acutely aware of in his role leading Engineering Excellence. Fixing the factory floor would prove to be an enormous win for morale and efficacy.

Then suddenly the cake was ready. There was a vision. Reading this, one might really want to know what precisely went on for those months. How did the team go from brainstorming to a plan? The lack of a concrete description of this is why it has always been somewhat magical. It really isn’t magic, but it is empowerment, accountability, and creativity. There was never an answer other than build a great product, but pieces had to fit together, and everyone had to agree and reach a shared view of what was being committed to and being built. Every offsite, prototype, and sketch were talked about, debated, and considered. Most were thrown out for any of a myriad of reasons.

There was, however, one bit of magic and it was connected to a cultural change. The typical (in Windows and elsewhere) executive management role is one where teams go off and generate ideas and come back with a plan, for approval. Invariably during a meeting for approval the plans would be changed with the incorporation of executive feedback. The problem I always had with this was the underlying assumption that an executive thinking on the fly about whatever specifics or details arose during one meeting for an hour after weeks (or months) of work was truly value added or just value changed. I never had that much confidence. We started from an assumption that the plan was already approved, and the meeting was a confirmation of the plans the team created and was accountable to. The magic was that leading up to those review meetings we were, JulieLar in particular, in a constant and iterative conversation about ideas, tradeoffs, and specifically adherence to the evolving product vision. This led to a much deeper sense of ownership and buy-in and avoided the historic problems of swoop and poop or simply random executive thoughts.

We called the transformation of planning themes to the product vision a pivot (Microsoft loved to use the word pivot in just about every context, especially because it had nothing to do with basketball.) We were pivoting from a long list of themes with ideas of problems to be solved to a much shorter list of vision areas each with specific scenarios we would implement. This is why the vision represented a true product plan.

On July 27, 2007, we gathered the team at the Meydenbauer Convention Center—yes the entire Windows product team was invited—for a meeting where we presented the product vision. The all-team meeting was another step in the culture change. It would be the first time the whole of the Windows team got together to hear the entire product plan—the committed product plan—for a Windows release before coding started. It was so important to me that everyone really experience what we intended to build and to have that moment when as a team we commit.

Just as we did with Office, the product vision consisted of a substantial memo (this time with a bit more up front on how to read the memo), a series of produced design sketches showing each of the main themes of the release as we intend to develop them, a mock press release created by marketing showing how the release would be communicated upon shipping, and my favorite the one page cheat-sheet for the vision.

Even though we had been together for more than year as a team, and Windows Vista had been in market for six months already, we were still transforming and growing as a team. While everyone really wanted to know what everyone else was going to build (by this time most people knew what they were going to start to build) I wanted us to continue to build the culture. I had a slide defining a successful Windows 7 as a set of key traits feeding into success (using Office SmartArt of course): promise and deliver, develop satisfying features + scenarios, create partnerships [not dependencies], participate and communicate, learn and iterate and improve. Still, we had one more slide articulated how to use the vision. At this point, if you’re not convinced management is repetition…

Before JulieLar would take the stage and share the vision themes and features, we had a special speaker. Although now formally transitioned from his role as Chief Software Architect to philanthropist and Chairman of the Board, I thought it would be important for BillG to share a personal view on the role of Windows within Microsoft. He delivered a wonderful and improvised talk without any slides. It was a mix of history and enthusiasm for the most recent innovations lasting about 15 minutes. He spoke of the patience we showed in building Windows after the first releases that were too early and the bet on having Office for Windows which made Windows better and Office better. I did ask Bill to emphasize competition knowing that was near and dear to him, given I had already shared with him my view that there was a bit of a lack of fire in that regard. The iPhone was just weeks on the market and the potential impact on the PC industry was just becoming clear and did not escape Bill’s mention, including some speculation about a tablet-sized device for reading (this will be discussed in Chapter XIV.) He also touched on Linux competition which was acute in the enterprise space and on servers. The highlight for me was when Bill held up the vision one-pager and reinforced that this was the product he was expecting, and he too would behave and not ask people about things not part of the plan—the team applauded and that made for quite a moment for me. That moment didn’t last long as he then told the team it wasn’t critical that we hit the ship date as long as we got all the scenarios working—that is the Office baggage described in previous sections where Office somehow cheats by cutting features to ship on time. There is a recording, but it is poor quality—just a camcorder in the back of the room. 

JulieLar presented the vision itself. It was a work of art. From a dead stop after Vista she pulled the entire PM team across WEX and COSD through a foreign process (an Office process no less.) I could see the excitement and almost amazement from the team as I stood in the back of the room doing all I could to get a sense for the vibe. The vision for the release had five areas:

* Specialized for Laptops

* Designed for Services

* Personalized computing for everyone

* Optimized for Entertainment

* Engineered for Ease of Ownership

Each of these were detailed with scenarios, business motivation, and a definition of success and then illustrated with a narrated design sketch.

Following this ChuckC, Julie’s counterpart from the Windows Core System team in COSD, presented the project tenets. These were the non-negotiable aspects of the project:

* Design for interoperability

* Security is a key promise to customers

* Runs with existing hardware

* Application and driver compatibility

* Getting ready for 64-bit only

* Performance breakthroughs for key scenarios

* Improved Reliability

* Design for sustainability, manageability, supportability

* Design for every market, every language

* Improved accessibility for all users

Chuck outlined the project schedule which included three milestones—each an opportunity to re-evaluate, adjust, re-allocate resources, and adapt the plan. We would begin coding in 5 weeks, after the US Labor Day holiday. Windows 7 RTM was set for May 13, 2009.

Mike Sievert (MSievert), the CVP of marketing (and as of this writing, the CEO of T-Mobile) provided a detailed overview of the current state of the business and opportunity. KevinJo spoke about the importance of Windows Live, which was in the process of executing a plan to run on a shorter schedule and would have a releases of services for Windows 7 at availability. He also addressed what was top of mind for both of us, which was adhering to the newly announced Windows Principles a series of proactive steps to managing the business that the legal team put forth on their own in hopes of setting a different tone with regulators.

JonDe spoke to the deep technology shifts in the PC industry where the COSD team had historically focused their energy and where the big bets at the core OS level were critical, especially for Windows Server which shared the OS. He spoke to the work we needed to continue including:

* Multi-core and many-core

* Virtualization

* GPUs

* Wireless

* Storage and non-volatile memory

* Power management

* New and popular devices: GPS, biometrics, web-cameras

* Diverse form factors

To set an example, the meeting went like clockwork and lasted three hours, and there was even a break. After the meeting, I sent out the full memo to the whole team. I recently acquired a new ultra wide-angle lens for my (then fancy) DSLR and took a team photo. Everyone was in their limited-edition color-coded t-shirts which was always done tongue in cheek but certainly plays like something one would see on a bad take of a tech on HBO. I still see these Windows 7 t-shirts around town, which amazes me. I even saw one in a yoga class in Silicon Valley, years after vision day.

I followed up with an Office Hours blog post expanding on my themes of what would make Windows 7 a successful release.

The day could not have gone better. I had been through many vision days in Office, but this one was truly a special moment. I genuinely felt like we had reached a milestone of cultural change within the team.

I was of course kidding myself. I only felt that way because for 15 months non-stop I had been saying the same thing over and over again gradually improving. But we were just now starting the real work. Other than my own fatigue, there was no evidence yet to support an assertion that we would get the release done. In reality, I remained terrified. I couldn’t even hide it. KevinJo sent me mail after the meeting saying he felt the meeting was great, but he thought I seemed down.

I was not down—the day was really excellent. I was, however, worried. Would this be enough? Would we get done on time? Was on time even soon enough? We had so much to do. We had so much to fix, starting with the relationships with PC makers who were truly suffering with Windows Vista.

On to 089: Rebooting the Ecosystem

After thinking and writing to provide context to BillG, SteveB, and KevinJo, I had to begin the real work of changing the team. As much as I would have liked to avoid the second step of the “Three Envelopes” (having skipped the first) I found myself planning a reorganization. Not just a reorg though—Microsoft was by many accounts in a perennial state of “reorg hell”—I was planning an organizational change and cultural transformation that would have an effect on every member of the team, almost immediately. That meant more writing. More communicating. A lot more.

Back to 086. The Memo (Part 2)

Most big company reorgs are fairly routine affairs that nevertheless cause teams to drop everything, stress out over the weekend (because reorgs always happen on Fridays) and contemplate what might change. But then returning to work on Monday, little changes immediately except for somewhere up the org chain there’s a new boss who will in a matter of time introduce some changes. Most reorgs are not nearly as big a deal as all the time and energy that goes into talking about them.

This was especially true at Microsoft which, at least to many, felt like it was in a constant state of reorg hell. In my early days at the company, I experienced several reorgs in the most senior (other than BillG) executive structure from having a president to not having one, to adding a COO to removing a COO, three-in-a-box (the BOOP, Bill and the Office of the President), back to a president, then a president and COO, then SteveB as CEO and BillG as Chief Software Architect, and so on. Office itself bounced between a few executives over the years as well. In fact, just as I was in the middle of planning this June 2006 announcement, BillG announced he began transitioning from Microsoft to spend more time at the Foundation. Ray Ozzie (ROzzie) would be appointed Chief Software Architect (CSA).

The thing about reorgs is that most people are trained, best case, to scan the reorg mail and see if their team is directly affected by the change. Specifically, how far away is the new boss. If there’s no immediate impact, then just go on doing what they were doing. In practice, most reorgs at scale don’t affect most people directly or immediately.

The Windows and Windows Live changes were not like those reorgs. This was not a change at the top. This was a change for literally everyone in the organization. More than half the team would get new managers soon after Vista shipped, and everyone would have a new manager no more than three hops up the chain.

It was even more than just that. Jobs were changing and with that many mental models of career paths were being upended. Everyone who thought they had plans for what would be next would wake up to something different. Aspirational jobs as a PUM or an architect with no direct reports (or code) were no longer going to be available. We were an engineering organization, and everyone was going to be asked to focus their trajectory on building products. Even becoming a manager was deemphasized as we asked managers to take on more directs while we reduced the percentage of the team that were managers by one-third.

Then beyond that we had every intention of radically changing the way we would work. Everything from the planning process to daily builds to milestones. Even meetings with execs would decidedly change (or mostly go away).

I spent May and June 2006 on two things.

I was mostly meeting more people on the team and figuring out who would be filling in the organization I am about to describe. These meetings were a constant reminder of the desire for change. They were also opportunities for ongoing reminders that Windows and Services are different and more difficult than Office. I probably wrote 500 long emails replying to questions about everything from the future of specific technologies (most of which I knew nothing about: USB, DirectX, virtualization, and more) or to suggestions for how we could improve. I received quite a few questions asking “how do you want us to…?” on everything from hiring to signing purchase orders. There were many questions that were very specific to situations and people that I knew nothing about. The questions always seemed to boil down to process and culture challenges, never about domain expertise. It was 7x24 from the end of March to the end of June.

To remain sane, I was also installing daily builds of Vista and Office 2007 which were both winding down. Not being in the daily triage meetings for Office was kind of sad for me. I vividly remember sneaking over to the ship-room meeting one time, which proved to be silly and indulgent on my part and a distraction to the team. It was, for me, a moment of sanity just to see the team working, and by that I mean not taking any code changes.

Mostly, however, I was genuinely scared. I had absolutely no doubts about what we needed to do, including how to structure the team and what to ask of them. I had a lot of doubt that I’d be able to pull it off and most days wondered if I was the right person to drive these changes. There was so much baggage coming from Office.

Something that I was keenly aware of was how many managers, myself included, viewed reorgs as something of an adversarial process. A reorg was something to protect the team from, not something that could help. Reorgs prevented work from happening and were a distraction. That’s certainly how I treated a lot of what went on above me for most of my career.

Now it was my turn. The very last thing the company needed was for people to view the changes I was putting in place to be prevented or redirected. I was terrified.

Would people quit? Or likely, how many people would quit?

Would people run to the gossipy press or Mini-Microsoft?

How much email would be sent to SteveB or BillG? And, yikes, would they answer it?

What if no one wanted any of the new jobs I was proposing?

My first step was to figure out the new leaders. In picking those leaders I was also certain of how the overall organization would be shaped, my direct reports and their direct reports and so on. This structural change was the visible symbol of the reorg. It was a massive pivot away from a product unit organization to what I called a “functional organization.” A functional organization is based on having discipline specific leaders reporting at the top and their teams consisting entirely of people within those disciplines of development, testing, and program management. Across each of the disciplines we would have mirror structures of group managers, leads, and individuals. I sketched out the math and knew we could build the organization out of about 40 teams of 25 developers each (and 25 testers and a dozen program managers, under their discipline leaders.) In due course, the intention would be to organize COSD this way as well though we needed to let them finish Vista for a bit more time.

I would love to spend more words in this section describing the inherent tradeoffs between these two organization types, but it would be a bit of a distraction from the story. Instead, I would refer the reader to Functional versus Unit Organizations, an essay I wrote in 2016 on this topic.

In assembling a team of new leaders, I tried not to be the guy who brought “his people” from his old job, but there simply weren’t any candidates in Windows that would champion the changes we needed. You’re not supposed to show up with a team, but managers almost always do. I never understood why that was the case, but after living through this I have a more visceral understanding. It is not about the personal connection, as most think, but in times of change you need to have a team of people who share the same world view by default without having to guide at each step. Without that, change is impossible.

I thought I wasn’t going to be that exec, but I was. Only to a point, however. Within the team, I was able to find a balance of “natives” and “imports.”

Here’s how the leadership team shaped up: The Search team remained as it was, under Christopher Payne (ChrisPa) working on its own roadmap and plans, but with much more capital and more people and soon a functional org structure. Chris Jones (ChrisJo), a longtime executive on the Windows Client team, would lead program management, design, and research for Windows Live Experience, WLX. Leading development would be Steve Liffick (SteveL.) Steve had Windows Live deep in his DNA, but he had been a program manager his entire career (having grown up in Seattle, interned at Microsoft, and joined straight out of college the same summer as I did.) The challenge facing the team was a lack of senior enough software engineering leadership to manage a team of several hundred, so he agreed to manage the engineering team and would prove to do an excellent job over time. Arthur de Haan (ArthurdH), a longtime test leader in Office who had built out the internet services operational infrastructure, also joined the team to lead test and internet operations.

The new name for Windows Client was the Windows Experience team, or WEX (pronounced weks). WEX needed a program management leader. In many ways this job was the program management job at Microsoft. Vista screamed out in need of program management—it needed a holistic view of the user, the customer, and the experience. Julie Larson Green (JulieLar) was ready for a new and bigger challenge after leading such an extraordinary effort redesigning the Office user interface. She was just recently promoted to vice president for that contribution on top of her long history of successful product development and team leadership.

Aleš Holeček (AlesH, which coincidentally is the proper pronunciation of Aleš) wore his Czech heritage proudly and maintained close connections to Prague, one of the most creative and vibrant tech communities in Europe. He also frequently, and inexplicably, wore bright red pants. AlesH was in the process of leading a rescue mission for large parts of the most visible portions of the Longhorn Reset. In short order, as a new hire to Microsoft, he had established himself as a strong leader and deeply knowledgeable and respectful of Windows as a third party developer, but also clear on where Windows needed to go. After several discussions, I sent him the shortest of emails asking if he wanted the job leading WEX Development. An hour later we had a leader.

The testing role for WEX was going to be the most visible testing leadership job in the entire company. Windows, almost more than anything, was a product of testing. Grant George (GrantG) was busy completing Office 2007 and was so focused he was reluctant to even chat about what comes next—focus was one of Grant’s defining traits as a test leader. In speaking with him, it was clear he was excited about the challenge. But he had also been much more deeply involved with Windows than I had considered, especially over the past few months, and hesitated because of his concerns about the culture. After a couple of weeks of being left to his own thoughts, he came back willing to sign up. This was a huge win for the team.

With a team in place, I penned the longest reorg mail of all time. In hindsight, this surprised nobody, but at the time it was, well, shocking. It was not just an announcement, but an explanation and justification for an organizational pivot—moving from product units to a functional organization with large groups of each engineering discipline and very few product unit managers. While not an intentional play on words, functional organization worked that way too.

On the last Thursday in June 2006 (breaking with the tradition of Friday afternoon reorg mails), I sent out a 3-page email with an attached 20-page memo (with no org chart or diagram, and no to-be-hired spots). At more than 13,000 words the memo was titled “Windows and Windows Live: Organizing for agility, Competing with focus, Building must-have software.”

I even did something I had never done before, which was to copy the mail to all of Microsoft’s executive staff and their direct reports all around the world. There were about 150 execs at the time plus their directs (and usually staff). I broadcast the mail, in the last days of the Vista project, to send a message that we were working and making progress.

As soon as this mail landed in the inboxes of about 6,000 full time engineers (and designers, localizers, planners, and more) they would all hear that their jobs would be different. But precisely how would take time. It would take weeks to build out the five or so layers of the organization, down from 7 to 10. There was no spreadsheet with all the answers for each person. Not even close.

In fact, taking a lesson from Office, we put in motion something that was yet another point of evidence of how different things would be. There was going to be a bit of a free market for people to stick their collective heads up and decide what they might want to work on next. Everyone had a job, working on their old area or perhaps trying something new. At the same time, the new execs would be choosing new direct reports who in turn would be choosing new managers and those people choosing new leads.

The previous two sections detailed the process I used to learn and the memo I wrote for an audience of three to crystallize my thinking. Now it should be clear it was a rough draft for broader communication. I moved from “Observations, Aspiration and Directions” to “Organizing” and as you look at both you can see the tone moving from analysis to action. In many ways I was employing the same planning process we use for software to design the organization—open a funnel to inputs, iterate, and at each step distill down the actions to what is essential for success.  

But hitting send on this memo led to the most workplace stress I had ever experienced or would experience, not to mention the stress for all the new leaders who would be crushed with questions and concerns. Significantly, I knew how stressful this was for every individual. I felt or hoped that the messages would be read and considered even if not immediately validated, recognizing the emotional nature of so much change.

There was sizable pent-up demand for a reorg as that is what people were expecting, but I was terrified that somewhere in this memo I unintentionally offended someone, or that I perhaps expressed too much candor, offending a constituency in a deep and unrecoverable way. I was certain that I was going to immediately get an email from Mary Jo Foley at ZDNet, who was going to reprint the whole memo (I even had a “I am being transparent so don’t make me regret it" plea in the mail message cover note). It worked. No leaks.

I diverged from Microsoft culture in ways many found shocking but was routine for me and Office. I sent out a reorg mail without a directed acyclic graph of the organization at the top of the mail. Even more shocking, there was no org chart at all. When people opened the mail, it was as if they had opened a box of Cracker Jack candy and couldn’t find the prize. I received countless replies to the mail asking for the org chart, some of them not particularly supportive of this cultural statement which was simply perceived as incompetence or insensitivity. Additionally, the organization was complete in the mail, absent any open positions or to-be-hired.

On the other hand, I also received so many replies that were positive beyond words. The desire for something significant to put the team on a path to better results was clearly in the air. From my former co-worker in Office, Jeanne Sheldon (JeanneS), who is (even to this day) an absolute stickler for brevity and clarity in writing (a decade leading Word testing would do that even if originally choosing to work on Word because of this skill) had perhaps the kindest words. Jeanne replied to me saying “This doc is a masterpiece of clarity and focus. Although it is long, it could have been neither longer nor shorter. Wish you could do another employee poll tomorrow.” I needed that.

Much to my relief, the mail received a rather heartwarming reception. I received hundreds of messages from people who appreciated the transparency—the mere heft of 20 pages, which I know most people did not comb over like the Code of Hammurabi or anything, provided some air cover. (Some even complained about having to read a memo of such length—a complaint that would become something of my brand if it wasn’t already.) Being able to answer questions in town hall settings and then saying “there’s more in the memo” became a bit of a rallying cry for me along with a pointer to the inevitable follow-up post on my Office Hours blog.

Still, I received a few dozen deeply emotional mails combined with one-on-one conversations. These were people who were the most affected, particularly by the perceived loss of status or career trajectory when it came to product unit management. I knew these conversations would be the most difficult and dealt with those the best I could. No one was being demoted in any way from my perspective and the organization had a place of equal level and opportunity for everyone. There were no formal staff reductions at all. Surprisingly, we fielded queries from the press about layoffs which were never considered. I was asking people to take on roles more directly accountable to engineering outcomes. For some, and it was a small number, it was just not appealing, and they moved on. Each one of these cases was enormously difficult. I’d like to say there was some emotional distance for me because I didn’t create the situation we were in, but there’s no way to avoid the feelings of the moment—I in fact did create this change.

With the mail and the memo, I went out on tour and so did each of the new leaders. The slides to explain the reorg were focused on the strategy of “Why are we doing this” and “Why are we together.” KevinJo came up with a hierarchy that we used across his expansive world consisting of product lines, engineering areas, and feature teams. Kevin was used to organizing tens of thousands of people and had real insights in how to use hierarchy to communicate.  

I answered the “Why are we doing this” question with a slide on “Goals of Organization Changes.” This was the core of the discussion. I made people sit through my talking about this slide at length rather than, as usually done, emphasizing the structure or org chart of the team. The reasons behind the org were a direct reflection of the past 90 days of learning as I thought back to the first memo previously described.  Many of the exact same words were used that I had written a month earlier.

In the description of product lines, we intentionally left off the name COSD but it was implied in the Windows/Windows Live product area. People would get the message that COSD was part of Windows, not separate or even Windows entirely.

To address the question of why we were together I created a table of the engineering areas for WWL: Search, Live Experiences, Internet Explorer, Windows Experience. The “glue” as I said at the time was that Windows, as critical as it is, needed a series of connected services that were core to Windows. This was a subtle shift away from Services independently focused solely on advertising. This vision would take time to materialize. One can see how Apple was also just starting this same push with iLife and iWork on the Mac. Recalling the fits and starts of services connected to Apple products is a great learning exercise. What we know as iCloud today was originally launched in 2000 as iTools, which were desktop applications for photos, video, and productivity. In 2002 the addition of email and other online services came with the branding of the .mac service. Then in 2008 (two years after our org change) the service was renamed to MobileMe and greatly expanded, which lasted until 2011 when it became iCloud. Phew. That is some journey to get right. We would struggle much the same. It is interesting when everyone seems to have the same idea of where to go but takes many years to get there and not everyone even arrives at the future the same way.

The other glue across WWL was Internet Explorer. This was the era when tuning online services to the latest browser was still important. The struggle to deliver great experiences via the web that matched desktop applications was significant, as was owning the “frame window” for delivering advertising and promotions. Due to the declining popularity of IE and lack of work on a new version, Search and WLX (and the rest of the internet) had pivoted hard to optimizing for Firefox. It is not without irony that as I write this in June 2022, Microsoft has just announced that Internet Explorer has been officially retired and replaced by the Edge browser based on Google’s open sourced code.

Each of WEX, WLX, Search, and Internet Explorer had sections that outlined the major themes to be investigated or worked on for the next products. There were no names of feature teams, no schedules, no user interface sketches. Astute readers could see where we were heading and how, as we dove into more understanding about these areas, it would inform the next level of the org structure and then specific product features would follow. This is what we had mastered in the past four releases of Office, so I felt confident we could scale it here.

Change started with this memo. I summarized this change as follows, quoting from the original memo:

This memo represents a change.  Change is difficult.  Change is uncomfortable.  Changes that look good today might also have looked good before and failed.  Changes that look good today might not be so great tomorrow.  Change is risky.  The changes outlined here are not just tweaks, but represent the first steps in working in a substantially different manner.  Many of the issues raised by members of the team are about the culture of our organization—these are the aspects of “how we work” that must be addressed. 

This memo is about the top line changes—the organization and priorities—and over the coming months the way we work together will also change.  We will push more decisions down.  We will aspire to a more consensus approach to decision making, rather than an escalation approach.  We will streamline our organization with fewer managers overall, and fewer levels of hierarchy.  We will value our core engineering disciplines more and demonstrate this by building an organization that focuses on the role of development, testing, program management, with integral contributions across the product line from design, usability, planning, localization, business development, operations, and more.  We will ask our teams to be clearly focused on deep technical contribution in a smaller number of well-defined areas, rather than breadth of coverage at too shallow a level.  We will allocate resources more deliberately and generally in smaller teams.  All of us may not operate with the same tempo, but we will all operate with a rhythm and not move from crisis to crisis.  We will operate with a clear framework with a clear understanding of how we will define success, a framework that is flexible and has vast room for innovation, yet represents a commitment to customers that we will deliver. 

These changes are part of the agenda of this memo and our organization moving forward, but will require all of us to learn and grow together.  I am committed to doing my part.  I will not dive into the middle of situations.  I will not randomize your work.  I will not be a bottleneck for decisions.  I am here to work with the senior leaders of the team to provide the framework, define success, provide the resources that map to those, and make sure we have the right people with the right skills in the right jobs to get the work done that you commit to doing.  That is my commitment to change. 

A few weeks after this communication blitz (July 22), KevinJo announced that Jon DeVaan (JonDe) was going to lead COSD also reporting to him. Partnering with JonDe was going to make everything better—Microsoft was very lucky that Jon took on this role. This was a bit of a reunion for us. I thought back to meeting Jon the first time in the summer of 1989 when he pointed out so thoughtfully how interesting yet naïve (in a commercial sense) my views of memory management bugs were. Then through a few releases of Office as peers and then Jon as my manager, promoting me to vice president. Over the past few years while I remained in Office, Jon had been leading a new team called Engineering Excellence, which brought all manner of excellence company wide. Under Jon’s leadership the team introduced and deployed tools and software for training and management as well as individual excellence. Largely not followed outside of Microsoft, the EE team was critical in scaling, training, and developing the company’s engineering capabilities across every product line. It was the first substantial effort at training engineers since “Klunder College” for new applications developers, which ended decades earlier. Jon was uniquely qualified given his lifetime of experience to re-energize the engineering culture of Windows. So loved as an engineering leader, an early 1990s pre-beta build of Excel once read “Excel DeVeloper Release” in the About box.

Jon created a top-level organization structure to parallel WEX by naming three senior leaders for development, program management, and testing, respectively Ben Fathi (BenFa), Chuck Chan (ChuckC), and Darren Muir (DMuir), each experienced Windows leaders, for a new team Windows Core Services (WCS). Their peers and counterparts in WEX were AlesH, JulieLar, and GrantG. In addition, Jon would have a team of architects (the original COSD architecture team) as well as the corporate resource team for security engineering, a.k.a. Trustworthy Computing, and a large team providing the fundamentals engineering, engineering tools and measurement, sustained engineering, and support for in-market products that would produce urgent, monthly, and regular service updates led by Wael Bahaa-El-Din (WaelB) called Windows Engineering Services (WES.)

The WEX and WCS split of Windows was a first turn of the crank organizationally to building a unified Windows team. Jon and I were 1000 percent unified at the top. Our respective teams were unified. Still, it would be fair to say that the old rivalry or tension between Windows Client and COSD would continue to manifest itself until we were well into building the next product. Jon and I were working to create an organization of peers, but history did not see the teams that way. There was a lot WEX would need to prove to WCS in term of focus on performance and quality, and much WCS would need to prove in terms of building an exciting product. When tensions would arise so would the old names of Client and COSD—that’s how Jon and I knew we still in the midst of a culture transformation. In practice, the COSD name stuck around for the release as we most always were talking about WCS and WES (I will generally refer to COSD throughout this chapter.)

In practice, this was all part of the slow-rolling process of changing the direction (the culture) of a giant ship. The structure is only the first change of many. I remember when I was relatively new to Microsoft and BillG created the Office of the President and announced it at a big meeting (well, it wasn’t that big since all of Apps fit in the old Kodiak room back then—still hundreds of people total) and then went back to my office and kept working. An analogy I often used about change came to mind. The reorg was like how the Soviet Union fell and then the next day everyone was back at GUM waiting for winter coats to arrive, but over time there would be huge cultural changes.

As interested (or perplexed) as people were with these changes, they wanted to know who their boss would be and what they were going to build. Reorgs always come down to the most localized interpretation possible.

Something I should say about this organization that is incredibly important. While I’m obviously as biased as can be, this was the very best team at precisely the right time to do exactly what Microsoft needed to get done. Perhaps that is a bit much to say, this was decidedly a collection of Super Friends, each of whom brought their own unique “super-power” when Microsoft needed it. For the remainder of this work, everything good that I will write about happened because of this group of leaders. The Microsoft of today owes them enormous gratitude, not just because of what they did from this point forward for Windows, but several were also foundational leaders of Office that so dominates Microsoft today. They ran towards the fire.

But figuring out what we would do was going to take another six months. Whether that seemed like a lot of time or a little was a matter of perspective. Teams that were done with Vista would just start doing what they thought should come next, likely what was just cut, rather than what might be optimal for a product plan. Whether the team wanted to acknowledge it or not, there was also a ton of work to be done on the basics of the engineering system.

The changes weren’t over. They had barely started.

On to 088. Planning the Most Important Windows Ever

The previous section detailed the raw observations on Windows and Services culture I saw after weeks of hearing about the situation from as many people as I could. I could not just put that out there without specifics of what I thought could improve. I had to put some structure on what I learned and to offer optimism and aspirations.

Back to 085. The Memo (Part 1)

Reflecting on this moment of both optimism and fear, today I look at the candor I expressed with a bit of amazement. I wrote with detail and assertiveness yet seemed to forget that I was writing about one of the most successful businesses ever created. I was writing about hundreds of billions of dollars of market capitalization. I was writing about many friends. At the same time, there was so much that needed to be improved or more specifically to be repaired. I think what really motivated me were all those 1:1s I did and hearing all the different people expressing their pain and troubles, knowing things could be better. This was not a team that was dug in ready to resist change. It was a team waiting for change. It just needed to be the right kind of change.

That reality made this much easier. I felt if I could document what was going wrong and the broad population agreed then I was on a path to addressing challenges. If I could articulate reasonable aspirational goals, then what remained was to build a product plan on that rebuilt foundation of trust in management.

I was quite worried that both the problems described and the aspirations I would document would seem cliché. With BillG in particular, over the years he had shown little patience for the broad topic of management. His world view was always that the business would be best served by taking on the most difficult technical problems and developers would be anxious to tackle such challenges. That recipe propelled Microsoft for twenty years of Windows but was failing us now. SteveB was never one for patience and while he would be receptive to these management challenges, he was far more anxious about a plan and the timeline for the next product to address the concerns that were mounting about Vista—the company hung in the balance. KevinJo had just orchestrated a massive restructuring of the global sales force before taking over most of product development. He was deeply in sync with the idea of identifying organizational problems then directly addressing those.

The memo, Observations, Aspirations, and Directions for Windows and Windows Live, proposed three main areas to address: decision-making, agile execution, and discipline excellence. Each was presented in a section with both observations and aspirations.

* Decision-Making

* Agile execution

* Discipline Excellence

These points will sound like random musings from any generic book on management, both at the time I wrote them and reflecting on them today. The lesson learned, using the phrase from the previous section, is to demonstrate that these are more than clichés by citing specific examples that resonate with the employees who are being asked to operate differently and specifics on exactly how we will achieve aspirations.

Decision-Making

Across all of Microsoft, “decision-making” had been a constant and nagging issue. We discussed it after every MS Poll (the yearly survey of employee attitude and feedback), and each year I was left puzzled. It had never been an issue for our team (in the MS Poll and other feedback channels). I didn’t understand what was so difficult about decisions. We made decisions all the time in Office, so many it wasn’t even clear to me what decisions were so difficult.

Then I arrived in the Windows hallway.

There, it was an endless discussion of who “owned” a decision or who was “accountable” and, worse, people were asking me what “model” I used to make decisions. This was a reference to classic models of business function (or more aptly dysfunction) that use tools known as a responsibility assignment matrix (RAM, one such tool) for decision-making. One labels participants as: Responsible, Accountable, Consulted, and Informed (or RACI). Another such tool, OARP, stands for Owner, Approval, Responsible, Participant. These tools consistently proved frustrating and there was little evidence that decisions were made with less effort or more importantly, more staying power or higher quality.

The use of these tools arose as a defense mechanism against executives and managers who were prone to swoop and poop, a metaphor I learned as I assimilated into the team. As with birds, many managers seemed to show up at inopportune times, issue a quick opinion or edict, and not stick around for the mess they left behind. How much of this was actually a mess or simply a reaction to executive authority or inability to influence decision-making would take time to untangle. The expectation for me as a new Windows executive was that I had a tendency to employ this technique, no matter my own personal history or approach.

What I knew already to be the case turned out to be a big part of the problem, and that was a culture of escalation. In all software projects at scale, it is always the case that one team depends on another team—to provide code, consume code, integrate things together, and more. And this extends to sales and marketing connections. In Windows, escalation seemed to be the way most situations between teams were handled. It was a culture in which nothing was decided until people got in front of a VP, resulting in a culture where most of the middle management layer was biding time. And did I mention there were 7 or 10 management layers in Windows?

Weening the team off the culture of escalation proved to be one of the bigger cultural transformations I needed to make. It was also the root of challenges over many years of work between Windows and Office. In a culture of escalation, decisions made by people on the front lines, so to speak, rarely stick. In fact, escalation was done expressly to reverse lower-level decisions. If a Windows partner or collaborator doesn’t like the situation then an escalation ensues, and rarely did things stay the same. Office loathed escalation. Decisions were pushed down and stayed down. When people tried to escalate, they were told to work it out. The result was that when Windows tried to escalate decisions in working with Office they rarely got overturned, which proved enormously frustrating to Windows. And when Office tried to make plans, they would often find them upended at executive escalation meetings with Windows.

In Office, escalations happened so infrequently I cannot even recall any specific instances. In fact, we in Office had a saying that “escalation is failure.”

The primary downside of escalation is the way it shifts accountability. The winning side in an escalation feels an accountability not to the decision, but to winning the process of escalation. The losing side (and yes, they feel like they lost) does not feel bought into the decision and if it does go wrong, they too will join in the chorus of pushing blame up the chain. This is exact opposite of what you want to happen in times of making difficult decisions. The second-order effect is the obvious problem that as decisions are pushed up the chain there is less detail on execution related issues available, and usually that is where the trouble starts. These downsides were especially acute in mid-2000s Microsoft which was so much about improving accountability.

Given the crisis situation I was facing it would have been trivial to declare some sort of emergency and take control like a field general in a losing battle situation. Not only would this have been straightforward and arguably predictable, but it would also have fed right into the dysfunction that was already present. Sucking up all the difficulty would have been another management cliché, but one I could avoid.

Changing the culture surrounding escalation was going to be tricky. I decided to focus on consensus as a core tool for decision-making. I had to work hard to help people to understand that consensus was not the same as design by committee or groupthink—I’d always seen these as distinct when operating well. I also felt it was important to remove two tools that were all too frequently used to avoid either committing to consensus or collaborating, or to create dependencies between teams: Agree to disagree and Non-goals.

Agree to disagree gave each team the freedom to act how they would have acted prior to coming together to reach agreement, while also getting credit somehow for trying. The result was a product design/development conflict, which would fester through the development cycle and later be a customer problem.

Non-goals offer up a list of all the things a project won’t accomplish, which at first seems helpful. I never understood how such a list could be finite since there was an infinitely long list of features and ideas not in the plan. In practice, it became a way to kneecap executive input on potential collaborations or connections to other parts of the product by simply stating them as non-goals up front.

Executive presentations often began with a slide stating non-goals. Such presentations often ground to a halt debating non-goals as a result. Often the non-goals ended up looking as though the team would get nothing done at all. There’s a general rule to follow which is never offer negative goals up front. Early readers of Hardcore Software might recall the story from Office 97 when I spent weeks unraveling the damage done when the routine status report included a very long list of feature cuts, but no indication of what we were actually delivering. Bad idea.

My new team had an over-reliance on metrics and process as a mechanism to drive or force agreement on issues. This was exhibited by the constant drumbeat of red-yellow-green scorecard reviews in Windows or the KPI process in Services. These processes took an enormous amount of energy while also creating a sense of disempowerment in the organization.

The execution of these practices was fundamentally flawed. In both Services and Windows, the culture developed around having a policing team derive and measure the results, which only created an us versus them dynamic. As one example, in Services the small product planning staff organization actually believed it had the job of “determining the work that needs to get done by 800 FTEs” (a quote from a planning manager). Yet most of the debate and discussion took place around “are these the right metrics” or “are we measuring this correctly” as expected. And when the organization wanted to do something, but the metrics did not all point in the right direction the org still moved ahead. The result undermined the entire KPI process.

I offered a specific example that was going on in real-time. The team was deciding whether to turn on a new HotMail user interface for all users. The KPIs established by the planning team clearly said not to do this, but the engineering team needed to for testing and scale. Thus began a discussion over “maybe it is OK to meet 2 of 5 KPIs” or “perhaps we should weight the KPIs.” All the while when you think about it, this is an engineering organization, and it was unable to determine if the software was ready then that was some seriously deep trouble—and this was the largest flagship service.

These common techniques—decision-making frameworks, non-goals, agree to disagree, and metrics—were too often employed in forums for deciding and seemed to have the exact opposite result. These were, however, just obvious signs of poor decision-making. It was apparent we could improve everything about deciding if I personally modeled behavior and worked from the top-down to change the culture. With that in mind, the aspirations with respect to decision-making included the following (summarized from the original here):

Consensus among engineering peers. To avoid escalation, the team needed to arrive at a culture where the experts in the code (no matter who their least common manager is) can together reach a consensus on what to do. Once a decision about what to do in code (design or test) brings in general management we have reached a failure point.

Consensus among disciplines. A significant issue in decision-making was the failure for executive management to provide a framework for decisions. I saw too often that poor choices were the result of discipline silos or unsolvable situations. For example, executives pushing on development for a certain date while pushing on program management for more features while not giving testing enough time. To counter this, I offered an aspiration of reaching consensus across engineering disciplines before escalating while also committing to providing frameworks that allow for the unsolvable problems (schedule versus features for example) to be solved.

Agreeing to disagree is failure. Too many decisions were actually never made. A key example I came across early was the big bet in Longhorn on Avalon (what became Windows Presentation Foundation.) WPF was shelved for a future release, but development continued. Yet at the same time to ship Vista the use of WPF (or its precursor, managed code from the .NET framework) were specifically precluded from shipping in Vista. In other words, on the one hand a big bet did not pay off and was effectively put on hold yet on the other hand it was banned from inclusion in the product. This was a prime example of the kind of non-decision that was made at a time when the team desperately wanted and needed clarity. It would be only a matter of time until the Avalon team would just assume they would be part of Windows again and yet the whole Windows team that was shipping was making sure to never use the technology. Agree to disagree was a huge failure point.

Agile Execution

No topic caused me more personal grief and angst than the phrase agile execution. The concept of agile execution—seemingly a religion with terms like scrum, sprints, and stand-ups, as well as development process approaches that put experimentation on customers above all other methods—was top of mind on the Services teams. The team believed that the only way of addressing the poor results they were seeing was to move faster and become more agile. And while they were focused on this new methodology, the Vista team was gummed up unable to do things but somewhat irrationally believed that their problem was not taking enough time to get things done. The key leaders in Windows believed the problem with Longhorn was that the team was not given enough time, enough time to complete WinFS, Avalon, or other key initiatives.

The Services view was consistently expressed as “delivering internet services is entirely different than releasing boxed software.” The use of “boxed” was always meant as an insult specifically aimed at me, even if occasionally said with a neutral tone. The implication was old, easy, and irrelevant. A key aspect I was informed about repeatedly was: “Services do not use the waterfall approach, but rather they must iterate in the market.” Waterfall was another code word for old and dumb.

The problem with describing Office (or Windows) as waterfall was (and is) that this presumed a development process of writing specification and handing off to development and then later to testing—a sequence of discrete steps known as a waterfall. Implied was that there was never any notion of reevaluating what was going on, iteration, or that no work was done in parallel. Also implied was a perceived timeline of years. This was not how Office worked, but there was no chance I would change the minds of those arguing for agile. Whatever Office did, it was not agile, and the proof was that a product took 24 to 36 months. Still, Office iterated throughout the milestone process and also updated the product with hundreds of changes every month, and those were based on data of how the product was being used in the real world. But that was only evidence of maintenance not innovation, even though the vast majority of Services updates were simply to keep the services running and not new features—roughly equivalent in my book. There was little evidence of innovation in Services to counter this example.

As an aside, the concept of waterfall development has been misunderstood for generations. The first description of the process came from Dr. Winston Royce and appeared in the Proceedings of IEEE WESCON from 1970 in an article "Managing the Development of Large Software Systems.” Royce diagramed out what became the canonical waterfall process of gathering requirements, analysis, program design, coding, testing, and so forth. One discrete step after another. Royce, however unfortunate for us all, meant for that diagram to be what not to do. In the full text, he explained how critical it was to iterate at each step to be successful. Yet because of that diagram generations of engineers treated the process as a stepwise and discrete, one after another. Also, maybe IBM was to blame too.  Nevertheless, many on the Services and Windows teams perceived the Office planning process, including a vision document and milestones, as a waterfall approach in the classic and incorrect manner.

What I had learned as I gathered information ahead of writing my memo was that our use of these new agile methods was causing multiple real execution challenges. One example was the Spaces service, which was poorly architected for scale while racing to put features into market to compete with MySpace. In fact, they were asking me (the new person) for budget approval for a lot more data center spend because the costs per user on the free service continued to rise significantly and non-linearly—that is, each new user being added to Spaces was costing more than previous users. Clearly, that was unsustainable.

The most shocking example of management by self-induced crisis was Internet Explorer. In many ways IE was the symbol of a rapidly developed product, participating in the creation of “Internet Time” as it competed with Netscape 1995-1999. Once the original Longhorn plan started in 2000 to 2001, development on Internet Explorer was, for all practical purposes, shut down. In my first days on the job, I met with the recently reconstituted IE team who had been given a “hurry up and get a release done for Vista mission.” A recognition that Vista needed a browser as part of the Longhorn Reset.

Internet Explorer 6 shipped with Windows XP in August of 2001. Here we were, almost five years later, and while there was a great deal of activity in terms of security fixes and supporting the myriad of Windows releases, nothing substantial in terms of product features was released. Ironically, perhaps, the intention in 2003 was to stop releasing standalone browsers to focus on integrating and synchronizing the browser with Windows. IE had effectively ceded the browser war to Firefox (Google’s Chrome was two years away, but there were rumors of its development). IE was riddled with security holes due to the use of Microsoft’s ActiveX technology and components which were not architected for the modern security landscape, while also falling behind on performance and web standards. IE had become a pariah on the internet and attracted scorn from the developer community. Realizing this, a crisis was created by the very people who ended development and essentially commanded an updated browser in time for Windows Vista. This amounted to a classic arsonist-firefighter dynamic within a culture that always seemed to love a good crisis.

The good news, if there was any, was that Dean Hachamovitch (DHach, former Word and Office PM of AutoCorrect fame) was leading the new team, reconstituted from across the company. In the first meeting I had with the team, all the managers fit into one small conference room. The team was woefully understaffed for the work it needed to do. This was nine months before the product was to be completed. Dean was already exhausted, but we found ourselves allies. In talking about IE with BillG, SteveB, and KevinJo, the irony was not lost—voluntarily ending work on browsing after a fairly well-known legal battle was an odd choice, to say the least, and one I did not spend time trying to understand.

There was also the idea that planning and being thoughtful were archaic and the modern way of building products was via lean methods, as they became known—get an experiment or something “minimally viable” to market and then iterate. Though by this time, the biggest successes of these agile methods had also mostly imploded as companies. On the other hand, most people were consistently surprised at how long even relatively thin-featured products gestated before becoming viable and then successful. Managing every product like it might be the next Google search made no more sense than managing every product like it was a NASA mission. There was a rational approach in between, especially for products that were mature or necessarily focused on enterprise customers.

This issue as I would later discover was one that none of my new management receiving this memo would quite know what to make of. The conversation would come back to needing a plan and me returning to the reality that the team hadn’t ever developed and executed on a plan. That meant there was more needed than a slide deck with a set of features and a schedule, all while needing to find a way to agree to the highest level of development methodology.

It also meant that the odd-even curse around Windows might have been due at least in part to a lack of patience, and that regardless of my plan the team might not have the patience to see it through.

While on a recruiting trip I caught up with Sarah Leary (SarahL), the product manager who represented Office at the Windows 95 launch event. Sarah invited me to attend her class at Harvard Business School in 1998. Professor Marco Iansiti taught his classic case study on the development of Microsoft Word—the one where the Word team was called the worst development team at Microsoft by my future manager JeffH. Marco and I got talking and he invited me to spend the fall of 1998 helping to teach that very class with his colleague Stefan Thomke, which proved to be an incredible learning experience for me.

Marco later helped us to articulate our aspiration for agility as defined by Agility = Execution + Impact. This was a way to talk about three challenges all at once without having to define what agility really meant or even that it meant fast or, worse, faster. By focusing on execution, I was able make clear the issues of simply failing to get things done, like MSN Messenger working correctly for people with more than one PC or big features of Vista that were cut. With the addition of impact, I would discuss the issues of the Services team spinning their wheels while not making any strategic progress. This definition also helped me to avoid picking a specific development methodology which was about as appealing as choosing to become ISO 9000 certified (that’s a joke a few people will get.) Instead, we would focus on planning, plans, and timelines using my favorite methodology of “promise and deliver.”

To put a time scale on agility in my memo, I pointed back to ChrisP’s Shipping Software mantra (Chris was my manager in Office and had joined Microsoft to work on Mouse 1.0, Windows 1.0, Word 1.0, and also led Excel engineering, then Word, before leading Office.) I said we would aspire to a milestone-driven process, with more than one milestone, and a process to plan, execute, reevaluate, and iterate. I had a great deal of difficulty bridging my experience in product cycles lasting years with the perception of needing to last days, no matter how much we talked about how processes can scale while the absence of a process is still a process, known as chaos.

Across all teams there existed a cacophony of agile development that was defined as a cultural high-order bit. In many years of working with teams as they moved into Office or were aligned with Office, my experience was that there was some degree of correlation between teams executing poorly and a very specific development and engineering process that the team was overly proud of developing. Such a process was one the team pioneered and was deeply committed to, even to the exclusion of success. This wasn’t a causal relationship, but rather a correlation often seen. Certainly, teams with a unique methodology also executed super well, but that probably wasn’t causal though they believed it was.

The challenge, or properly my baggage (Office worked differently than Windows), was much more acute when speaking with the Windows teams. Windows felt they were not moving fast enough, but after six years of Vista the more general view was that they were not given enough time. This was rooted in the way that Windows NT was developed, with architects and a lot of upfront design (in practice, much closer to a historic waterfall approach). The project, which started approximately in 1989, was not ready for mainstream usage until almost 2000. And to many on the team, a decade was the expected amount of time needed to build robust platforms at scale.

The Windows team had a belief that Office shipped releases mostly on time by “cheating” because it cut features from the product before it shipped. PaulMa (pioneering manager of Windows, including NT, and former CEO of VMWare) often told me, “You just can’t cut things from Windows like you can in Office.” In any discussions about Office processes, I always felt a bit of OS snobbery directed at me. While this could have been my own inferiority complex, there always seemed to be that unsaid feeling that Office was the simpler product.

For what it’s worth, back in the day, Office people always thought that Windows was a perfectly good product to have in order to launch Excel and Word, but not much else. This was reinforced externally because Office on the Mac operating system was equally loved. We had our own expression of snobbery in Office.

The two gardens continued to exist.

There was another truth that emerged as I researched and tried to sell my plan. There was overall perception of Office, and by consequence me: aside from cheating by cutting features, I was confronted with the perception that I was a tyrant, literally. The reason Office shipped on time and was so structured was because of how I ruled the team—by terror or by some sort of iron-clad grip on process. The more I talked to people the more I learned of what I thought were crazy stories about how the teams worked, and how I worked—hearing them was like learning about some exotic culture across a vast ocean, not just another part of Microsoft. Not my Microsoft.

It was the first time I had to face the perceptions people had of me personally but also had to reconcile how those perceptions could be so opposite of my reality. At times the disconnect between perception and self-awareness had me questioning my sanity. I understood how I could be intimidating just as any executive could be, but at the same time I felt the team knew I was fully supporting them and worked hard to avoid the trappings that contributed to that perspective.

It was, after all, Windows where the manager punched his fist through a wall. It was Windows where people (including me) were regularly chastised in front of big war-room meetings. It was Windows where managers often found out about changes to their schedule or plans via rumors or indirectly. I did none of those things. I didn’t yell. I didn’t skip over managers. I didn’t escalate decisions (or tolerate escalation). Generally, my biggest offense was writing lengthy emails late at night with too many points in them, and sure, an occasional barb, though I rarely replied-all and did my very best to focus on ideas and products, not individuals in emails. That and refusing to go to endless meetings, especially early in the morning or when they were scheduled at the last minute were where I regularly messed up. Besides, how could anyone hold a crisis meeting for a strategic discussion?

Whatever my flaws as a manager, what I thought was going on was that the Windows team was looking at how they worked and assuming that to achieve the results that Office achieved it must be doing what Windows did but just more, or better. So, more escalation, more big meetings, more VP decisions along with better PowerPoints and shorter lists of non-goals (or is that longer?)

That wasn’t reality. But it was the reality I had to deal with, as out of body as it felt.

In hindsight I began to realize that the two gardens were not styles but deeply held beliefs. Each of Windows and Office operated the way they operated, and loved it. Each had achieved tremendous success in the market. Where I thought Windows achieved success in spite of how they operated, they saw their success as because of it, and vice versa. It just so happened that the most visible cultural differences were also almost the opposites: planning versus crisis, consensus versus singular leader, cult of team versus cult of leader, promise and deliver versus over-promise and deliver, and on and on. Even today, it can be challenging to describe the gardens without sounding judgmental one way or another.

Top of mind during this transition were some of the more legendary efforts at cross-pollination between Windows and Office. Several extremely talented and senior people in Office had taken roles in Windows only to quickly return to Office sharing tales of their adventures. And while there were stories in the other direction, it often felt like we had more success with Windows people moving to Office. From the outset, I was deeply worried about that sort of rejection knowing I had nowhere to go back to.

Our aspiration, Agility = Execution + Impact.

Discipline Excellence

Despite having thousands of engineers with more seniority (as defined by salary level) than any other engineering team in the company, the team did not have the depth or breadth of talent (human capital) to build products of the scale being attempted. Sharing this observation was scary. It was both counterintuitive in thinking and felt like the height of arrogance. To BillG who valued IQ above all and prided himself personally on the IQ assembled to build Windows, to express this was, for lack of a better word, insulting.

I used data to explain it.

Something PeteH once explained to me: “You can’t build a billion-dollar business out of 10 products each doing $100 million dollars.” What he meant was that the characteristics of a billion-dollar business are different than a collection of smaller businesses (he was referring to the struggles Microsoft was having in the Microsoft Home division). That pertained to my challenge at hand: we couldn’t create a product team at scale for billions in revenue with 100 teams of 25 people each. A 2,500-person product team operating in unison was qualitatively different than all those small teams added together, even if headcount was the same. Even worse, it was almost always the case that the bulk of the value delivered was due to a small number of those teams anyway, leaving most of the teams work essentially unaccountable or even squandered.

Windows was sold and experienced as one product, but it was organized as though 100 small teams came together to create that product while operating essentially independently. What was supposed to make Windows be Windows was how all the pieces fit together. There was no organization, however, to build that product. Simply put, the whole was not greater than the sum of the parts.

The driving force behind all the small teams was to empower people to work outside the complexities of the bigger team. The team had found itself caught in a negative reinforcing cycle. It was too difficult to get things done because processes were failing, which caused management to assign senior leaders to work out of band or off the books to get truly important things done (translation: make it a crisis), which made it harder to integrate those into the product and amplifying the overall difficulty of shipping the whole of Windows. The empowerment led to poorly integrated and architected products such as Media Center and Tablet PC, as well as disconnected core architectures such as DirectX graphics, Networking, and Security. The success of early Internet Explorer working this way reinforced this as a methodology, but all that came to a standstill once the goal of the product was to integrate it with a whole.

That would be challenge enough, but accelerating this cycle was the existing approach to managing. In order to conjure up these small, agile teams, management pulled people from the ranks and gave them responsibility for managing a team of developers, testers, and program managers—creating product unit managers, PUMs, or multidisciplinary managers, MDMs (the HR expression). PUMs were a direct manifestation of the old list of people and problems, formalized to an org structure.

For a culture that loved a good crisis, the heroics of being a PUM managing a crisis became an aspirational job. As I was making the rounds talking with middle managers before writing the memo, a frequent topic raised was the desire to become a PUM, and my view of the career path to become a PUM in my new world. When speaking with PUMs, I heard time and time again, “I work best overseeing a small, multidisciplinary team.” The problem was the lack of supporting evidence proving that point. Being a PUM was a career goal for nearly every mid-level engineer, not being a great engineer.

A direct result of pulling people from the ranks and promoting them to manage multidisciplinary teams was to cut off the pipeline of talented engineers and, more specifically, program managers. The very people who would be called upon to scale and manage larger teams of engineering leaders were robbed of the depth of discipline expertise that would train them to do so.

As if this wasn’t enough, these new leaders were then responsible for hiring, mentoring, and growing the next generation of leaders in job functions they had not even done at any level of seniority or tenure. As a result, most of these teams had a management structure where the PUM was also filling the role as development manager or group program manager (the titles for the role of leading the job function). This further stunted the development of new leaders.

To illustrate this point, I compiled the statistics of the approximately 40 product units in the Windows and Services group (not including COSD, but the numbers matched almost identically). It revealed that half of the product units were being led by people who would not have been senior enough to be discipline leaders (dev managers, test managers, or group program managers) in Office.

The lack of seniority was immediately recognizable in program management, arguably the most crucial role for achieving synergy in product design and features across a single product. Overall though, Windows had more senior employees than Office, but they were allocated to pure management roles, PUMs.

The quest for PUMs and autonomy had pushed all the relatively senior talent to be managers of managers (or their managers). That was a shocking realization. This was also a generational problem because the presence of PUMs robbed the junior engineers of opportunity. The Windows team had been robbed of a generation of talent development.

Perhaps nothing was more shocking than the Software Test discipline, where, once again, I was up against a long-held belief, by BillG and SteveB in particular, that having testers was not a sign of success but somehow represented a failure of tools and processes in engineering. For many years, I tried to have this debate or discussion but simply ran out of ways to sound anything but defensive. But in truth: there was no engineering or manufacturing, in any field, without the role of quality assurance, and the more complex a product the more testing it needed. Software projects brought with them two unique characteristics not seen in hardware or manufacturing. First, Windows for the most part provided programming interfaces to developers who would do all sorts of things, some expected but most not. Testers came to work and found ways to exercise APIs by writing adversarial code against them. Second, every release of Windows shipped supporting every previous release and previous capability on all the hardware that existed and all the hardware that would exist. Of course, Windows had enormous libraries of automated tests and more being added all the time, but all they could do was tell you that you had not broken something that already worked the way you thought it should work. There is much more to testing. I understood that start-ups and smaller projects could do without testing, as Microsoft had in the early days, but complexity, extensibility, and backward compatibility caught up to every product.

Later, when I made my case after sending the memo, I experienced a lot of friction on the topic of testing because SteveB as CEO had been pushing teams to reduce headcount as a cost-saving measure. Both Services and Windows had reduced headcount by reducing testing and moving responsibility offshore or to vendors. The Services team, where there would normally be one tester for every software developer, had half as many. As we learned in operating internet services in Office, testing wasn’t reduced but rather shifted to and shared with operations, which was also understaffed.

Tactically, our plan was to aim for two important structural changes. First, we would dramatically reduce the height or depth of the organization. This was something that SteveB would get excited about as he had been trying to get people to understand Jack Welch’s General Electric approach to org span of control and depth (at this time, everything Jack Welch said was undisputed business canon). SteveB had run up against PUMs and the depth and minimal span of control that model imposed on an organization. This would dramatically alter the jobs and career paths of dozens of the most senior people on the team. It would be a very expensive change to undergo.

Second, I proposed reducing the number of pure managers, those with no line of responsibility but who had management oversight. They did not write code, specs, or tests but focused on the process. Some were needed, but the organization had too many, which contrasted with Office where even the most senior discipline leaders were managing people and writing code and/or fixing bugs.

At the strategic level I used this memo to begin what I knew would be the most important management journey of my career: restructuring the Windows and Services team into a functional or discipline-led organization.

A reality I could count on was that it seemed nothing could have messed up the Windows business, and hence all of Microsoft’s revenue and profit, at that point. In hindsight, what Windows had was the greatest product-market fit in the 20th century, except maybe for oil. That stability enabled the company to thrive during macro issues of recessions and wars. It thrived throughout the largest antitrust trial in our lifetimes. It thrived through successive changes in leadership and company reorganizations. It thrived through a restructuring of the PC manufacturing industry. More than anything, it thrived despite products receiving lukewarm reviews at best and a lot of releases being broadly panned, and nearly every single product being released to market years later than planned with notable quality issues.

Windows had no trouble surviving the odd-even nature of flawed products and changing leaders. To date, there had been no credible competitors or alternatives.

As I write this today, I realize just how wild that sounds. It was, however, true.

In one exercise, my colleague Adrianna Burrows at our communications firm WaggEd researched key product reviews for all the Windows releases going back to Windows 3.0. Surprisingly, out of that selection, while some were glowing (Windows 3.0 and Windows 95) most were lukewarm to good (Windows 3.1/3.11 and Windows XP), and many were quite painful to read (Windows 98 and Windows Me). Windows Vista was shaping up for reviews akin to the latter. Looking back on the reviews solidified my opinion that there was much more of a Windows challenge than a Vista-only challenge. The business model and momentum were sustaining the product, not the march of consistently improving products and increasing customer satisfaction. At one point, I even suggested to SteveB that Microsoft would have been fine not shipping several of the Windows releases. Heresy. To be fair, in Hardcore Software I have pointed out that absent the contractual obligations and staggered adoption of Office, it is not entirely clear the same would not be said of Windows.

While I did not have the vocabulary of product-market fit, I knew that I had the luxury of being patient and deliberate. SteveB showed restraint, even though every bone in his body wanted something fast. I was not going to rush. I was not going to have a short-term tactical plan to show we were awake or listening—something that had been suggested many times by those more senior than me and in subsidiaries. I knew we would spend a lot of time in push-pull conversations, but ultimately, I believed I had the support to do what I thought needed to get done.

The goal was to have the whole organization collectively, including COSD, deliver one Windows product to customers, OEMs, and enterprise/business customers. The cardinal rule of having everyone finish at the same time was to have everyone start at the same time. But with the Windows team still finishing and also about to undergo a major organization change, I needed to develop a hybrid approach. This would also remove some of the pressure at the company level to show progress or, worse, to make sure we did not look like a few thousand engineers were going into hiding.

In this transition memo, sent to BillG, SteveB, and KevinJo (which I sent when Vista was still six months from shipping), I proposed an entirely new organization and a rationale for why we were going to operate together as one.

On to 087. Reorg! Why Are We Together, Exactly?

Everyone in their career should have one memo that they think of as the most consequential. For me, it is a memo I wrote after a about six weeks on the Windows team. Under intense time pressure to figure out what comes next with Vista rapidly approaching final release (not formally, but it was going to soon be all but impossible for code changes to make their way into the product) I had to come up with next steps. Over the next four posts, I want to share not just the memo but more about what it is like to live through a major organizational crisis and work to set things up for building a new engineering culture and new team structure, all in a couple of months.

Back to 084. How Many On the Team, Exactly?

The history of Windows releases was cursed when it came to product and leadership. Like Star Trek movies, Windows releases alternated between good and bad, odd and even. Line up the OEM products by availability date, and you’ll see this is basically true—starting at Windows 3.0 and changing to the NT kernel with XP (3.0, 3.1, 95, 98, 98 SE, Me, XP, Vista.) Compounding this, the curse says, no leader seemed to last more than two major releases of Windows.

My neighbor, a successful biotech entrepreneur, asked me about the curse the day he read the org announcement in The Wall Street Journal story saying that I was moving to Windows. He wished me luck.

After 140 scheduled 1:1s, 20 team Q&A sessions, over 30 hours of office hours, and countless hallway conversations in a dozen different buildings I had to do some thinking and organize what I observed, heard, and learned. That meant writing.

A dose of reality was needed with BillG, KevinJo, SteveB, and to some degree even the Board.

I did that with a 20-page memo titled Observations, Aspirations, and Directions for Windows and Windows Live. For me writing is thinking and I really had a lot to think about, hoping others would join in. I felt alone for long enough and I was certain SteveB was growing increasingly anxious for what would come next. I had been talking to KevinJo constantly over the past few weeks as he was doing a huge amount assuaging those that essentially rejected the idea of an Office person leading Windows.

The 20 pages were the most difficult I wrote in my entire career—to literally put these words down—I knew they would be impossibly difficult to read. I was deeply concerned that what I wrote would be viewed through the simple lens of setting expectations or painting as bleak a picture as possible so that I could be a hero later.

It seemed that everyone, especially SteveB, wanted the plan for getting things back on track and a product roadmap. He also wanted to be able to communicate to the field and bring comfort to customers, while continuing to support Vista when it shipped. Bill was especially keen to restart discussions over product investments that had been cut since the Longhorn reset. Kevin was getting his footing across wildly disparate businesses including the massive money-losing online services.

I couldn’t kid myself, however, as I too needed a plan. The team was still frantically fixing bugs, but in order to ship by October that would soon end. The bar for fixing bugs would rise dramatically by summer. Idle hands will make trouble for sure. Projects will start, code will be opened up to changes, and worse presumptive commitments to outside customers and partners would be made, and so on (all business as usual for Windows.) For there to be a release that addresses any challenges I would need to orchestrate that every team at a project arrive at the starting line at the same time in order to finish at the same time. In other words, I had only about four months and one shot to get all this figured out.

Adding to the stress, the OEMs were extremely anxious as they were reeling from Vista missing both back to school and holiday selling seasons. They were used to hearing plans, or at least slide decks, about future releases so they too could plan, as much as that was worth. A January launch was painful for PC makers as it meant they had to stock up retail outlets with PCs unsure if the buzz over a new OS release would dampen Holiday sales or not, and then deal with upgrades new customers demanded on those PCs. It was messy.

In round numbers, fiscal year 2005 had revenue of about $40 billion and net income of about $15 billion. The Windows OEM business on its own was $12.2 billion (about 30% of Microsoft—incidentally it is not possible using public data to compare these to today’s Microsoft, much as people claim to) and $9.4B in net income (about 63% of all of Microsoft). OEM revenue was highly concentrated in six major and global PC makers, each CEO with a direct line to SteveB and KevinJo.

My memo solved for none of these immediate issues. Instead, it was a lot of bad news and, in contrast to conventional wisdom or expectations, was less about strategy as it was about execution and culture. It diagnosed, without blame, the situation as I saw it. I provided a ton of data about the organization. I detailed structural problems that I was worried would feel trivial up the management chain. It was a lot of work to count the number of people and find out how much money was being spent (on projects, not salary). It was disappointing that for all of the staff and managers, the most basic controls over dollars and headcount were not in place.

Something BrianV once told me really stuck in my head years earlier. In his inimitable way he reminded me, “There’s just a lot of s**t going on in Windows all the time.”

I was fast learning he meant that in every way possible.

There’s an old business story usually called “The Three Envelopes” about an incoming executive taking over a dysfunctional team. The outgoing exec offers advice to the successor in the form of three envelopes, with instructions saying, “when things get tough, open them one at a time.”

After a bit of time, things indeed got tough. The new exec opens the first envelope. It says, “blame your predecessor.” They do and it buys some time. A bit more time passes, and things take a turn for the worse, so the second envelope is opened. It says, “plan a reorganization” which improves things. Some more time passes and desperate for help, the third envelope is opened. This envelope reads, “prepare three envelopes.”

Good grief, I thought. I felt like I’d become the punchline to a business joke.

I promised myself I would never blame my predecessor and never ever did. I went out of my way to avoid that not only myself, but to remind people not to do the same. There was no escaping we were going to enter some new era as a team, hopefully for the better, but I was not going to permit our time to be defined as positive compared to a blame-worthy negative.

I was troubled, however, because I knew we were going to reorg. I really thought I could get through this change without becoming a living cliché, but as I quickly realized sometimes a cliché is born out of countless experiences. As it turns out, most of the time to fix a dysfunctional team there’s going to be at least changes in leadership if not structure. With so many of the leaders choosing to make Vista their final release of Windows, I would need to hire replacements, so why not new jobs? The memo was a precursor to much larger changes and designed to motivate those changes with facts, not blame. Unlike most reactionary reorgs I had seen (at Microsoft and elsewhere) it was also not based on swinging a business pendulum in the other direction as is often the case.

I continued to be concerned there was a perception that if we could just get a good strategy deck then my job would be to do what I do, which was to be a tyrant—take the new strategy and execute. The strategy wasn’t there, nor would it be, but I viewed that as a third-order problem. Besides, strategy without a product plan isn’t really a strategy. As the saying goes, “culture eats strategy for breakfast” (often wrongly attributed to guru Peter Drucker.) I was under no illusion that the current team and structure presented with even a perfect product strategy could execute it.

The engineering culture was broken.

In fact, over the previous few years, while SteveB had been increasingly leading the company, he embarked upon initiatives that presumed execution was the key problem to address. Key among those was an updated performance review system based on “commitments.” Everyone was required to document their commitments (goals, tasks) and share them up and down the management chain for review and approval. On some level this is a solid approach, and in start-ups the concept often works well (such as the well-known OKR process used at Google). At scale, however, this type of process too often devolved into people gaming the system with vague commitments or aiming to set low expectations. I was not a fan. That wasn’t going to help this team.

There was a special difficulty in diagnosing and sharing execution and management problems with two people who basically never had managers, BillG and SteveB. KevinJo, on the other hand, was an expert in scale management and a true ally in this regard. In fact, he had clearly orchestrated many more people than I ever had. Adding to the degree of difficulty was to what extent they would, especially Bill, take my assessment personally. I was quite concerned that I would come across as way off base on what needed to change, and even more concerned that this would not go well. Perhaps worse, they would think I was blaming their leadership and JimAll’s as well.

I was having flashbacks to a mismatched conversation with SteveB about Windows Phone leadership (c. 2000) and what was needed back when Steve was looking to change phone leadership for the third time in as many years. He ended up talking to several other product leaders, each of us saying essentially the same thing—the phone needed a full reboot, in the team, business, and code, to compete with (then leader) BlackBerry. There was a mismatch that continued for quite some time.

Avoiding an early product strategy discussion was important. The easiest thing for execs to do in time of crisis is debate the specifics of product features. In those discussions, there’s a strong desire for a silver bullet—one change, one addition, one synergistic initiative, or one deal—and then to ignore all realities and externalities and rush execute that. We were in the midst of the Vista project which itself was designed around both synergy and silver bullet features, such as WinFS and Avalon.

Above all, this would all be extraordinarily difficult for me because I’d been either watching or participating in this brewing problem for most of my career. I had come into this role not thinking there was a Vista crisis but thinking there was a Windows crisis, years in the making, with Vista merely the latest symptom. It was not just the odd-even curse of releases but the challenges we had collaborating because of the differing methodologies of the two gardens, which was difficult in the best of times. Not only would I have to break free of my own prejudice, but any visible display of prejudice would immediately snowball into a horrible situation that would be perceived as something of a hostile takeover of Windows by Office. Given that Office was always viewed as the subservient business and technology, this was not acceptable.

The risk of being rejected outright by the Windows team was very real, much more so than the external view of the savior arriving.

Working to my advantage were the ever-present “quality of life” challenges the team faced. Most every discussion—1:1, team meeting, or small group—was much more about the way work was done rather than what work was done. There was a deep-seated victim complex, and the perpetrators were management at every level and some specific managers/execs. I abstracted these concerns to what I considered three relatively mundane concepts, the kind found in any management book, and illustrated them for BillG, SteveB, and KevinJo with some concrete and dramatic numbers. The details on the Services teams were decidedly different from Windows, though the issues were largely the same. In fact, the challenges were identical, just manifested differently owing to the delivery of code and business model more than anything.

While I diagnosed three main areas to work on, areas that would motivate the proposed changes I was going to make, I spent almost five pages on a situation analysis. Writing about the way I saw things at the time I shared some of the following (summarizing from the original):

Engineering Skill. Windows has the industry leaders in PC technology, having invented much of it. In industry technologies ranging from Wi-Fi, USB, printing to Microsoft’s own technologies such as Hyper-V or DirectX, the team has unmatched and extraordinary technical depth. Translating that depth into high-performance, secure, robust, production code has been challenging. The Longhorn project showed a great deal of technology potential but across the main initiatives there was a broad inability at every level to turn that into products.

Fatigue. The Online Services team has been running non-stop for years, releasing every month and spawning new projects, but with little in the way of product success or share gains to show. The recent financial results causing a pullback on headcount growth have really left the team shattered. The Windows team is on year 5, though optimistically it is only year three since the reset. The recent schedule change all but cancelled summer and the holiday season for most of the team. The team is fried.

Maturity. There is a decided lack of subtlety or nuance in how the team approaches problems. By and large even the most senior people think and act locally, almost in survival mode. In discussing the situation with senior people, they invariably jump to unsophisticated solutions such as cancelling projects or putting groups under a single manager. The idea of being both fiscally responsible and investment minded is difficult for most to grok.

Bloat. The organization is bloated with middle management. There are too many multi-disciplinary managers (PUMs) which (as will be discussed) create a deficit of senior engineering leaders. This creates an absurd engineering structure where small groups flail on problems too big to solve, escalating to a PUM who has the sole motivation to keep the decision local for fear of losing control while lacking the personal experience to adjudicate the issue. This bloat also caps the ability of the organization to grow senior engineers.

Science Projects. The organization is filled with science projects. These are projects operating as though they are building product features, but they have little chance of achieving critical mass and an even smaller chance of remaining sustainable over time, if they ship at all. One way to view this is how cool it is to be exploratory and entrepreneurial. The vocabulary used to describe these is always “delivering value to customers” which is far from the reality. These continue despite the broad view of a resource crunch.

Hiring. The lack of deep excellence in senior leadership for development, testing, and program management creates a difficult hiring situation. There exists a highly distributed hiring decision process and a large number of open heads. This pressures relatively junior people who are under the gun to deliver to onboard any “warm bodies” they can find and in doing so these hires are often over-leveled or over-compensated, creating a down-stream fairness problem for the whole organization. The PUM model often drives poor calibration for promotions simply because the PUM sees people only through the lens of a tiny team they are trying to hold together.

Competitive Fire. There is a curious lack of competitive fire relative to Macintosh, Linux, Google, and Yahoo. There is a broad and vibrant spirit around the concepts of providing software that competes with these companies, but a clear lack of understanding of how what we build stacks up and what we are doing about it. For the most part this shows as an organizational challenge since everyone thinks to be competitive everything must be under one person and nothing is today. This was particularly odd as I was already running Linux at home long before this job and posting unboxing videos of the iMac to YouTube. I saw few Macs, iPods, or Linux boxes anywhere. In fact, the team was even lobbying to prevent the use of Google search at Microsoft’s firewall. Everyone is aware of these but thinks competing is the job of a mythical compete team or belongs in a compete lab, not just in daily use. This is not just at the top level, but at every subsystem where the technologists are not aware of how competitive platforms support an industry standard technology.

Bureaucracy. The engineering process is loaded with universally accepted yet loathed and mindless bureaucracy. For Windows, the processes pushed down to teams in the name of security, builds, quality, etc. are not yielding the results but forcing people to spend creative energy working around those processes hoping to get something done. In Services, thought and judgment have been replaced by a Rube Goldberg set of key performance indicators that themselves would make for a case study in how to make sure things don’t get done. Even the most basic corporate administration work from finance, to legal, to administrative assistants seem over-staffed relative to headcount. Here again the tiny teams headed by a PUM create excess overhead.

I was rather reluctant to share the above. I recognize just how harsh and potentially insolent these statements were. Any one of them could be taken out of context as too broad an indictment of too many or worse about specific people. For each I could offer specific examples if called to, but I so much wanted to avoid this becoming personal. I saved specific callouts for things that were clearly going well or simply stood out relative to these themes.

This was a brutal list. I remember meeting with BillG and seeing his felt pen markup, his callouts, all over this section of the printed memo—and we debated many points he did not agree with. SteveB was deeply in touch with the management challenges, and his unusually silent agreement spoke volumes as I felt he was disappointed to see these findings while also relieved, in a sense, that someone was willing to diagnose and address them directly.

The bulk of the memo documented three areas in need of attention: decision-making, agile execution, and discipline excellence. I presented a situation analysis with supporting facts and data. To avoid being super negative, I also suggested what our aspirations would be for each of these attributes.

Initially, these felt rather anodyne but soon became rather crisp talking points for what amounted to my stump speech as I began to engage a very small set of people such as Ray Ozzie (ROzzie, now CSA) and Dave Marquardt (member of the Board). I perceived a consistent feeling of uncertainty over what to do with my assessment. The questions were much more about what to do—when WinFS would get done, or what should we tell the OEMs. In KevinJo’s case, he simply agreed and said we need to just keep moving and asked how he could help. He was so supportive.

Decision-making was the first topic to address. Windows was an organization that loved decisions. They loved having decision-making meetings. BillG and SteveB were always meeting with the team on important decisions. What could I possibly mean by decision-making and what should the team aspire to?

On to 086. The Memo (Part 2)

Much of what Hardcore Software has been about was what we were building (and why). This chapter is about how. Specifically, I wanted to delve into the management structure and what we worked through to restore efficacy and build a new kind of Windows team. Over the next few posts, we will journey through understanding of the cultural challenges the team faced, figuring out a plan to lay the foundation to address those, and then putting that plan into action. This first post gets to the core of understanding what precisely the team is building by figuring out how many people work on what projects. That should be simple, no?

Back to 083. Living the Odd-Even Curse [Ch. XII]

When you move into a new job there are a lot of things that need to come first, too many. You want to touch base with the most critical individuals, but don’t want to minimize the importance of those less so. You want to focus on the high priority areas of work, but it is times like this that the lower priority work hardly needs to be reminded of that fact. You’re dying to ask a lot of questions, but people are dying to tell you things. Then there’s the political reality that the many things pushed to you or that arrive in your inbox are often those least needing your attention, but most likely to notice a lack of attention.

I had all this to think about while both being reminded of Windows Vista every day and needing to let the team in place finish the project without interference, inadvertent or otherwise.

It was extremely weird to commit myself to learning about Windows and the Windows team. I had, after all, essentially grown up around it, just not in it. I knew the Windows product. I knew the Windows people. I just had no idea how the people made the product. I knew the organization at a super granular level from Windows 3.x and Windows 95 working on toolbars and app compat and the shell from C++ and Office. I knew things at a strategic and executive level.

I had a high-altitude view of the organization, and I knew a lot of individuals, but between a few feet off the ground and 50,000 feet above the ground I had a lot to learn.

Little was as it seemed, however, when it came to the details.

There’s a well-known military principle on knowing the difference between lessons and lessons learned, between reading about something and having learned that same thing through the experience of changing how one operates. Any management book will tell you to know the budget and resources on a team and that’s a good lesson. In the Microsoft culture filled with cookie licking, shiny objects, and side projects my most important lesson learned is to actively track how many developers there are and what code are they writing. Every time I was uncertain of what a team was actually building or if a project was real, understanding the number of developers assigned to which code was the most valuable information to have and the most critical to keeping a project on track. I learned that with NetDocs, the Tablet PC, and so many 1990s internet projects long since passed. Everything other than actual working developers is just talk.

Therefore, the first thing I chose to do was to get a handle on the composition of the team. With the help of Kristen Roby Dimlow (KristenD) from HR, one thing became clear: I was in a new world. KristenD was previously our finance partner in Office, coincidentally, and brought with her a refreshing analytical view of the structural challenges I (now we) faced. Kristen began immediately trying to collect the data on who was doing what.

In Office, headcount, resource allocation, and org structure were readily visible and, for the most part, easy to figure out by looking at the company’s online system headtrax. Windows was a different apparatus. While there was a headcount number, what they were working on, for whom they were working, and even their actual physical location, were all less clear, or fuzzy.

In keeping with Windows tradition of reorgs that “split the baby,” or product organizations that were structured such that accountability and ownership were muddled, the job I was given was not as much the “Windows job” as most would at first perceive. This wasn’t a surprise at all to me—I knew what I was getting into. This was the Windows Client team previously described. COSD remained separate as it was already.

To KevinJo and SteveB, accountability was clear, even if the organization structure and people were not. This was typical Microsoft accountability in the 2000s. I was their Windows “guy” and decidedly on the hook to figure out what comes next. Kevin had a huge amount to figure out. He was clear just how much he was hoping I could wrap my brain around with respect to “what comes after Vista?”

Along with the Windows client, there was Internet Explorer and the user facing side of Live services—the split of everything down the middle was alarming when it came to accountability, but just how alarming required more investigation.

The Live services represented a lot of headcount but the revenue numbers did not seem so big to me at the time. By Microsoft Online Services standards there was significant revenue associated with Hotmail and Messenger. Hotmail sold display advertising, perhaps $300-400M worth. The ads were intrusive “right rail” ads that took up the right side of the screen. The running joke was that the most popular ad was for a toe fungus medicine. The team was working hard to try to sell Hotmail Extra Storage, upgrading to 10MB (later 50MB) for $19.95 per year. Google’s Gmail had no ads and essentially free unlimited storage. The unlimited storage was not a gimmick, Google invented a novel “infinite” and reliable storage mechanism enabling the capability. MSN Messenger was selling ads inside the client application (less than Hotmail), also intrusive, though the move to mobile phones and the growing competition from Skype were both problems. In other words, the few hundred million dollars in revenue was not remotely sustainable and at the same time the products were struggling.

Almost an after-thought in all the discussions about me taking this job was the fact that I would also manage the new homegrown Search product, which was recently branded as Live Search. It would not be Bing for another two years. The team was growing rapidly (up to almost 100 engineers) but was still very new and clearly a very distant competitor to Google (with over 10,000 employees). The first beta test of Live Search started just weeks before I joined the team.

Christopher Payne (ChrisPa) was chartered with leading the team. He was the vice president and team founder and had returned to Microsoft to lead many of the MSN Services efforts. In a moment of boldness for a team under a great deal of fiscal pressure, in 2003 he proposed to BillG a massive effort (expensive investment) to build out a search product that would compete with Google. This included maps, instant answers, books, and more. At the time, as crazy as it sounded, Search across all of MSN was a hodge-podge of business development deals and outsourcing—to compete with Google. In his prior time at Microsoft, Christopher (he preferred his full name in spite of the email name) was a product leader on the first versions of the Access database product in Office and some of the early MSN properties (he later went on to run eBay North America and is currently COO of DoorDash).

Over two years or so, the Search team built an extremely credible effort, first releasing at the end of 2004. The team was the first fully organic one at Microsoft, tasked to build scaled cloud services, employ artificial intelligence and machine learning, and create the kind of tools Google had developed to automate and manage tens of thousands of servers in multiple data centers. Many of these pioneering efforts were critical to Microsoft’s cloud data centers over the next decade.

While ChrisPa knew what he needed to do from a product and technology perspective, there were only two things holding the team back. The first was resources. The team needed to spend a lot of money on capital expenses for servers and data centers, as well as hiring more people. Second, the team needed to be given the time to build much more of the product and technology base before being pushed on revenue—they were far behind Google and the complexities of overlaying a new advertising business did not seem prudent at the time. Google was doing about six billion dollars of revenue directly on search that year, doubling year over year. It was already a juggernaut. In 2003 at the exec offsite, Payne said it would “take at least 18 months and $150 million dollars to even enter the race with Google, and that it was critical we own our own search infrastructure.” The first time Christopher and I met (as part of Search and Windows) he told me he needed an additional $1 billion just in capital equipment (data centers) next fiscal year and revenue was not yet a priority.

As I would learn, there was only so much patience above me.

Combined we called all of these “Windows and Windows Live” and my official title was Senior Vice President, Windows and Windows Live or WWL (I was already Senior Vice President of Office, another fact several people pointed to as evidence I was not up to the job.) COSD continued to report to Kevin, though figuring out how to manage and organize it was all part of our ongoing efforts.  That meant the broad view was that there was WWL and COSD, just as before there was Windows Client and COSD. To some this was comforting. To others they were waiting for the other shoe to drop.

To put some numbers on all of this: There were approximately 3,500 full-time R&D employees in over 30 cities around the world for WWL, with about 1,000 software design engineers. In Office, we worked using ratios that would translate to 1,000 software testers and 500 program managers, compared to WWL, which had 750 testers and 600 program managers. We had only a handful of managers to oversee multiple job functions (Office 2007 had about 10), but this organization had more than 40.

COSD was a bit larger with about 4,700 people (in most every country Microsoft did business), but more than 1,500 were part of a major push to move all bug fixes and servicing of old releases of Windows to India. This was a radical out of sight, out of mind move designed for cost-effectiveness, and something we did not do in Office. COSD also had about 1,000 software engineers, but over 680 program managers (and not much user interface!) and about 1,000 software testers (about what one would expect). COSD had another 40 to 50 multidisciplinary managers.

The number of vendors and contractors and open positions in WWL plus COSD product development approached 10,000 people. Yikes. The number of open positions was astonishing, thousands upon thousands. Not only could they never be filled, but the question was also how would they have helped to ship Vista? That couldn’t be more different than what we did in Office.

Perhaps the most surprising data point was that almost one third of the team was managers and there were easily seven, and often up to nine, levels in the management hierarchy. Office was about 20 percent managers and rarely more than five levels of hierarchy domestically. Another measure of complexity in the system was the number of cost centers. In Microsoft lingo, a cost center was a locus of financial controls, budgets, and headcount monitoring. In practice, it was a numeric field in SAP. According to finance the mere existence of a cost center was about $100,000 a year in operational overhead. In actual practice, every cost center was a headache as it was another place someone could come up with unique budgets, costs, and headcount, and when everything was considered for one product release, cost centers became overhead and bureaucracy. Windows had around 300 cost centers. By comparison, Office had about 30, and most of those were needed because people were paid in local currency and a cost center could have only one currency.

Mini-Microsoft was looking more and more accurate. I was beginning to understand why I thought Mini was so off base when I compared what they said about Windows to Office.

I completed an inventory of the products and projects that were underway, and resources assigned. Doing so felt a bit like an excavation. There wasn’t a single place where the allocation was tracked. Finance knew how many dollars were budgeted by cost center which were created to essentially streamline accounting or sometimes to park open headcount. The projects underway were mostly tracked by multi-disciplinary managers (MDM, or PUM for product unit managers). The mapping of projects to products or a roadmap of product releases didn’t exist. Finance had one view of open headcount which had little correlation to the view HR had for recruiting. It was quite chaotic. When asked, managers had a solid idea of what they were doing but that certainty did not roll up in either a strategic or fiscal sense. Compounding this were what I came to call “headcount gymnastics”. In order for one group to rely on a contribution from another, groups engaged in headcount bartering where heads were offered or loaned from one group to another as a way of creating accountability or a reliable contract for work. Absent headcount gymnastics, partnerships or collaboration between teams would be subject to the whims of PUMs. I suppose.

I knew about these gymnastics because more times than I could recall, Office was asked to support something new in Windows and as part of the ask they would provide headcount to get it done. It should be readily apparent as to why this is just not going to work, but when you think about it even for a bit you realize just how absurd such a system is. It basically says that headcount is the tool for changing the priorities of a group. If you don’t want to do something then you don’t want to, and the idea that if you had more headcount then that thing you were asked to do is the thing you’d choose to do next is absurd. That’s on the face of it. There’s the second order problem that headcount is not the same as a human being, a developer. It means the receiving group, the one that signed up to do something it didn’t want to do naturally, has now committed to do that very thing but has no person to get the work done. If one continues to play this out, then you ask all sorts of other questions about what schedule the work would get done on and what would happen if the work required changes to parts of a system that were not open to accepting changes (for a variety of reasons) at that time. I could keep going but it should be clear operationally why this is awful. Yet, this is how almost everything worked.

Let me indulge with a brief view as to just how broken headcount was and how key this was to the whole mess I was now facing. There are some basics of all software projects, among them there is always more that the team wants to get done at any given time than is currently planned and that adding more people once a project starts not only fails to help get more done, but likely will result in less efficacy. There’s a simple corollary to these rules, which is that most every project will end up scaling back work as it progresses to finish on time. Said another way, projects don’t get more done by the end than they said they would get done at the start. These basics go back to the Mythical Man-Month, one of the books issued to every new Microsoft developer going back to the earliest days.

Therefore, the basic way we worked in Office (also for as long as I could remember) was that projects were planned to use the number of people currently in place at the start of the project or milestone (sub-unit of a full release). If you don’t have a human who can start the work, then whatever work was under consideration doesn’t get put on a project plan. Groups that were growing had open heads but did not commit to work based on filling those heads.

This makes it very easy to know what a project is actually going to accomplish because everything without a human assigned to it simply won’t get done. It will only get done the next time the team regroups, builds a new plan, and starts. In the case of Office this took place every milestone (projects had 2 or 3 milestones) and in the large every release.

A big part of how we ran in Office then was to free everyone from ever thinking about headcount, ever. There was really no process to request headcount. We started a project with a known number of people. Every team could hire people to replace attrition. And then every new project cycle we assessed where we wanted to spend resources and increased, decreased, shut down, or created new efforts. Lather, rinse, repeat. We grew the Office organization from 350 to 2,500 over a decade using this deliberate approach, and never had thousands of open heads.

Whenever we wanted to do something entirely new the first step was to create the team by reallocating from our existing teams, in a significant enough way we could execute the whole project just as described above. This is how we created OneNote, SharePoint, InfoPath, and even the original Office Product Unit. By starting new efforts this way, we benefitted from having experienced people volunteering for the new work who were committed to seeing it through and we never went through a period of one manager telling us they are still hiring people to do the work.

Some reading this description would be critical and point out how this lacks agility. They might suggest that this does not allow for flexibility or entrepreneurial thinking. What if a really great idea comes up or a competitor does something requiring a response, people would ask? Easy, change the plan, allocate people to that new thing, and scale back or cancel something else. What if something is much more difficult than originally conceived and there’s no way to get it done without more people? Easy, the team really messed up and either we immediately reallocate from elsewhere on the team or we kill the feature.

Why are all these so “easy” then? Because anything that relies on hiring, onboarding, training, and getting up to speed with people that don’t currently exist has zero chance of getting the work done in conjunction with the rest of the product plan. If the business wants credit for the feature then it is going to want it to finish with a release on some schedule, be incorporated into marketing, and launch. Otherwise, it probably won’t exist for customers anyway.

Were there complaints or grumbling? Of course and primarily along the lines of “we could do so much more” which was hardly specific to any single team.

There’s a certain psychology that takes hold while building out a product plan once execution starts. There are people who always think about “just this one more thing” or “if only we could also do this too.” They fall into the trap of believing that it is always one thing that makes all the difference. That one extra thing. But it is never like that. And on the outside chance it is, then it is far more likely that the whole of the plan was not that great in the first place. That one last thing is never considered in the context of the entire plan, rather it is just in that one moment. That’s the whole flaw with planning by headcount rather than holistic plans based on people that exist, ready to do work.

Ultimately, the key for how we worked in Office was to remove headcount from ongoing discussions. There was never a headcount request or approval process. Everyone was expected, and did, simply work with what they had. The deal from management (at every level) was that we lived with the tradeoffs teams made along the way. Into that process of tradeoffs, we baked in a culture of commitment to partnerships across the organization so we avoided one group prioritizing locally at the expense of other groups depending on previously committed work.

Windows (and Windows Live) had almost the mirror image of this approach. Nearly every team ran with open heads that sometimes approached half their existing team size. It was not just that the team was always hiring (we were always hiring in Office too) but the team was also in a constant state of having no idea what would get done and when. This lack of clarity extended to cross-team collaboration where headcount gymnastics were still not enough to make good on commitments.

It was even a bit more insidious than I just described. As I began talking to teams about what they were planning on releasing, it was almost as though at every step I was running into a manager explaining that they had open heads. I would ask then if the feature was in the plan or not, and they would always say yes. I would follow up, asking when it would be done. The answer was that it depended on when they could hire someone. Yet if someone left the team (in general, Microsoft teams at this time were attriting at 6-8% per year, more so during Longhorn as per the articles in the last section) then the next hires were simply replacements for who had left.

None of this reality slowed teams down from working in a constant state of signing up to do more, requesting and being granted more headcount, and furthering the gap between what was sitting on slide decks as the plan from a team and what code was going to be written and delivered (and when). Meetings with executives (aka me) were viewed through a lens of expansive slide decks and accompanying headcount requests.

The culture of headcount, as I called it, led to a world where people were seemingly rewarded for thinking up big ideas and making the case for more headcount to implement those ideas. It seems entrepreneurial—making a case for an idea and getting resources to build it. Everyone can make a case for resources to get something done, but the question quickly becomes what will actually get done. The process of circling back to those original proposals and checking in didn’t really exist, other than meetings where projects went from expressing goals to expressing “non-goals” or what was no longer in scope. My inbox was filled with these decks offering to get me up to speed, or maybe to approve more headcount.

The flipside of the culture of headcount is just how much bloat it causes. People do get hired on to these teams and the teams eventually grow though never as much as the open headcount (also more headcount keeps getting added as the team expands the charter to do more, at least on paper). The problem is that as soon as people show up they are invariably added to the efforts that have already fallen behind and not scaled back. This is a big part of how the original Outlook and NetDocs projects got to be so large, both of which reached a point where in order to ship headcount was frozen and plans shifted quite a bit. In Systems, this explained the growth of the Cairo project which was ultimately cancelled.

The fiscal tracking systems in place only exacerbated the challenges this process created. The finance team trying to budget expenses gave up accounting by heads and simply tried to use actual dollars being spent on payroll and then literally guessed how many dollars might be spent the next year. In other words, rather than asking executives how many people were on the team, finance maintained a dollar-based Excel model of expenses that had little correlation to all those cost centers and headcount slots. When I would ask managers about their headcount, they would point me to finance who would then tell me a dollar figure for the team’s expenses.

I did not intend to discuss headcount so deeply, but as I was listening to people tell me what was top of mind it literally drove me bonkers. All I wanted to do was make a list of what was planned and who was working on it, but all I could get back were big plans and open headcount. As it would turn out, this was one of the most visible signs that things could be improved and since I knew what to do it gave me a bit of hope when I needed it the most.

This might seem like the talk of a headcount tracking maniac. I am not. In fact, I spent almost no time on this topic until I moved to Windows. As the next sections will describe, we had a massive amount of remedial work to do on headcount management. I won’t skip to the end, but a bit of foreshadowing is that we will ultimately get more done, ship on time, and with vastly more clarity by spending hundreds of millions of dollars less (in direct costs) and completely removing the whole concept of budgets and headcount gymnastics from the team. It was a huge headache and had we failed to deliver good products then the effort would have been used as a causal factor for failure, but it positioned us enormously well for the financial crisis that would seemingly appear out of nowhere halfway through our first product cycle as a team.

The easy access to the headtrax system gave everyone a ready benchmark for how other groups were perceived as growing faster and bigger. In times of rapid growth, it was easy to find people who thought “Micro-dollars” were to be freely “invested.” Not in the back of my mind, but front and center, were my mentor Jeff Harbers’ words about spending and treating Microsoft money as the shareholders.

That’s the rant as to why the key lesson learned for me was that if you want to know what an organization is doing, then just count where the developers are and what they are working on. It really is that simple. Every financial control follows from the number of people actually working on the team. People love to say that building comes from small teams and of course there is truth to that. Building at scale, however, requires sizeable teams. The way to make a big team seem small-ish is to keep the teams focused on building and making the tradeoffs inherent in building and not on budget and headcount gymnastics.

In many ways, in a large company with many talented people and key product people in key roles, the unique and critical role of executive management is to decide and manage headcount so no one else ever even thinks about it and to drive the reallocations to get new things done, or adding headcount to be filled without the expectation or requirement to deliver in the current project. The only way to do that is by knowing what the headcount is actually building all the time.

Returning to the inventory of projects in the WWL organization, I counted 74 projects, each with about 13 developers on average for a total of 947 developers.  There were only about 780 testers which was far short of what Windows software generally required. Some of this shortcoming could be explained by Search, which was using more developer operations owing to the modern web architecture, but even Windows which I would argue needed more testers appeared short-staffed. There were 440 program managers which was shy of the 2 developers for 1 PM ratio I might have expected. There were, however, over 40 people managing the small teams of a dozen developers and most of those managers were serving as the lead program manager as well. I realize I am already falling into the trap of using Office as a baseline, but absent that there was no baseline, no plan or strategy, from which to work.

The key lesson learned for me was that if you want to know what an organization is doing then just count where the developers are and what they are working on. The largest project teams, over 25 developers, in this whole organization were (in order): Search, Print server/drivers, audio/video platform, audio/video codecs, modern interface (pen, ink, etc.), and media rights management. While there is never a perfect correlation between number of engineers and strategy, it was abundantly clear either the resource allocation was off or at the very least was not aligned with strategy. Looking to Windows for some examples, there were only 13 developers on DirectX the core graphics engine for Vista and there were only 25 developers on the rendering engine for Internet Explorer and they were primarily fixing security and compatibility bugs until the recent emergency plan to produce IE 7.0 for Vista. That came about because there was whole new, non-HTML, browser as part of Avalon which is no longer in the Vista plan. Avalon, which would later be known as WPF for Windows Presentation Foundation was a cornerstone of the Longhorn plan had a total of 46 developers. While the specifics of what code was where might not have been totally clear (and certainly isn’t today as I write this) the team was staffed inconsistently with respect to what seemed important.

Windows Live was organized as series of what seemed to be small projects relative to the overall scale. On the one hand, it might be easy to look at the allocation and think about each one as a cool startup inside a big company competing with a startup from Silicon Valley in a similar space. With that view, the teams were staffed well. Except Microsoft was not able to release things in a small way and grow them like a startup. Everything needed to work worldwide, include adequate accessibility, work across browsers (not just Firefox), and scale to all the users seeing the service on Microsoft.com one of the busiest sites on the internet. Microsoft’s online services were spread across 30 or so projects each with less than 10 developers, at least for the front ends (the backends were still in a separate organization).

The difference in org structure and composition relative to Office had already begun to clarify some of the questions I was receiving.

While those differences were stark to me, I quickly realized the obvious. Comparing what I was seeing in WWL to Office was not a merely non-starter, it was insulting my new team. No one in Windows wanted to hear anything relative to Office. Windows was not just different. It was vastly more complex as I was repeatedly told. It was also more difficult. For more than a decade I was used to being reminded directly (or more subtly) that Windows was technically deeper than Office, but now I was hearing that Windows was also a more complex management challenge. I wasn’t convinced but I was in active learning mode.

I had no other baseline. I knew Office. I knew development tools. I worked across the company for BillG. I’d studied tons of other companies As much as I knew I was biased in my thinking of Office, I also knew…it was just software. It could not be that different, I thought. I did not really believe Windows was either more technically challenging or more difficult to manage, but I had to resist the temptation to debate those points. 

There were bigger issues. As much as I was focused on addressing Windows challenges, I realized the pain and anguish the Vista product cycle had brought to the broad employee base.

To many product group employees, the stock price slump reflected the product execution, and Vista was taking the brunt of that blame. The challenges were much broader and deeper, however, and it would take time for employees and other executives to gain an appreciation for the difficulties the company was facing in products. There’s a tendency to view morale and employee issues (or broadly culture) as distinct from company execution and performance, but at least at this moment one thing was clear. The negative employee experiences were happening at the same time as customers were experiencing product issues and strategically the company seemed to be falling behind. It did not seem to me that one could fix the culture unless we built better products, executed more effectively, and transformed the business to be more competitive.

A favorite internal conversation for me was on a Tren Griffin (TGriffin) email discussion group, called LITEBULB. TGriffin was a former technology investor, Seattle-area native, and early friends with the Gates family. He was one of the strongest strategic thinkers at Microsoft. Long a student (and author of books) of investing, Tren frequently posted news stories or questions about competitive markets, Microsoft’s approaches, or other industry dynamics, and generated a rich discussion among a core group of contributors and a larger set of observers. Often the best discussions about Mini’s posts or other press articles about Microsoft could be found on the LITEBULB distribution list, or his external blog 25iq. (Above is an example of a thread from LITEBULB.)

After a couple of weeks of listening across these many forums, I started to gain a full picture of what was going on. It was deeply emotional for me—a mixture of opportunity, as I said in many team meetings, “to work on the other greatest business in the history of business” (a not-so-subtle reference to Office I could not resist), and deep angst, which I also shared in many meetings. “So much of what I’m hearing are things I’ve seen, heard, even experienced over the past 15 years but from afar . . . and now these are my problems, and by that, I mean our problems to solve together,” I would say.

I had moments of sheer terror. For a while, I tended to avoid people outside of the Windows team, especially my dear friends in Office, because they all wanted to know, “Are things really that bad?” I simply could not afford to be candid. Even going to yoga class or out to dinner resulted in sightings I wanted to avoid. Seattle was a one-company town back then.

Fifteen years earlier when Mike Maples (MikeMap) shared his description of two gardens, the Windows and Office gardens, I understood it intellectually from the experiences I had. Now I was experiencing the difference emotionally. Even to this day, I struggle to articulate just how different the cultures were, while both still achieved spectacular success. Somehow this came about all under one roof in a remarkable case of divergent evolution.

While I definitely experienced lonely moments leading Office, I was never as lonely as I was in the first six months of working on Windows.

I had to write to think. But I was not ready to write in public.

On to 085. The Memo (Part 1)

Welcome to Chapter XII, where Hardcore Software turns from Office and enterprise customers to Windows and consumers (and PC makers). For many readers, this will also be a bit more of their own lived experience. As such it is worth a reminder that I am sharing my experience and observations, not any sort of omniscient history (if such a thing even existed). Importantly, by waiting a decade to write, the history becomes much clearer and less influenced by the emotions or immediate reactions. That’s certainly been my experience so far in writing HCSW. These next four chapters (about 25 sections) will cover Windows 7 and Windows 8, with a decidedly different approach than the previous 11 chapters. We will see much more focus on organization, strategy, culture, real competition and disruption, and the challenges and opportunities seen in a big giant company.

Back to 082. Defying Conventional Wisdom to Finish Office

2006: The year was marked by cultural shifts. BillG announced he would step down as chief software architect, a transition that would take two years. I was given a new role and faced multiple corporate and culture challenges, and outside of Microsoft the tech landscape was changing too. And fast. “To google” was added to the dictionary.

By the start of March 2006 the Longhorn product cycle had been a chaotic five-plus years that included the security work for Windows XP, the release of Windows Tablet PC, Windows Media Center, Windows 64-bit, Server releases, and importantly, a major project change called the Longhorn Reset, essentially defining a new scaled-back product mid-flight based on the original Longhorn. The Windows team had been through a lot and was not finished. Longhorn had been receiving a lukewarm reception from users of a big Community Technology Preview release since the fall of 2005. The team, however, had started updating the product more frequently and momentum was indeed shifting by early 2006.

Windows Vista, as it was officially named, was still an unpredictable amount of time away from shipping. While not public at the time, a couple of weeks down the road, Microsoft would announce a final and just-decided delay to ship Vista for availability in January 2007. The team could not commit to making the release available in time for PCs to be sold for back-to-school or holidays 2006. Vista would eventually release to manufacturing in November.

Windows was still on fire with PC sales breaking through 200 million units in a single year for the first time, demonstrating extreme product-market fit. Both Servers and Tools were doing well, extremely well, except there was a nagging problem emerging from across Lake Washington called AWS, Amazon Web Services, a shift from companies buying Windows to run on their own server computers to renting storage and compute in the (or a) cloud. There was a good deal of tension between Windows team and the Server team. The Server org required the Windows org to contribute to shipping a new Server. This delayed a new Server product, slowing their release based on Longhorn until the next Windows release. The .NET framework and Visual Studio had become leaders for IT development within corporations, but the onslaught of Linux, Apache, MySQL, and PHP (later Perl/Python) continued to dominate the public internet and the university programs in computer science.

On the RedWest campus the investments in online services faced a myriad of revenue, cost, product, and usage problems that were not nearly as visible as the Windows challenges. Wall Street, however, was growing increasingly impatient with financial results, which seemed to punish SteveB for his transparency. There were dozens of Microsoft online services, some branded as MSN and others using a new umbrella name Windows Live, in every conceivable category from selling cars (MSN CarPoint) to chat (MSN Messenger) to finding Wi-Fi hotspots (MSN Wi-Fi Hotspots.) Microsoft seemed to be searching for a big win against Yahoo and a rapidly dominant Google in the world of internet advertising and consumer services.

Google was top of mind for many, not because so many groups across Microsoft competed with Google products but because of the aura the 2006 Google culture achieved. Google was fast. They were innovative. They were empowering. They had “20 percent time” when engineers could work on whatever they wanted one day a week. They had free gourmet food and a chef, all day long, compared to our grungy filtered water dispensers and subsidized airport food with limited availability. They had snacks and we still had noodles and one type of V8®. They had massages, while we had a multi-purpose sports field, but no towels (note, towels returned in the summer 2006.) We had individual offices and they had collaborative open plan cubicles (you read that correctly, Microsofties complained about having offices.) They had a modern, flat organization with 50 reports to a manager (yes you read that right too.) In the blink of an eye to me, everything we held near and dear and made Microsoft an icon of business culture, seemed to be old, tired, and either wrong or inadequate, like wearing khakis, loafers, and a button down to Burning Man.

Google Chrome was still almost three years from launching while Internet Explorer had 90% share. The last new release, however, was Internet Explorer 6.0 launched five years ago with Windows XP frustrating users, web developers, and the market. Gmail was about to turn two and it was crushing Microsoft Hotmail with its superior junk mail filter and massive free storage. Microsoft just started to build its own web search product which would launch in 2006 as Windows Live Search into a market where Google had already overtaken Yahoo and grown to half the market while gaining a half point of share every month.

As Vista was creeping along, albeit faster these days, toward shipping, there was a much deeper problem in Windows that was symptomatic of the broader malaise or even open hostility across the company, especially in engineering. Even though the company kept putting up blockbuster numbers, the morale across product groups had declined. Vista had contributed to that. Integrated Innovation had as well. Integrated Innovation was the expression at the CEO level of the desire and right to build integrated software, which continued to be challenged in the courts and among regulators. Internally, this was the opposite of what people wanted to hear because the feeling was Integrated Innovation, or synergy, was what had first gummed up Microsoft relative to Google. The yearly Microsoft Poll survey was a litany of complaints and issues from employees across most of the product groups.

In a semantic twist, the phrase was later morphed into Innovate then Integrate. That might not have helped. In reality the pressure for synergy had not relaxed at all as it was a cornerstone of Microsoft’s (and BillG’s) strategy and culture, even more so as the company became an enterprise company given how much enterprise customers and the enterprise ecosystem valued synergistic strategy, or maybe strategic synergy. Strategy was the anchor holding back Longhorn. A scathing cover story in the September 26, 2005, BusinessWeek, “Troubling Exits at Microsoft” painted a picture of employees departing, malaise, and the rise of Google. Even a longtime member of Microsoft Research’s Technical Advisory Board, Carnegie Mellon professor Raj Reddy, called for a company breakup to support more “nimble operations.”

But the biggest problem was that we felt like we were losing, and Wall Street felt that way too and the stock price reflected that lack of enthusiasm.

We were losing to Google. We were losing to Yahoo. We were losing to BlackBerry and Nokia. We were losing to Sony. We were losing to Oracle. We were losing to SAP. We didn’t have anything to compete with AWS. We were losing to Apple when it came to PC hardware. We had already lost to Apple’s iPod.

In the years ahead, we will see accelerating change in the software industry, as the computing needs of our customers start to move beyond the PC into a “PC-Plus” world.  The PC will undoubtedly remain at the heart of computing at home, work, and school, but it will be joined by numerous new intelligent devices and appliances, from handheld computers and auto PCs to Internet-enabled cellular phones.  More software will be delivered over the Internet, and the boundary between online services and software products will blur.  The Internet will continue to change everything by offering a level of connectivity that was unimaginable only a few years ago — and every home, business, and school will want to be hooked up to that incredible global database. —Annual Report, 1999

Our competition with Apple was becoming increasingly sharp compared to past years where our view was essentially to ignore them, going way back to the launch of Windows 95 and the “C:\ONGRTLNS.W95” full page advertisement in The Wall Street Journal. In 1999, BillG wrote an oped for Newsweek and a month later proclaimed in the 1999 Annual Report to Shareholders that the “PC-Plus” era was upon us. With this Bill was describing an era where PCs would continue to be central, but rather than part of every scenario they would be surrounded by devices that connect to a Windows PC.

This framing of the future became more visible and widely used across Microsoft communications as the temperature of the competition from all corners heated up.

The PC-Plus era is rooted in a response to what had been simmering among the tech press from as early as 1993 when Walt Mossberg first used the phrase “Post PC.” The first wave of connected devices began with the EO Communicator in early 1993 and then the Apple Newton available a bit later. In his review of the EO, Mossberg described the device as not “the kind of post-PC device that promoters of the PDA concept have promised: something with the price, size and battery life of a Sharp Wizard, but the smarts and communications ability of a good PC and an advanced phone.” Whereas in the review of the Newton he described it as “a post-PC device that streamlines data entry, links all of your information in intelligent ways and adapts to your handwriting and work habits over time.”

A few years later with the 1999 arrival of the Palm VII, the first truly connected and mobile-phone sized device, the punditry was running full throttle declaring the arrival of the Post PC era. The trade press was filled with editorial and widespread usage of the term, much to our dismay at Microsoft.

Bill Gates, Paul Otellini, and others in the PC industry went on a bit of a campaign defending the PC and declaring the PC-Plus era. They executed a series of OpEd pieces and other marketing efforts to thwart the notion that the PC was dead. In The Wall Street Journal in May 2006, just after I started working on Windows, they wrote an OpEd explaining why and how the PC will continue to thrive.

So, the next time you read about the end of the PC era, think about what you do when you get home from vacation and want to share the pictures on your digital camera with family and friends. Or where you go to download music and videos onto your iPod or MP3 player. Or how you synchronize the contacts, calendars and email on your handheld wireless devices. Or where you go when you want to find new music or search for that episode of "Lost" you missed last week.

You sit down at your PC, of course.

As this shows, the defensiveness around the PC became increasingly obvious and the technical justifications increasingly detached from where the industry was heading.

There was no shortage of problems on the Windows front, in contrast to Office which seemed on both solid footing and heading calmly to a new era. Despite the chaos, upheaval, corporate strife, and my own apprehension, I was about to run towards the fire.

Office Hours

I was sitting in the guest chair in SteveB’s office while he was standing, swinging his golf club. He stopped, finally, and said, “Thank you. Thank you.”

With great enthusiasm, those were his words as he shook my hand with all the vigor of a salesman closing a deal. A handshake between product group Microsofties was so unconventional that it added to my uneasy feeling.

Uncertain as I was, I accepted the role of leading Windows product development.

But it would not be so simple. That also meant managing the struggling Hotmail, the new Live Search, and the loved and popular, though shrinking MSN Messenger, along with several other online services. I would report to Kevin Johnson (KevinJo), who had joined Microsoft from IBM in the early 1990s and risen up the ranks by building out the company’s customer support arm and then to running the worldwide field organization (after Microsoft he went on to become the CEO of Juniper Networks and then Starbucks). Kevin would provide much needed stability across his enormous portfolio, which included all of Windows and Server, Tools, Servers, and online services. The big news was that Kevin was taking on a new and huge product development role, essentially everything except Office. The way I thought about Kevin’s job was he was on the hook to lead competing with Apple, Linux, Google, Yahoo, now Amazon, and the rest of the internet. The key thing for me was that one person oversaw every major customer segment at the company: consumers, PC makers (Microsoft’s largest source of revenue concentrated in about ten customers), developers (developers, developers), small business, enterprise IT, and now advertisers. It was kind of nuts for one person to be asked to manage all of that I thought. My job was to help him by making sure Windows was taken care of.

The Windows team had been divided into two big teams for quite some time. The core operating system was known as Core OS Division, COSD (pronounced “kahz-dee”). COSD led the parade at creating Windows, drove the engineering process and culture, and was staffed with first among equals. COSD owned the operating system kernel, device drivers, file system, networking, security, and in general the guts of Windows. The team was where the original Windows NT architects all worked. When Jim Allchin (JimAll) created the COSD organization he and I spoke about how we built the Office team (the original Office Product Unit a decade earlier) and COSD was somewhat mirrored after that, at least they thought so. About half the Windows resources were in COSD.

The other half of Windows was known as Windows Client and embodied the user side of Windows including the graphical interface, the explorer, start menu, control panel, printing, faxing, and all the experiences from tablets to media playback, to Windows Media Center, and importantly Internet Explorer. What COSD was to process and hardcore, Client was to “doing cool stuff.” A visit over to one of the Client buildings and you were likely to see displays of cool new media players, fancy gaming PCs, or the latest in wireless gadgets. There was always a cool demo to be had. Showing off COSD innovation was a lot more tricky.

There always seemed to be tension between COSD and Client. Whether it was about the schedule, testing, or different views of the engineering process. There was not a lot of love lost between them. This might seem weird to many. To outsiders, I am positive the early days of the Office Product Unit tension with Excel and Word would look identical.

For clarity, the Windows Server product worked closely with COSD but owned the product definition and the unique components differentiating Server from regular desktop Windows. Yes, it was a complex matrix.

Technically I was to manage Client. COSD was driving the Longhorn project even though Client was 100% engaged on that. No need to upset anyone with a new boss anyway. We would figure out the details of COSD at some future date closer to when Longhorn would ship. I also took on half of the Windows Live Services, which were also divided into two orgs as well (front end and back end.)

If this sounds a bit halfway, that would be a valid observation. It was certainly confusing to outsiders searching for the new boss of Windows, which JimAll was previously. In total fairness, very large reorgs are never finished before they start to roll out. There is always a balance between completeness and fighting the inevitable leaks that prove even more distracting. The press release from Microsoft tried to detail the organization but from the outset it was complex.

Was I up to this job? Was the team up to me in this job? Could a person with experience only in “boxed” software work in the modern world of online services? An Office guy running (half of) Windows? That seemed like a punchline to a bad reorg joke.

And what did we need to accomplish? Tackling the challenges faced by Windows seemed, well, perhaps too late to the party. They still hadn’t finished Vista after the Longhorn reset and it wasn’t clear when it would ship. Did I have to ship Vista first? What if Vista turned out fine and customers were happy? Or did Windows need to be reinvented? Brought back to life? Or both? And, if so, what level of urgency was even possible? What did the individuals on the team think were the problems?

I had never hemmed and hawed about a job change or negotiated any titles, terms, or conditions, and I didn’t for this one—just two weeks going back and forth, mostly with BillG to get a sense for his candid thoughts. My new role marked his last staffing efforts with SteveB—the last “Bill person” to move into the Windows job. Though I was not ever going to be a “Steve person” because of my lack of field experience, we both worked equally hard to see each other’s perspectives.

All the best choices I had ever made in life were counter to my exceedingly planful product execution, without strategizing, lists of pros and cons, or excessive deliberation. I just went for it. I was lucky in that regard having not really made a poor choice, yet.

But I was tired. I had been going nonstop since graduating 1987 and had, for all practical purposes, given my 20s and 30s to Microsoft. Was I about to turn over my 40s?

This opportunity was sure to be all consuming.

A management transition for Windows was a material corporate governance event, and thus a formal announcement needed to happen quickly to avoid the potential of leaks to Wall Street. Plus, there were many anxious people across the company who had both a need to know what was going on with Windows, and a need to influence what was going on (or believed those to be the case).

“Quickly” turned out to be an understatement.

The Vista team sent out a team-wide mail as well as communication to partners with an absolute RTM date of October 25, 2006, a slip from the previous August target. This was essentially external communication and would generate press. However, word already leaked to The Wall Street Journal about me moving over to Windows. The PR team began negotiating by trading verification of facts in an effort to delay the story. The story was going to run on March 22, 2006.

The clock was ticking to actually get an announcement done. The announcement scheduled for the morning of Thursday the 24th would not be moved even with the WSJ story.

Within minutes of accepting the job, I was informed that my first meeting was to be held immediately to go over the announcement tick-tock, an expression I had not seen used before inside Microsoft. I was also asked for my internal comms contact, my external comms contact, my human resources contact, my executive assistant, and my chief of staff. Time was short. There were almost 40 people on a mail thread summarizing the process.

I had no staff, so I replied, “Just ask me.” I suspect everyone on the mail thread had no idea what to do with my response, but it sure cut down on the email traffic as there was a bit of a culture of fear in Windows when it came to sending mail to an executive, especially a new boss and one they had not worked with.

I forwarded the mail to our executive assistant leader Collen Johnson (CollJ) and then immediately walked into her office. I shook my head as if to ask, “What did we get ourselves into?” I knew Colleen was already buffering a huge amount of noise, mostly people asking if I really meant for them to ask me directly.

I arrived at a conference room in building 34, the big executive building, to a room of what appeared to be a re-org war room. There were easily 30 people, standing room only, more people than I think I’d seen in a meeting since we signed off on Office 2003, all to plan the announcement of my new role. The big conference table was covered with handouts of org charts, talking points, and draft press releases and rude Q&A docs. I didn’t know most of the attendees. It was funny because this was not a restructuring or anything complex; it was news of a retiring executive JimAll, a new executive boss, Kevin Johnson, and then me. It seemed that every vice president involved in this announcement sent two or three people to the meeting but didn’t show up themselves. Questions quickly started mounting over messaging, email cascades, and heads up. The production values well exceeded the actual announcement being planned.

As much as I understood the importance of this announcement to the business world and to the team—after all, this was the retirement of legendary technologist and leader Jim Allchin and a material event for a public company—the craziness (and that’s what this was) around a single announcement represented a microcosm of the entire situation. I was no longer in the comfortable garden MikeMap had created for Office.

With a lot of effort, the room managed to get the information that everyone wanted to go into this announcement down into a single email response to the official press release and filing, which I wrote, which came from me, and had one small set of talking points for any press calls that PR would handle. There was to be no email cascade—a new word for me that meant a process where an email went out from the top to the organization, and then every level of management forwarded that email (that people had already received) to the team(s) they managed with their own words interpreting the org change for them. Since there were parts of the Windows team that were nine or even 10 levels deep, the amount of interpretation that went into these cascades was mind-boggling in the depth and breadth of potential misinterpretation.

Turns out, we needed none of that with this announcement. Why? There would be no outreach or interviews by anyone at this stage. Most of all, literally nothing would change until Vista shipped.

That was the only talking point that mattered.

I was not joining Windows with some sort of secret master plan nor did we want the announcement of my job to portray me as some sort of Vista savior. Still, it played out a little bit like that in the press. There was an uncomfortable 36 hours between that WSJ story and the official announcement. That’s what happens when things leak.

The Wall Street Journal said, “[Sinofsky] has a reputation as a meticulous manager who is adept at controlling large software projects.” Paying homage to MikeMap, the article said the Office team culture was created by “an executive recruited from International Business Machines Corp., the Office group adopted a more management-heavy, disciplined culture . . .” The headline read, “Microsoft delays Windows Vista debut again; consumer version to miss critical holiday season; unit shake-up is expected.”

The rest of the week saw much of the press derived from the WSJ and the announcement focused on my new role in fixing Windows. There was no way to avoid this. It was broken. I guess it was also the truth. Business 2.0 ran with a headline “The Man Who Could Fix Windows: Microsoft's new OS chief has to get Redmond to embrace a new model of programming, in which software is constantly being improved instead of updated every 5 years.”

Inside the tech industry, one of my longtime favorite foils in the press, Mary Jo Foley of ZDNet, said, “Sinofsky has the reputation of a strict, schedule-bound manager who keeps the trains running on time.” After all these years, and quite a bit of product innovation from the team, I was basically a strict project taskmaster. That stung, in a Spock-like way. But later the ZDNet editorial team added more, “The Sinofsky promotion (not sure we’d consider being named Windows Mr. Fix-It constitutes an upward career move) grabbed the most headlines.”

And finally, everyone’s favorite anonymous internet whistleblower, Mini-Microsoft, a widely read blog maintained by anonymous author calling themself Who da’Punk offered thoughts. To clarify the record once and for all, I was not the writer and have no idea who was though at least two reporters met the blogger in person verifying that fact. The post on March 23 had a headline that read:

“Sinofsky to the Rescue!. . . (?)”

The article said, “There’s a new sheriff in town, and he’s aimin’ to gun down any rootin’, tootin’ varmi[n]t that can’t deliver what he committed to. Maybe.”

It is probably important to detail Mini-Microsoft at this time because they were a fixture over everything that was going on at Microsoft, even if I chose to ignore them the rest of the Windows team and the company followed every word (and so did the press). Mini, as in “Did you see the latest Mini?” or “Well, that really pissed off Mini” wrote about all topics Microsoft though seemed especially focused on the plight of typical employees struggling to make sense of what was going on. Mini was especially critical of typical big company problems such as organizational bloat, excess hiring, lack of innovation, performance reviews, promotions, salary, and more. Mini was also critical of our technical strategy and challenges around Longhorn. Like many claiming informal whistleblower status, the challenge was always there for an executive to respond to critiques, but it was so difficult to do so knowing Mini did not always have the complete context.

It is difficult to parse today but when reading Mini’s posts one of the most interesting aspects is how they turn the phrases of Microsoft’s HR and leadership back on them. From accountability to synergy to integrated innovation and even “I love this company” which was classic SteveB. Beyond that I proved to be a subject, directly or not, over the next couple of years in many of his (eventually their gender was identified in the press) over 100 posts. Mini even got himself a profile in BusinessWeek, as part of the much larger negative story about the loss of talent at the company.

Share this post with a friend who remembers Mini :-)

I had no real direct reports at this point because everyone, including BillG, was finishing Vista. Still, I needed a way to quickly connect with a large number of people in a way that felt more . . . intimate.

To move forward, I chose a decidedly non-traditional path. The Microsoft way might have been a big all-hands meeting, a follow-up email with vague statements of support, or an immediate gathering of a staff meeting. Instead, given the need to both ship Vista and meet a lot of people I looked for a way to communicate broadly while connecting in-person with many, all while not getting in the way at all of Vista. This meant, for example, turning down all the escalations or crisis moments that people would bring to me. For example, in July AMD announced the intent to acquire ATI, the graphics card makers, which caused a brief panic in how to handle shipping ATI drivers in Vista. Given the future impact of this choice many tried to pull me into this crisis. This was a brilliant acquisition and noteworthy that Intel did not lead or follow up with acquiring then similarly-sized Nvidia.

I browsed over to the internal SharePoint site and created a new blog called Office Hours in an effort to signify openness and a risk-free place where ideas could be shared. Blogging the goings-on proved to be the best way to reach a team of approximately 10,000 people and, as I would learn, the rest of the company.

Over the course of six-and-a-half years, I wrote more than 400 posts amounting to nearly three quarters of a million words (1,700 pages), answering questions, discussing the how and why of all we were doing, not doing, or considering, and detailing almost every aspect of the business. I wrote something substantial most every week, sometimes twice. Posts covered product strategy, organization structures, people management, competition, features, culture, my personal management, and just about everything in between. I posted the trip reports I dutifully wrote after conferences, recruiting trips, and customer visits. Many of these posts were included in a book I co-authored with Marco Iansiti of Harvard Business School, One Strategy: Organization, Planning, and Decision Making (Wiley, 2009.)

I had one last meeting with the Office team. We gathered the Senior Managers, the most senior 120 or so people (the dev/test/pm triads as well as general management and discipline leaders across design, planning, localization, content, operations), in the big conference room where I shared the news that was about to break. Even to this day it was the most emotional day of my years at Microsoft. I looked out over the room and saw people I had all but grown up with professionally, many of whom I’d known for my entire time at Microsoft. Mostly I sensed they were worried about me—the look on their faces said no one goes over to Windows and lives to tell about it.

As I was packing up my office to move across the street to a temporary office in Building 50, a member of the team stopped by and delivered the most wonderful hand-made lightbox of Office logos and packaging over the past dozen years. It still sits on my shelf with the signed note. It means the world.

This was just my first couple of days. Even though for the time-being I had no direct reports, I still needed to figure out who and what would eventually be on my team. The team was incredibly anxious and clearly expected both a master plan and a reorg. I realized that many people had observed or become a fast study in how the Office team worked. Many were prepared with arguments as to why the way Office worked (at least their perception of that) would never work in Windows.

I had a sneaking suspicion that SteveB and BillG wanted a quicker “fix” than I might deliver.  Even though I had not only lived the Windows challenges for at least a decade and many of the people were well-known to me through countless meetings, offsites, email exchanges, and more, the one thing that is certain is that talking about fixing something is a lot easier that actually fixing something.

On to 084. Who’s On the Team, Exactly?

As we conclude the story of Office12 and the major redesign of the product, Microsoft of late 2005 to early 2006 is in a bit of a lull which for better or worse is good for the launch of Office. Longhorn continues to stretch out and the lack of clarity continues, which is putting a drag on everyone. There’s something very special, yet bittersweet, about this release of Office.

With the conclusion of this chapter, Hardcore Software, will start to get into Windows. I have about 30 stories planned. As my roles have changed so too have the stories. With Windows, we will see a lot more detail on organization, change management, strategy, and direct competition. If you are not a subscriber, please consider signing up. Audio will continue to be free and posts with all the graphics, artifacts, PDFs, and videos will be available to subscribers.

Back to 081. First Feedback and a Surprise

Nearly every country’s “Feedback to Corp” slide at the grueling field sales multiweek Mid-Year Reviews (MYRs) in January 2006 published the same bullet point:

🚩 Office “12” – Needs Classic Mode

What was this big, and clearly coordinated push for something called classic mode, and why now? We, of course, knew what it was but we did not know why this was happening now. It was very late in the schedule, post-beta testing. We were just months from scheduled completion as we just went through the final validation of the product—when the team is changing as few things as possible for the last few months, certainly not making any design changes.

A broad public beta went out to most enterprise customers as well as the technical press. More people enrolled in the beta than we expected or could even imagine. There was a great deal of interest in such a bold direction for Office.

As with the technical beta, the reactions came swiftly and clearly, often based on little more than the first few minutes with the product. Reactions from the press arrived in three waves—straightforward news of the release, first looks or reactions based on first experiences, and then, after a week or so, deeper dives into the product.

The first looks wrote themselves as we expected. Office12 was a sweeping change, and the obvious commentary or controversy questioned whether customers or the market were ready for it. Would it work? How difficult would it be to learn? Almost always the point of view of why the change was made was reflected, but the tone was skeptical. That was kind of annoying, but entirely expected.

For example, CNET’s Ina Fried who is always fair and balanced, said, “The radical revamp could help the company as it seeks to stave off competition from OpenOffice and others, but it also risks alienating those who like things the way they are.”

Computer Reseller News, the trade publication focused on small and medium business, went to great lengths to express concern. “While most users will welcome the additional features, Microsoft’s decision to teach its customers a new user interface for accessing commands and functions could be a risky proposition. Once the beta testers (and the bloggers) have registered their opinions, some Office 12 design points could be in for a course correction.”

A more detailed expression of concern came from CNET’s editors. “In the past, Microsoft has sabotaged itself by unrolling too many new features to Office too fast. We’re keeping a lookout for problems; after all, Office 12 was in its storyboard stages just a few months ago. If you’ve spent the past two years mastering Office 2003, prepare for a steep learning curve.”

These articles generated the MYR feedback. The enterprise account managers, essentially all our revenue except for Japan, were on the verge of freaking out. They saw the Ribbon as pure friction in the way of revenue and nothing less. They cited doubts expressed in the articles, reprinted in every language around the world, as evidence of deep concerns over the direction Office was taking. They did not want to spend energy selling Office where the assumption was we’d already won. They wanted to focus on selling the big server strategy, where we were losing to open source Linux and a host of smaller competitors. So why put up a barrier, they asked.

As if to highlight these enterprise customer concerns even more, in the spring of 2005 Office marketing rolled out worldwide a series of advertisements as a follow-on to the “Great Moments” campaign previously described. Attempting to inject humor into the extremely enterprise Office 2003 wave and to encourage customers to digitally enable knowledge workers, marketing developed a new advertising campaign affectionately called “Dinosaurs” though formally called “Evolve.” These ads featured humans in the office but with oversized, cartoonish dinosaur heads, implying those who have not yet embraced a digital workstyle including running Office 2003 were dinosaurs. In other words, we called nearly all our customers dinosaurs. At least the ads were popular in Japan, a market known to appreciate a good mascot, where the company distributed a large quantity of small plastic dinosaur heads.

Very quickly what felt like a magical release suddenly seemed to be worrisome to the sales force. That was not acceptable.

We obviously took on a significant risk in choosing a complete redesign of Office to address our “good enough” challenge. In hindsight sometimes I can hardly believe we did so. Now that we had 18 or more months of time to develop the product, we were genuinely confident.

Our previous attempts at addressing bloatware or the belief the product simply did too much each failed. These approaches were rooted in the conventional wisdom of different stakeholders:

* Reduce User Interface. From the earliest days of the product, the path to simplicity was to minimize the amount of interface visible on the screen. The conventional reaction to bloat was to proclaim less is more, as we often read about in reviews and analyst reports. We did our best to avoid removing features. Instead we twice tried a few design tricks, one was Intelligent Menus and the second was the technique of rafting toolbars.

* Office Lite. The business view looked at price points and wanted to meet good enough with a lower priced offering without upsetting the main revenue stream of course. The way to compete would be to have a stripped down, easy to use, easier to administer, lighter-weight version of Office, that cost less. We solved for this problem by changing the composition of SKUs to create lower price points, rather than chasing the low end as previously described.

* Customization. Customization was always the easy way out. If a customer or IT group didn’t like something in Office, they could just rearrange it. The tech enthusiast users and those early in the beta process said the would be fine with the Ribbon, so long as it enabled full customization by rearranging the tabs or contents of the interface. We addressed this with the customizable Quick Access Toolbar, complete keyboard support, and support for creating custom add-ins.

As we have seen, each conventional approach was fatally flawed and by and large amounted to half-steps to addressing the challenge of bloat or good enough.

Instead, Office12 would take the perceived liabilities of Office—the depth and breadth of features—and turn those into assets. The strategy was to make the product better by not just redesigning but reprogramming the user’s experience for a modern era.

Office12 could easily be viewed as taking the contrarian approach to conventional wisdom and feedback at each step. In early 2000s Microsoft, the idea of not “listening to customers” was decidedly counter-intuitive to put it nicely.

Most of our Office buyers were vocal and visible. Enterprise account managers regularly brought IT managers and executives to Redmond for briefings. Along with a direct line to SteveB, they were never far away, nor were their expressed concerns about products. As previously discussed, the growth areas of the Windows Server business hinged on directly listening to and acting on feedback from IT pro customers.

In the consumer business, Microsoft’s new online services were increasingly enamored with A/B testing and experimentation, substituting data for intuition (much more on that soon).

And here we were in Office being radical. To many it looked like we were either ignoring customers or not using data. We were just working the old way.

The MYR feedback added a new challenge. Customers, especially our prized enterprise customers, would simply demand we not ship the redesign at all. Even if we chose to there should be a way to easily revert to the previous design, at least for administrators.

Whether enterprise customers installed and tested the beta or not, this concern rapidly spread through the world of IT directly to our account managers. Budgets, dollars and headcount were reserved for back-end servers and data centers, for which we offered SharePoint and the full spectrum of Microsoft servers. In this environment, the resources that were allocated to PCs for individual knowledge workers were used almost entirely to keep PCs running, free of viruses and malware, and handle catastrophes such as breakdowns and stolen laptops. The budgets and resources for training materials, helpdesk, and even how-to courses all but vanished from the corporate world.

Given that context, any major change to Office was costly and unbudgeted. Even though customers were paying for years of Office, they had stopped factoring change into their IT budgets. For most in IT, Office was viewed as complete. Office was good enough. At the most extreme, a new version of Office would be fine if it added a few more menu items or commands, but mostly the best release of Office was one with no changes at all, but with better virus protection, reduced system requirements (Office already consumed the least amount of system resources of most anything running, even browsers), and even more administrative controls especially to turn off new features. Whatever lock-down we saw back in 1999 that first time visiting enterprise customers was now an ever-increasing new normal.

According to conventional wisdom among Microsoft followers, Classic Mode (CM) was the answer. CM was not part of Office12 and never was, but almost on cue the early punditry and enterprise teams assumed it would be in the product. The feedback or request was more of a Microsoft reflex. The term originated from Windows, referring to a switch or mode that flipped the new operating system to the look and feel of the old version. Windows had historically taken this to extremes. For example, in Windows 95 it was still entirely possible to run the old Program Manager and File Manager instead of using the new Start Menu and Explorer (in fact, those still run today on the 32-bit versions of Windows 11). Windows also included visual themes that emulated the old graphic design, which made the product look. . . old or comfortable. This provided a comfort for IT managers concerned about training. It was marketed as an option, but it was heavily documented in many deployment and IT-focused publications as an asset or even preferred way to use the product. Technically, CM meant Compatibility Mode in Windows, but it was referred to colloquially as Classic Mode because it referred to the old, and presumably loved version of Windows. These were thin veneers on very easy to use features, but customers were comforted by the gesture.

It was therefore entirely logical that these same IT managers (and the field sales managers) assumed Office12 came with a switch that turned Office12 into the standard or conventional user interface design—Classic Mode. Both Classic and Compatible are interesting word choices in that both imply the new product is less than a classic or not compatible.

The absence of classic mode was a surprise to, well, everyone including BillG and SteveB. While at one point super early on it was something we thought we might do, in hindsight, it was never more than a consideration with a placeholder specification.

Still, I had to be careful not to say that at MYR. I learned long ago not to drop hints or to be vague at MYR. My action item was dutifully recorded and in due time I would get back to the field staff with our plan.

We had so many reasons why CM was not possible let alone desirable. First and foremost, the requests for CM were based on the assumption that existing Office products were as easy to use as our marketing implied. While customers overwhelmingly associated ease of use with Office, in everyday usage, the product was complex, maddening, and fragile. Each day millions around the world had moments of dissatisfaction. The old products were familiar, but no one thought they were easy in any absolute sense. There was room for innovation to save untold hours of grief. No sane person would debate the maddening frustration that came at some point when using Office.

The user interface for a product that does as much as Office goes well beyond aesthetics. The design of Office 2003 was functional, and as a design the product was failing customers. Many people were squeaking by as long as they used the small set of capabilities they previously learned. And the tiny percentage of people who mastered the product would not credit design for their success, but rather their fortitude and investment in learning the product. A product designed for a single profession, like Adobe Photoshop or Autodesk AutoCAD, could remain mysterious to outside users because those in need learned it as part of their professional training. Office needed to be different. It was a tool used by hundreds of millions of people who learned with little to no formal training.

The goal of Office12 was to be more human and less computer. The design language for the PC era’s first two decades was primarily about utility and consistency—as in, making everything just function. We were at a point in time where we wanted to make the products work for people and to do so with a new sense of mastery and ease.

In early 2005, JensenH wrote The Office User Interface System, a document detailing the rationale and design for Office12. This document covered the motivations, problems being addressed, and the detailed philosophy behind each of the elements of the design. Even to this day, it amazes me that we had this document a year before release, and it still stands as an incredible accomplishment by the UEX team.

There was no looking back. CM was about looking back. As a practical matter, there were three major technical hurdles to classic mode.

First, there was literally no room left in the product. One could easily project out the future of Office as having hundreds of toolbars and task panes. Office would literally collapse in on itself into a giant black hole of buttons with little room left for content. The screenshots meant as jokes ten years ago were looking more like predictions or designs. Any new feature was like parking at the mall the day after Thanksgiving. Except instead of circling the parking lot in a car, program managers would be circling the hallways in search of an empty spot on a toolbar.

Second, and less obvious, was that the Ribbon design fostered a new and more modern interaction between user and features—live previews, extended text descriptions, galleries, contextual user interface, and high-level grouping of commands. New capabilities in Office were designed knowing they could be offered to users in this more modern experience. There was nowhere to do that in the old interface. That meant we would either not have those features or we would need to develop yet another mechanism to provide those new features in an old way, somehow.

Third, and most critically, everything we knew about customer behavior said that once a customer turned on CM, they would never turn it off. They would expect CM not just for Office12 but for every release after that. When one considers that Office is supposed to be compatible release over release, then it is obvious CM becomes part of a permanent compatibility story. CM would introduce a fork in the Office product where everything is done twice, once the new way and once the compatible way. An easy solution to this was to simply run the old release of Office forever. Microsoft had a way to make this possible as well.

The debate over CM, in my view, trivialized the design of the product. While I was of course extremely empathetic with the change that would be forced (as some would say) on to customers, I could not help but think back to the early days of the project. At the start we talked about all the places in life and technology that change. People are frustrated for a time then recover and move on. We were going through one of the greatest changes in the history of the world with the internet. Every internet site was constantly changing. Why did Office have to be static? Static equals dying.

Why were people so nervous about this change? I was puzzled for a while. Then I realized, almost no one in power positions in the industry had lived through a major change to Office. Since about 1990, or almost 15 years earlier, Office was unchanged. Office was a constant. It was as if no one ever expected Office to change. Almost no one recalled the early MS-DOS applications or the pre-Windows era. Most of our own development team only knew Windows or Macintosh. Out of almost 2,400 people on the Office product development team, only 58 of them even worked at Microsoft before Windows 3.1 shipped and only 7 were at Microsoft before Mac Excel shipped. Over 80% of the team joined since Windows 95 shipped. Even our own team never really lived through the graphical interface transition or the 8-bit to 16-bit transition, except while they were in grade school. Most were hired from college and the majority had much of their early computing experience on Macintosh. Our new hires during Office12 were the first generation of web-natives, having had the modern internet since high school.

JulieLar had a strong point of view on dealing with this, as someone who did live through the graphical transition as an early Macintosh app developer on PageMaker. She often noted, “When you believe in a design, go for it.” Some might interpret this as no compromise, but principled was a more appropriate way to put it. In many ways it was a new-to-Microsoft approach. The general manner Microsoft (and Office) approached change was to always support the old way, either with an option or to move on to a completely new product that solved the same problem differently, leaving the old product on the market. If you ever wondered why Microsoft had so many data access APIs or UI widgets or any other of a multiplicity of solutions for one problem, it is this latter approach. It is vastly easier to start from scratch than to reengineer something in place. The only problem is starting from scratch and creating a new product/technology rarely brought forward the myriad of tiny subtle details that existed in the original implementation. Complex products resulted from this approach. The products were either complex because everything had an option or alternate way to use it, or complex because multiple products claimed to solve the same problem but in non-overlapping ways. Teams often took the path easiest for their code base, defaulting to whatever had the least friction to adding new features.

It is worth noting how valuable customers found a high level, or perhaps perfect, level of compatibility. Today we joke about running Excel 2.2 on 32-bit Windows 10, but it does so 35 years later! Even early 1980s character mode MS-DOS applications continued to run through new Windows releases as late as 2010. This is decidedly different from compatibility at a user interface level. Whether one uses old Excel or old Multiplan, doing so doesn’t impact using Office 2003 or Adobe Photoshop as the compatibility is just bolted on the side. In the case of Office, the old features were intermixed with the new and that was an entirely different level of complexity, an unachievable level of complexity.

Because of this history, JulieLar and I wound up on the front lines, so to speak, engaging with hardcore fans over compatibility mode from the early days of beta testing. In the private MVP newsgroups, I once wrote a very long essay, almost, about why change is OK reinforcing the history and context of our industry, including that most customers had simply never seen any material change in Office (or Windows). I might not have convinced anyone at the time, but I did start to formulate the kind of arguments that would come in handy later in my journey. Quoting from the newsgroup post verbatim:

To believe that at any given time some technology is the the ultimate in productivity and nothing should change is of course absurd. While many people have a massive investment in analog recording of video and audio, few would argue that the change in technology is worth it if you want to stay a leader in the field. Photography magazines are filled with "move to digital discussions". There will always be a few people who remain convinced that the technology they invested in is the be all and end all of the field and that moving to a new technology is not perceived as being better, and in fact is worse. As with any technology shift, it is *never* 100% better -- digital audio does not sound as good to some people, digital photos are not as rich in quality or resolution as film, digital video looks different than film, etc. But new technologies have benefits that were not possible or not thought of at the time. So it is with the new user interface.

The idea that CM was a short-term fix crystalized our collective point of view for how wrong-headed such a capability was. If we learned one thing over the previous few years of Enterprise Agreements, it was that if customers were offered a way to freeze infrastructure, or avoid anything new, they would take it. Not only would they take it, but they would embrace it and stick with it. How did we know? Many customers continued to run Outlook 97 even though we had several new releases and they had no interest in touching email on the desktop or retraining users. Windows NT 4.0 was still a dominant server running many Exchange mail systems and it was released a decade earlier. In fact, the most critical initiative in the field was to upgrade NT 4.0 customers to Windows Server 2000 or later.

With the 10-year support lifecycle in place, CM would mean customers would assume they could run the new release the old way for another decade.

We had always tried to honor past products with immense levels of compatibility that went far beyond any of our competitors on the PC. The lessons from changing the file format in Office 97 were clear, but so were thousands of accommodations or compromises we made over the years. Now, however, the combination of Enterprise Agreements and the 10-year lifecycle proved to be a huge leverage point customers had with product groups. So much so that customers always assumed that any changes to a product would be optional. Their ideal new product release was one that was the old product, just faster and easier to deploy and manage, and the new features would be available on an as-wanted basis.

That was not our plan with Office12 and the Ribbon. Ever.

The Mid-Year Review (MYR) where we were swamped with compatibility mode requests provided the best evidence for the excitement surrounding Office12. Many countries used the new visualization features of Excel to enhance their revenue, budgets, market share, and expense numbers. Every grid of numbers used the new features to automatically color code red/yellow/green or included tiny sparklines for a great visual effect. This time I knew how to accept the MYR feedback gracefully by empathizing with a commitment to get back to the teams.

I must admit I already knew the answer. We decided at the earliest days of the project (May 2004 precisely). It would be a few months from then before anyone would even ask about it.

During the early demos of Office12 when BillG went from office to office to see a select set of features, one thing he mentioned to me that I wrote down was “classic mode”.  He wanted to hear why we didn’t show him CM. He thought doing so was “trivial” and was something we of course did, but maybe (as was almost always the case) we were going to add it later. He was prepared to make his case and we had to defend our choices. We had to do so knowing we had no backup plan. Any product changes would mean a product slip, but that was the least of the worries. Bill did not think in terms of product slips or schedules even, and often believed what he asked for would be easy to squeeze in. The scale of the projects was still something he was not entirely adjusted to.

JulieLar and her manager and leader of program management (and former leader of Office development) Antoine Leblond (Antoine) were the right people to go to follow up with BillG. In January, they walked him through the state of the design, how we would measure success, and what risks we saw. They answered his questions with the supporting data. They detailed specific scenarios that they repeatedly measured throughout the development process.

I wasn’t at the meeting, but they told me it went well. Julie shared one direct quote from BillG, later shared in a magazine story. At the end of the demo Bill said, “I can’t believe you convinced me to get rid of menus and toolbars.” It was also one of the last Office product meetings BillG would have as a full-time employee before he transitioned to part-time later in 2008. We were done talking about CM.

We hit Beta 2 and RTM only about 90 days off the original schedule of the two-year project. By our standards we became an execution engine, and with Office 2007, as it would be officially named, we also showed we could innovate in a big way.

There were many reviews, now many blogs, from the end of 2005 through 2006. Reviews focused on the major overhaul of the product as expected. Also as expected, each put the question out there asking if it would be too radical or too bold. Nearly every review was positive to glowing.

A smattering of reviews continued to complain about the lack of a bridge to ease into the Ribbon, compatibility mode, or a way to turn off the Ribbon, which they just assumed would be there. Of course, there were customers who told us they were not going to upgrade, but for any release only about one-third did anyway. That was another problem entirely, and all the Ribbon offered was a convenient excuse that went beyond budgets, IT strategy, something else.

Personally, this release was the confidence builder I needed after a challenging Office 2003. It felt great to build the hot or at least interesting and innovative product people were talking about. This came at a good time for Microsoft given the Longhorn chaos and the cloud over the company due to the regulatory settlement.

Anil Dash was early in popularizing blogging (today he would have been called an influencer). He authored a post I loved. It read, “Short and sweet, the Ribbon and new UI in Microsoft Office 2007 is **the ballsiest new feature in the history of computer software**.” [asterisks in the original]

He also captured the risk that we felt for the preceding two years:

Now, most of us who like to prognosticate and pontificate about software like to say things like “It’d be easy to just . . .” or “It’s trivial to add . . .” but the thing is, most of us aren’t betting our entire careers on the little tweaks and changes we’d like to make to our productivity applications. Try making a mistake that jeopardizes a business that makes $250 million a week.

But something else was on our collective minds.

What came after the Ribbon would not be more features in traditional desktop apps, but more internet scale services, more use of the browser and mobile, and more connections to data. We built the equivalent of the Cutty Sark, the best of wind-powered clipper ships. Steam-powered ships were coming, however, in the form of smartphones and mobile-cloud computing, as long-time industry analyst Benedict Evans would later write in an essay “The best is the last.”

The era of formatting documents was ending. The Ribbon was a new paradigm for desktop computing (what we called Win32 apps) in a world rapidly being overtaken by the web.

We were also approaching the end of an era of software reviews. We could sense that as we went out on press tours. There would not be another release where a magazine would devote dozens of printed pages to Office, or Barnes & Noble would have a shelf of Office books. One review mattered above all for me personally and that was by Walt Mossberg at The Wall Street Journal. It wasn’t just that he was the most influential reviewer, though he arguably was. Others would review every feature and have dozens of screenshots. Walt spoke for the typical customers, the non-techie, the person who just needed to get work done without futzing. Winning that review meant winning over that customer, at least by proxy.

No one expects a perfectly glowing review of any product from Walt because he makes a point of raising concerns that normal people will have from learning, to new file formats, and even the pricing. That said the headline alone was huge for us and it was a big enough deal that the WSJ placed it on the front of the business section with color screenshots— “Bold Redesign Improves Office 2007.” There was that word, bold, just like we aimed for at the start of the release. He went on to write:

So, when Microsoft makes significant changes to Office, it's a big deal. And the latest version of the software suite, called Office 2007, due out Jan. 30, is a radical revision, the most dramatic overhaul in a decade or more.

I don't use the word "radical" lightly. The entire user interface, the way you do things in these familiar old programs, has been thrown out and replaced with something new. In Word, Excel and PowerPoint, all of the menus are gone -- every one. None of the familiar toolbars have survived, either. In their place is a wide, tabbed band of icons at the top of the screen called the Ribbon. And there is no option to go back to the classic interface.

. . .

If you'd like to get more out of Office, especially in the area of how your documents look, Office 2007 is a big step forward and worth the steep learning curve it imposes.

Of course, I personally fixated on the places he was critical. For the team this was a huge, huge, win.

While we gave new life to Office with the redesign and we created a foundation to continue to evolve the product incrementally, the next wave of innovations would (and should) be entirely different products. We disrupted ourselves. We made the previous releases of Office look old and underpowered. OpenOffice would continue to chase the old design, and the soon to be released Google Docs would do the same.

The world was changing though, and we knew it. It wasn’t just the reviews going away or the rise of the web for consumption. In November 2005, just before the MYR process detailed in this section, I wrote the framing memo as I always did for what would be called Office14 (yes, we skipped Office13 though I was careful to note that 13 is unlucky only in some cultures). In Aligning for Office14, I described five “Big Bets”:

The big bets we will explore as we begin aligning the team for Office14 include:

* Moving Up the Value Stack

* Office Web Companions

* Internet (Web-Based) Services

* Building on Windows Live

* Office's Enterprise Content Management Platform

The first bet was about enterprise computing, as it should be. My heart was in the second bet, which was to build Office for the browser. I received immense pushback for suggesting such heresy. Often people used against me my own argument from years ago that the browser wouldn’t work for “real productivity.” The trajectory we were on was now clear and the time to start was now.

To ease people into the idea, I positioned (so cleverly, I believed) the idea of building Office for the browser as “companions” to Office and called them OWC, the Office Web Companions. As companions versus competitors or replacements they would not risk cannibalizing the real Office. The other challenge within Microsoft was the view that corporations would be running a Microsoft-centric “browser-based” platform using much more capable technologies that relied on proprietary Windows Server and Windows Longhorn such as successors to ActiveX. The broad consumer world would be running “web-based” solutions in a least-common denominator browser (a phrase always used when referring to HTML.) It was a subtle difference in wording with huge implications strategically. So I danced around both as I wrote and then evangelized the memo.

I was very excited to build on our 1990s strategies of embracing the web with HTML and then Office Web Server. I was already dreading what was sure to be a significant uphill battle across the company, not unlike what we had faced in building Office 2007 or using HTML or creating SharePoint. The company had a strategy and these bets seemed to run counter to it, but only at first glance. I thought a good deal about how Windows rose out of what was often branded internally as a side project, operating environment, or experiment.

It was going to be a journey to disrupt the desktop applications, but we needed to start.

My direct reports and our significant others gathered for a dinner at Assaggio Ristorante in Seattle to celebrate the final beta release. I hardly ever asked people on the team to do things outside of work hours, but this release was so special.

Months earlier in just a hallway conversation, Richard Wolf (RWolf), manager of PowerPoint and Visio, said that it was cool that the “last” release of Office was the one with a major UI redesign—it was almost poetic for him to say. Richard was the productivity philosopher among us, having worked at Lotus before Microsoft, a reflective person, and an early member of the academic community focused on productivity. He was right. There was no reason to think there would ever be another major redesign of Office that was necessary.

Innovation is like that. Microsoft was built on the idea of creating, grinding out improvements, then moving to a new platform to innovate. We were at that point. Everyone could see it. It was as if we each felt it in our own way. We had accomplished what we set out to do a decade and six major releases earlier.

We shared a toast (of a beverage of choice) to what the team accomplished. We were proud. And we were happy. We built the very best version of Office—a reinvention of the product—in a way that had never been done.

For most of the seasoned leadership team at this dinner, this was going to be their last release of Office. I think we each knew that.

Things were about to change for me too. As happy as it was at the time, it was also a bit sad. There was always a bit of a low after shipping. The grind of building suddenly stops. A sense of mission accomplished takes over. Also, I just turned 40.

Unbeknownst to me at the time, this would be my last release of Office. Something I never even considered.

That Office14 memo was my last work on Office.

On to 083. Living the Odd-Even Curse [Ch. XII]

We’d been working on Office12 for almost two years and the product had made enormous progress. The team was buzzing, and everyone was very excited. This product was different. We were building something we could all feel. It was a product that was good for individuals, not just organizations. Still, no one outside the company had seen it or knew of the monumental changes we were making. The user interface in Office was not just a user interface for the PC, for many many people for the past 15 years it had been the interface for the PC. We were quite confident. JulieLar was confident and prepared. This was a big moment, the first public showing and then the first feedback.

Back to 080. Progress from Vision to Beta

The first lesson of interface redesign: Do not unveil the design with static pictures.

The second lesson of interface redesign: Do not unveil the design with static pictures.

At the 2005 Professional Developers Conference (PDC), Chris Capossela (ChrisCap), Corporate VP of Information Worker Marketing, joined BillG on stage for a sweeping demonstration of Windows Longhorn along with the first public reveal of Office “12” (the quotes with a space became the official way of writing the name). ChrisCap and the marketing team zeroed in on the positioning of “Better results, faster,” while also pointing out that Office was “New, but feels familiar.” The demonstration zipped across Excel, Word, and PowerPoint, showing all the elements of the redesign and dozens of new features, along with many others previously undiscoverable. I was sitting anxiously in the very back of the room gauging how people reacted. I did not have to listen too carefully as during the demo someone shouted out to the stage, letting everyone know how they felt.

“Ship it!” they yelled.

We were still two months away from the first public beta, but this felt good. Only afterwards watching the tape did I realize we were being made fun of. Chris inadvertently missed a beat in the demo. His words describing what should happen did not match what was happening on screen. It looked like a bug and “ship it” was a classic Microsoft reference to shipping something with bugs. Nevertheless, the reception for the demo was quite positive.

The excitement spread through the industry.

Technorati, a tech news site that measured the important or high impact blogs on what was then called the blogosphere, was the place to be seen in the press. Our redesign made that home page, a first for plain old Office.

Despite the excitement of the moment, we learned a good lesson.

The video of the keynote was posted, but in 2005 not everyone was hip to consuming video. That meant that the still images (from Treo phones and the like), screenshots from the event, and JensenH’s later session made their way around the blogosphere. That proved to be a mistake. The spread of simple static screenshots for such a major change in user interface was not the way to communicate the redesign.

Almost immediately we were confronted with a wave of comments proclaiming the Ribbon to be too big and that it took up too much of the screen—assertions made by comparing screenshots to the current version of Office and making snap judgments. Attendees at the developer conference were counting pixels but not considering the full scope of the design or the experience. Besides, there really was the same amount of room for content—that was a key point of the design.

We did not anticipate this level of dissection, and that was a mistake. This immediately reminded us, especially JensenH, of his redesign of Outlook and the furor over the layout. Recall from the previous chapter that we had a spirited debate among early testers over whether the layout displayed fewer or more email messages. The question being asked was whether the ribbon took up more space than the toolbars and menus previously there.

We had some work to do.

Lost in all the comments about how big the Ribbon seemed to appear was the fact that we eliminated the row of menus entirely. Some comments and blogs slowly absorbed that reality over the course of the day as the magnitude of the design began to sink in. The Ribbon was not, as people thought by looking at a static screenshot, a big, fat, tabbed toolbar. It was so much more.

Also missing from this discussion were the differences between tech enthusiast or developer use of the product and typical users. We knew the typical user interface experience from instrumentation. Most users ended up with two rows of toolbars, the main menu, plus toolbars floating around the screen, and the side pane (that innovation from Office XP) each obscuring the document or squeezing in on the user’s work. By contrast, a very small number of tech enthusiasts prided themselves on purposely designing and maintaining a very select set of commands, often in a single floating tool palette (itself a very poor choice unless you have a giant screen, which many developers did). This was not the real world or even the base case, though we would eventually craft an answer for even this hyper-customized form of user interface.

In hindsight, letting the static shots out without video or animation was a rookie move that we corrected eventually. We were at the earliest days of real-time reactions to product launches.

Microsoft had recently begun using video as a means of connecting with the tech enthusiast community. The Developer Relations Group (DRG) created an online video site, Channel9, hosting videos with product leaders from across the company. JulieLar initiated the ground-level engagement as a companion to the PDC by recording a casual and friendly 40-minute discussion along with demos from her office. This video made a huge difference and began engaging the techie crowd with a good deal more information.

Simultaneously, JensenH began his new blog. Blogs were the rage among product leaders. Many of us maintained “external blogs”, or blogs that were visible to anyone, something that seemed risky for big companies at the time. Jensen shared his first Office12 posts after his PDC afternoon presentations. The blog was titled, Jensen Harris: An Office User Interface Blog. Portions of his blog can be found on a Microsoft site with a table of contents, but unfortunately Microsoft changed platforms and all the images have been lost. https://docs.microsoft.com/en-us/archive/blogs/jensenh/table-of-contents (individual posts can be found on archive.org).

JensenH had many talents beyond his obvious software skills and his regular performances with the Seattle Symphony. He was also a fantastic writer, a style he honed while writing a column in high school for USA Today. His posts detailing the Office12 redesign were not only incredibly well executed but ultimately served as a model for how a product could and should engage discussions on building software at scale. Through the course of the remainder of the release, and even today, these posts serve as reference materials for one of the most substantial redesigns Microsoft ever undertook (so far!). While obvious today, the press and reviewers were also following the posts carefully—something we took note of and proactively communicated with them. We never edited, cleared, or otherwise scripted posts. Jensen did this all on his own and under his own supervision, with the goal of detailing “why we’re changing the UI, not just how we’re changing it.”

Incidentally, this became another story of an Office process spreading virally across the company. I was often asked to point to the team in marketing that was doing our blogging and to the blogging strategy deck. It was one of those moments when I recognized parts of the company were scaling or growing up differently than Office. In other parts of the company, something like a blog would be a team, a budget, and a process with meetings and so on. We had none of that. It was just JensenH (and others) writing. We’d occasionally talk about topics to cover but otherwise it was an entirely organic effort. The key was that there was no strategy or oversight or overthinking, but just telling the actual story of the design and responding to the legitimate questions about it. Nevertheless, Gavin Shearer (GavinS) on the product planning team wrote up a blogging whitepaper so the rest of the company asking could see that we had some structure. Gavin met with several of the team’s bloggers to see how they worked and turned that into a guide for the future. It makes for an interesting historical record contrasting with today’s carefully crafted and managed communications. It served as a foundation for how we would later manage the larger task of writing about Windows (more on that soon).

Among JensenH’s first posts about the Ribbon were pixel-by-pixel discussions of the size, even discussing alternatives that had been suggested in other articles and comments. In a post called “Mythbusters” (the TV show with the same name was popular at the time) he helped readers to see why the Ribbon was far more than a fat toolbar or why the layout was organized by usage frequency and scenario, not implementation category. For each of the main areas of innovation in the design, Jensen walked through in detail the design in a calm and factual tone, along with humor, and colorful (and embarrassing) comparisons from past releases of Office. The posts were wildly popular and served as a model for much of the future blogs our team would author.

The two months from the PDC to the technical beta went by quickly—a good deal of product work was needed, but time flew by because of the incredible interest in what we were cooking up. Fairly low-key beta tests were the norm and only moderately interesting. Suddenly techies clamored for access to the release, which we limited because of our own views of quality and inability to support full-time usage of the product.

We got some early instrumentation on usage that started to confirm much of what we hypothesized with respect to the design (noting that these early users were intentionally trying out many parts of Office they might not routinely use). Those who got hold of the beta were clearly exercising a lot of the product and trying it out. It had been a long time since there was so much excitement about a pre-release version of Office.

In November, we released the technical beta, which was open to developers, enterprise customers, and the Microsoft MVP community, Most Valued Professionals, who played a key role in the beta process of the Office12 redesign. Most enterprise customers did not tend to pick up early technical releases for evaluation.

Who are these MVPs? We were briefly introduced to this group of supporters when they initiated something of a protest against the new Visual Basic .NET, referring to it as Visual Fred because of the lack of relationship and compatibility with their much loved Visual Basic. As we’ll see, compatibility and respect for the past are super important to MVPs who pride themselves on deep knowledge of Microsoft history and products.

The MVPs are an elite selection of consultants, educators, writers, and generally independent thinkers who are deeply committed to Microsoft products. Each of the major products has a group of MVPs from around the world assigned to it, with the MVP program managed by a central corporate team. Becoming an MVP involves a rigorous nomination and selection process along with reapplication when a term is up. MVPs take great pride in their role and commit significant effort, and often their livelihood, to Microsoft products. It is such a big deal that most readily identified their MVP status in email signatures, resumes, business cards, and today on LinkedIn profiles.

The MVPs are super important to the product once it is released. Many books, training videos, and courses on products are created by MVPs. Many command large audiences online and are the key creators of how-to content in many forms. While the program is centrally administered, including a yearly MVP conference, the product groups all have people assigned to serve as liaisons to their MVPs.

Over the years, the Office MVPs grew a little anxious in that they generally felt they did not receive enough insider information on planned features and ship date. My sessions with the MVPs sometimes had a bit of an edge because I did not use the forum as the first or earliest disclosure event. There was frequently some tension between the promises made by the managers of the MVP program and the product groups like Office in how they positioned the program relative to disclosure and influence on products. Office was perhaps unique in designing for a broad audience of many stakeholders. The most engaged MVPs were like the close-knit IT managers the Windows Server team managed with minimal risk to their IT-focused disclosure and business. I was always cautious of over-indexing on specific customers, especially when we knew they were a deviation or two from the typical user. One of the more challenging aspects of Office was how everyone tends to believe their use is widely representative of others, even software professionals who know this tendency but sometimes have trouble resisting the temptation to represent themselves.

I wanted to find a way to address this gap while also recognizing our responsibility to enterprise sales and customers. Regardless of the forum, I never wanted to be in the position of over-promising with a risk of under-delivering. I strongly believed sharing was committing and failing to deliver to customers had a high cost. Before the November beta, at the yearly gathering of MVPs in Redmond, we had a special session for the 50 or so Office and SharePoint MVPs.

They were invited but didn’t know it was special.

After JensenH did a never-before-seen talk on the Ribbon, I walked to the front of the large meeting room and sat on the speaker’s podium at the side of the stage.

“There’s a feature in Office that everyone has wanted forever and been asking about for as long as I could remember,” I said. It was a feature all our competitors provided, and some even claimed it to be a huge advantage over Office. I continued, “available in the public beta in a few weeks, Office12 would provide full support for saving files in Adobe PDF format.” We simply called this Save As PDF, exactly what everyone would have called it no matter what we named it.

The room went crazy.

I hopped up onto the stage and showed a click-through demo of the feature working exactly as expected. PDF was another file format option in the File Save As flow. I showed PDF in Publisher, Visio, and Word.

In today’s context this sounds supremely dumb. How could our best and most informed users get so excited over PDF? Today PDF is an utter commodity. Everyone uses PDF and no one thinks for a moment if it cost extra. Companies from DocuSign to Google and every institution from banks to hospitals and every government create PDFs and enable their customers to create PDFs. Every browser supports PDF. Every tool creates PDF. But in 2005, Microsoft alone was not in the PDF business yet the whole world was using Microsoft creation tools. It was a big deal, and the world was a silly place.

I then shared that the work was done by the Publisher team and they took on the work to implement it in all the Office applications. At the time, it was a remarkable maze (or thicket) of legal and regulatory challenges: a feature that our competitors supported, that utilized an open and published standard, and that was an entirely obvious customer need. We were receiving more than 30,000 comments per week on our own Office website requesting PDF support. The code was only half the battle. Would regulators view PDF as anticompetitive? Would implementing PDF in Office and not charging money for it be predatory pricing? What would Adobe think or even do? Would there be intellectual property challenges?

It was this last concern that kept us awake. A patent dispute claimed against Office got very expensive very quickly.

Adobe invented PDF more than a decade earlier. Recall, when I was working for BillG, the idea of creating viewable files was a key initiative passed on from my predecessor. Even before PDF, BillG did not want to do a file format that could not be edited and still did not. Adobe distributed a free PDF viewer on every computing platform, but to create PDF required a license, except on Steve Jobs’s NeXT operating system where it was built in (and thus eventually on Macintosh and iPhone too!). Over time, however, as the internet made PDF more useful, Adobe got pressure, especially in Europe, to make it possible for third parties to create PDF legally, for free. This was already happening, but technically such work risked violating the PDF license or intellectual property. Adobe, perhaps a bit too clever for its own good, published an open specification in a European standards body. We built our feature using only the open specification in a metaphorical clean room.

Adobe was extremely concerned by our support even though we relied exclusively on their open specification submitted to the European standards body.

Except we were Microsoft. Even our largest and soon to be most evil of competitors, Google, and our main Office competitor Sun, were using PDF to compete with us. In fact, the only way to print a document created with Writely, the browser-based word processor that would be acquired by Google, would be by outputting it to PDF which they announced shortly after this event. OpenOffice created PDF by a simple Save As command.

It was the peak period of fear and the assumption that everything we did had a potential for an evil twist, and as such the legal team was predisposed to capitulate to any regulatory skepticism by simply not shipping a feature. In fact, Save As PDF was completely benign and customer driven, but in the climate our motives were always questioned. Erich Andersen (ErichAnd), our fantastic head lawyer for Office, Alan Yates (AlanY) in marketing, and many others spent weeks briefing regulators, trade press, industry groups, standards bodies, and more, laying the groundwork for the feature. ErichAnd spent countless hours with his fellow Microsoft lawyers and those in the antitrust group convincing them we were on firm ground and delivering PDF was going to be OK when their reaction was to avoid regulatory scrutiny at all costs. Perhaps the biggest lesson from the regulatory era was that a company in a dominant position can’t always do the things that are perfectly acceptable with a lesser market position.

We were so worried that something might backfire in the antitrust or patent worlds that we designed the feature so we could easily remove it with a small update or reissue Office without the feature. If any party chose to litigate, it would not do so until after Office was commercially available to maximize the inconvenience for us and the damages owed to them.

Still nothing is ever easy, suddenly all those working hard to create or use our expanding XML file format were concerned we were sending a mixed signal to the market. XML was intended to support some of the scenarios PDF could, at least technically. The program managers working on XML authored a series of clarifying mails to be shared with the field on this topic. Under the hood, a key initiative for Office12 were the new XML-based file formats (the “x” in .docx, .pptx, .xlsx). These formats would eventually be published as open standards as well, a fact we also used to deflect any potentially conspiracy theories regarding our use of PDF.

One other wrinkle was that the Longhorn team was doing its own PDF competitor, called XPS (of course the X stood for XML in XML Paper Specification). We used the same code path we created for PDF to support also XPS. Peter Pathe (Blue) the VP leading the effort let the Windows team know we would support XPS, which they had previously pleaded with us to do. They were very excited to hear the news, but their excitement was considerably tempered by our additional support of PDF. Supporting both reinforced our claim as Office that we were trying to help customers by including multiple technologies.

We prepared an enormous package of briefing materials—all for a single feature. We had a whole media plan, Q&A with me on Microsoft’s main web site, a long set of RUDE FAQ especially over the Longhorn XPS format, and even a draft email to send to influential press and partners. It was a production.

Save As PDF was so popular that it quickly became part of the standard demo flow—a feature that exported a document out of Office, not into Office.

Save As PDF was very well done. We supported all the key features of PDF, such as accessibility, fonts, images, and more. Never had we done something so obvious and yet so difficult to release to market. The fact that the lightly resourced Publisher team delivered PDF was a special bonus, and development manager Ben Ross (BenR) did an amazing job. PDF support, through the work of people on the Publisher team like Cherie Ekholm (CherieE) in test and test manager Tammarrian Rogers (TRogers), also furthered Office efforts in accessibility and worldwide government standards.

We received emails extolling the virtues of Save As PDF from dozens of MVPs. It was so rare in a business of our scale to deliver something so immediately positive without cynicism or skepticism. The most elite members of the press from Walt Mossberg at the WSJ and Michael Miller at PC Magazine reached out to congratulate or mostly to thank us for adding support. PDF was crucially important to their workflows, and this made their lives simpler.

It is weird to think, but a feature that seems so dumb today was easily the most friction-free and joyous addition to a product I think I ever did, except maybe for the widget that counted compiled lines in Visual C++ that made everyone think the product was faster. Peter Pathe (Blue) our VP of Word and Publisher overseeing the work was equally happy, especially considering his own personal history in typography and publishing technologies, not to mention studying at the MIT Media Lab during the heyday of e-books.

A few weeks after the MVP conference, the Office technical beta was released. The MVPs received a lot of attention and were anxious and ready, and also feeling good about the insider scoop they received. This would be the first time anyone would have their hands on the code to use day in and day out—and the product was ready for that.

Once the Beta went out, we immediately began monitoring the private newsgroups (using the old NNTP protocol) the MVPs used to talk to each other—these newsgroups were the closed-door and NDA (non-disclosure agreement) meeting place for MVPs and part of what they valued most about the program. The product groups were on the hook to monitor the dialogs and respond to issues. The Beta proved to be the source of many emotional and heated discussions.

The good news was that these discussions were mostly the arguments we heard following the PDC. The MVPs were a slightly different crowd than the PDC developers. They were dedicating their careers to Office. They had a lot to discuss.

Almost immediately we were again (!) confronted with the feedback that the Ribbon took up too much of the screen. They were sending us screenshots of their customizations of Office—carefully removing much of the default user interface and relying heavily on keyboard shortcuts. To such a setup, the Ribbon was huge and wrong. Some showed us their dual monitor setups or how they arranged windows for multiple documents on a screen in skinny columns that did not work well for the Ribbon. Others had wide screens and sent us proposed renderings of the Ribbon oriented vertically on the screen to “save screen real estate.”

We recognized that many of these were personal preferences. We knew we were making a major change and major changes that undid knowledge of the most knowledgeable power users almost always received significant pushback. Through the course of this writing, I’ve shared several such stories such as the introduction of the new setup technology in Office 2000.

We filled our replies to the comments with data from our telemetry about how Office customers used the product: the screens they had, the number of toolbars and task panes that were routinely visible, and so on. At each juncture, the discussions devolved to a point that we were asked for options: options to move something around, hide something, or be able to change something. This was a normal reaction to change. Essentially, those resistant to change do not battle the change as much as request the ability to not experience it. . . to turn it off and go back to the old way.

Articulating that the redesign was a programmed user interface, like the cockpit of a plane, not a set of parts to be assembled, was our challenge—essentially rethinking the ancient design point of a customization-centric product. We changed the whole model and made it much more productive, and, in a real sense, moved the customer base (not only the hardcore technical users) to a higher level of expertise and mastery. We did this the very same way the graphical interface itself made software easier, by improving the abstractions. The graphical interface technology of pull-down menus with a mouse replaced arcane and seemingly arbitrary keyboard shortcuts of early character interfaces. The Ribbon replaced the user interface that essentially mapped every feature directly to an implementation and constant document debugging and futzing with higher-level abstractions that regular people could understand.

There was one raucous private newsgroup debate that came to symbolize the challenge of the thesis of operating at a higher level and even of the Ribbon itself. It started when one of the MVPs posted a message ranting, sorry raising the feedback, about “sub-second keyboard access.” The post explained that the reason the Ribbon wasn’t satisfactory was because it required the mouse, and what was needed was sub-second access to any command. MVPs often customized Office to provide unique and highly tuned access to commands. With the Ribbon this level of tuning was not (yet) possible. The MVP simply stated:

Advanced users have ***got*** [emphasis in original] to have convenient -- that is, sub-second keyboard access to all dialog boxes and many common commands. Without that capability, Excel 11 never will be uninstalled, because using it will be so much more efficient than using Excel 12.

As challenging (annoying, actually) as the comment could be interpreted, I resisted the temptation to immediately dive into the debate, as I was often impatient with this type of comment (threat) from insiders. I would forget to remind myself that while we had debated these very points for the past 18 months, the MVP was seeing everything for the first time. Instead, I commiserated down the hall with Billie Sue Chafins (BillieSC), one of the key program managers on Julie’s UEX team, reporting to JensenH. Billie Sue moved over to UEX from JeffO’s web services team where she was hired in the middle of the Office XP project. Like many (but not all by any stretch) program managers, she was a trained computer scientist, having put herself through school after moving from rural Kentucky, where she was born and raised. Unlike most program managers, Billie Sue was also a teacher, having been a university lecturer of computer science before heading to Microsoft. As a key member of the UEX PM team she was in a perfect spot to drive engagement with the MVPs who were extremely interested in the Ribbon. Billie Sue kept an eye out for hot issues and made sure the team was handling the traffic.

The “sub-second keyboard access” feedback stumped us. Once when I stopped by her office, we looked at each other trying to understand what that could possibly mean, because no one could type and execute commands that quickly. She knew debating the premise of his question would be futile. When forum participants smelled weakness, a pile-on followed. Suddenly, everyone needed “sub-second keyboard access.” Billie Sue drafted one of many responses on the thread and eventually provided enough data on usage, customization, and more to at least explain why the design worked.

The larger point she made was how the design committed to providing full keyboard access to all the commands, without having to customize the product to do so. In fact, part of the innovation of the Ribbon was to make sure everything was accessible via the keyboard. In addition, she pointed out that existing keyboard shortcuts remained compatible and customizable. This thread gave Billie Sue the opportunity to acknowledge the feedback and commit to improvements. We already planned on having full keyboard access. We just did not have it in the technical beta.

For every “sub-second” post, however, there were many threads not only defending the Ribbon and experience but calling it brilliant. Some of the more entertaining, if not parochial, comments asked if the Office team might go over and help the Vista team out. More on that later.

Customization continued to be a topic in the newsgroups simply because the MVPs were the people who customized the product the most. The data we offered showed how few people customized (or how often customization happened by accident and could not be easily undone), but there was no telling that to an (or the) audience of customizers. Experts always want customization options, but options have an enormously high cost in the short and long-term that impact customers as much as Microsoft. This is especially true when it comes to customization of user interface—something we were freshly experiencing as we worked to fully support the customizations that developers had become used to for creating custom applications hosted within Office. What doesn’t make the product too complex today, will certainly make the product more complex tomorrow when the combinatorics of all the various customizations conflict with each other. What always seems like a simple preference or switch turns into a testing and compatibility matrix from hell.

We were in the earliest stages of the design of what we thought of as a customization escape valve, a place for those strongly committed to customization or, frankly, where the usage model was so far from typical. The Quick Access Toolbar (QAT) was a row of buttons that could be turned into any command from anywhere in the product. The MVPs could have full customization control over this feature. I admit to forcing an expansion concept of the QAT on the team for the power user customization scenario. It was kind of ugly and broke the model, but it was also a life saver with a specific set of customers. The brilliance of how the team designed the original QAT was how minimal the impact was on the overall Ribbon model and design.

The QAT, which is the tiny little row of buttons at the top-left of the title bar (at least through Office in 2021), had buttons for Save (the classic disk icon), Undo (the back arrow), and Redo (the forward arrow). The QAT was meant to have the very top used commands always accessible regardless of what part of the Ribbon was visible. We were so worried about how dumb it might look for Save (of all things) not to be visible since it was from the first toolbar, that it was placed in the QAT. Much to the disappointment of HP, printing began its slow decline in the early 2000s and given the telemetry it was not on the QAT.

Surprisingly, none of the participants, so many well versed in history, drew the analogy to a feature in Macintosh Word called the Work menu (I believe going back to version 3.0 in 1987, the second Macintosh version), which was precisely the same idea—a menu that could be customized to contain any command in the system. Sometimes what is (very) old becomes new again and is even better when its reemergence goes unnoticed.

In the very early days of Excel, a command called “Set Print Area” was moved off the File menu and it immediately jumped to the top of the customer support call issues (today this command is mostly automatic, but also readily available in the Ribbon). Fast forward to 2007, JulieLar and I were invited to join with a Harvard Business School executive education session being taught a case study on the user-interface redesign. The students were asked to prepare their notes for class using brand new Office 2007, which none of them had yet been using given the pace of corporate deployments. As soon as class started a student/executive raised their hand and asked Julie “How do I print?” as the rest of the class groaned in support. The omission of a Print button on the initial QAT might have been the biggest oversight of the entire project. It was certainly an embarrassing moment.

The beta was solid enough that thousands were using it every day, and it was clear more of the product was getting used, quality was high, and we were on a path to finish. This, however, was the technical enthusiast audience.

Our next step was a broad release, including the core business users, specifically IT managers, who generally didn’t react well to change and could be very vocal about it. The press and reviewers would also be testing out Office12 and most of them used Word and Excel for hours every day.

On to 082. Defying Conventional Wisdom to Finish Office

This section tells the story of a plan coming together and the breadth of the release. We did have a bit of a speed bump early on. I was told to align schedules with Windows Longhorn (the next Windows release). The difficult reality of Longhorn had not yet sunk in. The new user interface for Office12 had surprising upsides. While we were confident, we did not know at the time just how positive the changes in Office12 would prove to be.

Back to 079. Competing Designs, Better Design

Organizationally, we had become a (relatively) well-oiled machine. Procedurally we knew how to work. We also knew what was required at the high level and individual teams knew how to fill in the details with plans. Writing this all down and communicating to the organization a product vision—the vision for Office12—was the next step.

Transitioning from Office 2003 to Office12 was happening across more than 2,500 engineers. In every respect we were building a coherent and collaborative plan with little dirt flying and no injuries, as the old MikeMap description of Office went.

By spring 2004 we had a complete product plan in addition to the user experience redesign described previously. Even with excellence of execution, this was not a lather, rinse, repeat release. Collectively, we learned some lessons from the previous releases. We learned more is not better, and that it was time to rethink, or, as we said in the vision, redefine the user experience. We learned that blindly following the enterprise path could lead to stasis, and in technology failing to innovate or standing still was equivalent to going backwards even when the best customers were telling us of the high costs of change. And finally, we had a firm grasp of how the product was going to evolve beyond document creation—the role of servers, services, email, and more were all important parts of Office12.

The question was not whether we had a good plan or even if we could execute, but would the results live up to our goals. . .finally. There was also a huge risk to making a big bet on changing the user interface of the product—an incalculable risk. It is the kind of risk you either accept and go for or don’t try at all. Many people inside the company, and even on the team, immediately saw the risk of such a big bet and absolutely wanted to know the risk mitigation plan. There wasn’t one. Any risk mitigation plan would only result in a compromise design, because at every step someone would be saying not to worry, we always have a fallback. Backup plans on big bets have a way of permeating the whole product development process and ultimately deny the resources required to achieve the goals, reduce the appetite for risk, and simultaneously dilute the efforts to achieve the bet itself.

From my perspective Office12 was all about that opening sentence of the vision document and a single slide shown at the team meeting for the vision. It read, “No More Good Enough,” with a big red circle slash. Surrounding that PowerPoint SmartArt on the slide were reviewer quotes about bloatware and competing with Sun’s free OpenOffice, along with some juicy analyst quotes about technologies that still weren’t going to pan out. It was not that we set out to compete with a free product that had yet to make inroads, but we needed to reset the narrative that Office was complete, old, boring, and, worst of all, bloated. We had to show that there was deep thinking in the product and the paradigm of document creation was ripe for innovation, and by doing that we could demonstrate to the market that productivity tools were not commodities.

In the conventional wisdom of the day, Office was ripe for disruption. There was a less capable product claiming to be a substitute for less money. We took the initiative, intent on doing the disrupting ourselves and not letting something like OpenOffice, or our old products, do it to us. Not to race ahead, but one thing they don’t tell you about in disruptive theory is that losing to a head-on competitor is almost never what happens. Head-on competitors end up, well, running head-on into the entrenched product and that is exactly what happened with OpenOffice. Google’s future suite would initially make this same mistake, but we were at least a decade before they would begin to address that false start, and three years before even their first release.

The redesign of the user experience was more than one part of the product or strategy. It was so visible and so potentially disruptive that we knew no other aspects of the release would rise above it, certainly in the initial product reception from beta through release. Managing the team and project knowing this reality was JulieLar’s mission.

The overarching importance and the inherent risk of the redesign was not lost on the team. We had become accustomed to working together and collaborating. This was the sixth major release of the product and we’d been executing as a single team, not siloes of app teams, for a decade. The team was not fighting the shared redesign effort as much as it was rallying around it. As teams saw the design make it into the product, rather than point out how it might not work and cause it fail to make the point, teams came together to make it better. It wasn’t everyone at first, but over time that was the case. Among thousands there would always be doubters and honest skeptics, but mostly there were legitimate concerns that required more work.

Success has many siblings and failure is an orphan as the saying goes. Time has certainly reduced the number of doubters across the team and company. Those working on the Ribbon have many stories of people across the rest of Office and Microsoft expressing extreme doubt and risk, but those too have softened over the years as people came to realize the different roles people play during a time of change. Suffice it to say, some of the doubters were hardcore and neither quiet nor necessarily even-handed in criticism. The same could be said of supporters. Anyone going through a big bet with massive downside would need to learn this lesson. It would come in handy for me.

The product vision process really came together. After the very rough start for Office 2000 followed by the over-correction in Office XP, and then again by another over-correction back to enterprise in Office 2003, we hit stride. The process very much became our culture and defined a new way of building Office. The output of the process, after just a few months of planning, included a robust vision document—the plan—over thirty-five pages containing details for all critical stakeholders. We covered the breadth of the 4 Ps of the marketing mix across product, price, place, and promotion. From a culture perspective we dove deep into the core tenets of the release, the non-debatable points meant to streamline discussion and reduce debate. We did so in a unique Office manner by offering tenets that themselves often contradicted each other. I had a favorite example of that. We had one tenet “Security trumps everything” followed immediately by a tenet “Privacy also trumps everything” which was a clear message to the team to be smart about resolving issues even when they contradict. The goal of the vision was to communicate the product but to also serve as a decision framework—it was not a detailed product specification, intentionally so. The full set of tenets is quoted below.

Security trumps everything. No feature will be important enough that it justifies exposing our users to malicious code.

Privacy also trumps everything. Office12 will not compromise our users’ privacy for anything.

OS and Hardware requirements remain the same. Office12 will target the same versions of the OS as Office 2003.

No new system components. Office12 will work with the Office 2003 level of system components and redistributables.

Instrumentation for all features. Any work that doesn’t include usage instrumentation will be considered incomplete.

Performance counts. Performance of key scenarios will not degrade with the new version of Office.

Flawless forward compatibility. Solutions, documents, and other content from Office 2003 will migrate to Office12 flawlessly.

Office12 is a true language-independent binary. No language-specific work will be built into the Office12 binaries.

Full accessibility. Office12 will comply with the current and future accessibility and privacy regulations flawlessly.

Watson throughout the lifecycle. We will be addressing Watson issues throughout the development of Office12.

The main themes of the release provide insight into the cross-organization nature of the plan. We worked hard to keep the plan from reflecting the org chart. While obviously different scenarios had a locus of technology in the organization, by and large everything important involved multiple teams across Office. One challenge this process always had, and Office12 showed this as well, was addressing scenarios broadly defined as database or data access. This deeply technical area had many strategic partners across the company, but also a unique relationship to Excel, which organizationally shared an executive within Office. Interestingly, we always struggled the same way most modern-day data-intensive applications struggle. All data eventually ends up being pasted or opened as a text file into Excel. Figuring out how to avoid that manual step eluded us just as often as it did for customers or third-party software.

As with previous releases the teams created sketches of the vision by each product pillar as will be described. These sketches serve several key purposes. First and foremost, they are a tool for the team that owns an area to commit to delivering what is shown. These are not aspirational or directional but are supposed to represent commitments. The rest of the company was swimming in prototypes with a lack of clarity over when or if they were planned products or simply documenting thoughts. Second, the sketches served to inform the team about what everyone was working on and to provide a holistic view of the product end-state. Finally, these sketches help us to see the product end-to-end in a way that helps us to evaluate the plan for each customer segment. Ideally the sketches are not far off the final release of the product, just as the mock press release we created should be close to the real thing at the launch. With all the changes to the user experience, we did not have the production bandwidth to make sure each sketch had the most current designs, making the sketches a bit uneven in this regard. When I reflect on this, I’m glad we never over-produced the vision and importantly did not delegate the production to a distinct group, but rather we kept the low production values and saved our energy for the product.

The new user experience encompassed two vision areas. The first was “Redefining the Office Experience” representing the mechanisms and mechanics of the interface design. The second, intentionally the second, was “21st Century Documents” which emphasized the customer facing benefit of the design and the kinds of cool and important new documents that could be created. Having two big, bold, and modern goals as the first two was an intentional effort to up the ante.

The next vision area brought together our collaboration efforts for teams and enterprises, mostly SharePoint. By this time, the business of SharePoint was still catching up to its strategic importance. We still had far more traction with sales, marketing, and partners than we did with deployment and usage, but that wasn’t going to slow down iterating. It usually takes three times to get something right, and this would be the third release of the product.

For brevity, the remaining items are quoted below, including investments around data access which encompassed XML (again) and connecting data in SharePoint to desktop tools.

Redefining the Office Experience. Office12 will redefine the experience of using our applications through a bold new UI, more streamlined tools, and a deeper integration with the shell for system and document-level tasks.

21st Century Documents. In Office12, documents will not only look dramatically better but will also integrate much more efficiently and dynamically with the systems and processes of which they are part.

Effective Teams and Organizations. Office12 will fulfill the promise of group productivity, making organizations more effective through enhanced collaboration tools, better access to corporate assets, and stronger integration with the desktop.

Manage Your Time, Work and Relationships in One Place. Office12 will bring together improved e-mail, calendar, task, and contact management tools, enabling our customers to manage their time, work and relationships in powerful new ways.

Unlock and Incorporate Business Information. Office12 will make it easy for customers to collect, find, view, and analyze relevant data, communicate their findings to others, work together to make decisions, and measure the results of their actions.

Breakthrough Quality and Satisfaction. Office12 will be the most trustworthy and easy to deploy version of Office ever, and will mark a leap forward in increasing the value of our digital connection with our customers.

The Office12 Vision from March 2004 (not formatted for printing originally)

The schedule started in May 2004 (after shipping Office 2003 in late summer / early fall 2003). We presented the vision in March, giving everyone about 8 more weeks to finalize the specific features and development schedule for each milestone. While we were anxious to begin, a big risk landed on us at the last minute. The primary reason for this would be our old friend Windows and Longhorn.

Days before releasing the project schedule for Office12—not a schedule I just made up in my Office or DonGa the Office development leader dreamed up, but a consensus across the leadership—there was a panic about Office missing the opportunity to align with Windows. JeffR, the executive vice president of Information Worker products, called me to his office to talk about the late-breaking issue. We just finished Office 2003 and at the start of that release there was a fire drill to align schedules between Windows Longhorn and Office 2003. Here we were again being asked to align around that same Windows release, with our next release of Office. The optimism Windows had in late 2000 now had a couple of years of work and it was abundantly clear the project was not where it needed to be. My head began to throb.

The elephant in the room was once again the Windows schedule only this time it was their alignment of the Windows desktop and Windows Server releases. The Server just finished a release in April 2003 and Windows XP SP2 was still about six months from completion (partially why Longhorn was adding risk as well). While the core operating system was the same code for both the desktop and Server, the differences and additions created a bottleneck to getting both done on the same schedule. As a result, Windows had to admit that getting both the desktop and Server products done at the same time—something highly desirable from efficiency and go to market perspectives—was not possible. They put together a schedule with Longhorn desktop finishing in the second half of 2005 and the server shipping 6-12 months later, or second half 2006. Since Office had both server and desktop code, trying to synchronize that presented an immediate problem, besides the reliability of a schedule with multiple 6-month ranges built in. This seemed to me to be a rather theoretical discussion given the history of Windows ship date ranges (versus actual ship dates).

The approach I took was to suggest releasing in sync with Server (aka Longhorn Server) which aligned with our proposed RTM date based on the detailed vision plan of May 2006. That seemed reasonable given the stated goal of alignment with both. Most everyone was really irritated with me for lack of flexibility, which seemed odd given the constraints. Much to my frustration this came across as a desire to ship above shipping the right thing, even given the realities of the situation. I just had to accept this characterization and let events play out.

Writing this I am sure some recall what ultimately happened, at least the headline. The Longhorn desktop project would go through a big “reset” (they called it the Longhorn Reset) and eventually shipped in late 2006 for an official street date of January 2007 for Windows Vista. The Server team became frustrated and chose to ship Windows Server 2003 R2 (comprised of a Server 2003 service pack and optional components) in December 2005. The full Longhorn Server released in February 2008. As for Office, our May 22, 2006, date turned out to be aggressive and we ended up shipping on August 15, 2006. We were 12 weeks late.

Looked at another way, from the start of planning releases after Office XP in May 2001 and Windows XP in August 2001, Office shipped both Office 2003 and Office12 (Office 2007) before another release of Windows or Windows Server shipped. It is not unfair to say I received a ton of grief at the time for putting us on both the Office 2003 and 2007 schedules, which I still think was unfair as it was abundantly clear at the time how the schedules would unfold. Nevertheless, there is no joy in being in the right when others ran into problems.

The most interesting aspect of this type of history is to consider an alternate scenario. What would have happened if Office just slipped along with Windows? Would it have mattered if we never shipped either of those releases and just eventually aligned around what became Windows Vista (Office Vista)? From a business perspective, it is almost certainly the case we would have continued just fine due to the compelling nature of product-market fit as described earlier. Office XP could have carried us for another ten years, just as Windows XP could have (and sort of did). From a product development perspective, however, I could easily make the case that it would have been disastrous for Microsoft. Technically, we would have lost out on the long-term investments in servers and services, and a host of other important architectural efforts (including alignment with Exchange Server and the browser-based apps) so incredibly key to the anchor of today’s Microsoft Office 365. The much deeper impact would have been to the lack of maturity we gained in the product development process to operate at scale. The team would have just been wrecked. I don’t think I’m being dramatic to put that out there.

Rather than point out that we read the landscape correctly, I wanted to share what it felt like to plan and execute in this environment. These challenges were one thing faced from my position in Office and little did I realize at the time how important this experience would become as I moved to Windows.

With our plan in place and the whole team charging ahead with a great deal of energy and excitement, what followed was night and day from Office 2003. Where Office 2003 felt like a slog, perhaps bloated like the product, Office12 seemed to cruise along. While there were daily debates over the ever-changing interface, the fact that the product was changing so dramatically was, for most on the team, incredibly energizing. It was also nerve-racking. There were exciting moments along the way such as seeing the first right-to-left Ribbon design, as we’d ship to Hebrew and Arabic speaking countries.

Two of the more substantial issues the first two vision areas had to work through were performance and exposing more features of the apps in a manner that truly tapped into the potential of the new user-interface.

In terms of performance, we were pushing the limits of what thought would work in our apps. For the history of Office, formatting and changing the appearance of documents happened one single command at a time. Developers worked super hard to optimize this to be as fast as possible, but the user would only perceive it in extreme cases (for example changing a chart type with hundreds of datapoints). Live previews, a feature of the Ribbon, proved to be an enormous engineering challenge—never before had the products computed so many alternatives while a user simply hovered a mouse over choices. With a live preview, the Ribbon showed dozens of potential outcomes of applying a command in a gallery, while also showing the results live in the document, to save users from endless loops of trying and undoing commands. There were many opportunities for the product to be slow and non-responsive. Some on the team said the design was too difficult and we should abandon the hope of delivering previews. It would have been easy to give up. From a pure engineering perspective, live previews were an incredible accomplishment. For the press and reviews, the feature brought the strategy of results-oriented front and center making it very easy to visualize the concept. End-users could experience a whole new level of trying out a look without the dreaded undo-redo command sequence. Features such as paragraph styles in Word or new graphics capabilities in PowerPoint were brought to life in a show-me-first manner never before available.

Releases always have surprises along the way. Usually, the surprise is that the release is taking longer than planned. Office12 was the kind of release where the surprises were how much better things were going to be than even we thought. The battles, and I’m using that word on purpose, between the UEX team and the Word, Excel, and PowerPoint teams over how much to use the new user interface and for what features were difficult and really stretched the teams. The longer debates raged the less we could get done, and if you’re looking to not do something then a delay tactic is a great way to get to a point of “would love to talk about this more but at this point the schedule is locked anyway”. That’s an awful “process win” we did not like. Each time a new aspect of the user interface came online in daily builds, internal friction was reduced a bit and some cross-group cooperation was unblocked.

BillG always complained about the fact that each Office “module” (he always called them modules and we called them apps) had some form of tables, with different features and substantially different user interfaces. The Ribbon gave us a chance to bring similarity to these while also showcasing the depth and capabilities latent in the product simply because the user interface was too complex or inaccessible. By latent, the features were unused because people could not find them or did not know they existed. The Ribbon gallery made it so simple, trivial even, to have a fancy table with colored rows and columns, even totals by columns (who knew Word had spreadsheet formulas?). These were also consistent across the applications as well. It was easy to change and customize. Since almost every document and deck had a table, it was easy to spot an Office12 document from across the room simply because of the cool table formatting made possible by the Ribbon. To eyes like Bill’s, it looked like we had more shared code and aligned the implementations.

Across Word, Excel, and PowerPoint, documents were dramatically cooler and more modern (that was the word we used, and overused). The process of creating documents was blazingly fast, mistake free, and easy to change. Not a day went by when we were not blown away by the new capabilities of Office.

The design had a fascinating effect on new features. As the Ribbon was implemented, many features simply got better because of the way the Ribbon could expose them. In using the product over many years, Excel users developed clever ways to make cells red, green, yellow, or some other coding, depending on the values (if sales growth was negative then color the cell red). The manual steps required were laborious and automating this mysterious at best. The Ribbon placed new conditional formats front and center—with clear, colorful labels showing exactly what could get done with the gallery. Suddenly everyone easily added color coding based on cell values with a single click. This only made the new features even better such as cells with small up/down/sideways arrows or miniature graphs of values.

Surprisingly, ancient features were given a new lease on life and brought front and center. Generations of writers had long been traumatized by the ritual of pasting a picture into Word and trying to understand how to wrap text around it, or not. The Ribbon exposed the existing features for images and using the gallery made it trivial to select a picture and then choose among the set of choices for flowing text. It only took 20 years, but finally everyone could easily paste pictures into Word and make the text wrap around or align with the image.

This Ribbon dividend significantly improved the ability to market the product as both new and improved as well as getting more out of what was viewed as underutilized.

The team also set out to quantify the results of the Ribbon. It would not be enough for us to simply feel good or just know. The usability team explored every aspect of the design in our test labs. Hundreds of tests were conducted at the most micro and macro levels.

TBriggs on the user research team repeated earlier eye-tracking studies over the course of development, revealing how much less tiresome it was to find features. The deep red blob of eye-tracking marks was replaced by a calm and ordered browse of the Ribbon. Subjects left tests talking of how much less stressed they were using Office12 compared to the previous releases and how much less time they felt they were blindly searching for what might work. In general, people expressed much more mastery of the product rather than confusion or frustration.

Any change comes with a cost. While we knew learning would take time, encouraging news emerged. After the one- to two-week learning curve that caused diminished productivity, there was a significant productivity increase. People created richer, more expressive (and more modern) documents in less time. The increased use of the product translated into better work outcomes and more success with the very work they intended to do. This went beyond fancier documents, too—people created documents for a reason: to persuade, deliver bad news, sell products, run projects, and more. Doing so more effectively was a huge benefit to the information worker, even if economists were not able to measure this for a generation of PC users.

We loved the Ribbon.

By the fall of 2005, about 18 months after Vision Day, we were ready to show the work to the world, or at least beta testers.

These early adopters would have some feedback for us. If we expected them to simply fall into line and cheerlead, we were mistaken.

On to 081. First Feedback and a Surprise

A common belief in big companies with resources to spare is that innovation works better when there is a competition between multiple efforts with the same goal. It is a luxury most companies don’t have. If you’ve lived through competing designs, then you also know this is a horrible way to innovate and it is odd that such a process persists. When we began work on the redesign of Office, we wanted to iterate over designs quickly while also making sure we had multiple perspectives. It was not competing designs per se, but it had many of the same tensions. It was only through careful management that we ended up with a better design because we had multiple efforts early on.

Back to 078. A Tour of “Ye Olde Museum Of Office Past”

Microsoft always maintained a competitive culture. It started at the top and flowed down from there. Any doubts, ask one of the early morning basketball leaguers who played against SteveB.

Generally, one place we did not compete was on products. That was wasteful. To be sure, cookie-licking had a way of making it seem like there was competition, but those involved knew the reality. We’d seen IBM intentionally set groups after each other and it was ugly. Back when I was technical assistant, I had a call with an IBM technical assistant (a very different job it turns out) who asked me about how the company managed competing groups “so effectively” he said, and I thought he was speaking a foreign language (later I would realize from his view he thought of OS/2 and Windows as competitive, but we didn’t quite see it that way).

While competition rarely occurred across groups by building the products that were addressing the same goal, at times it happened accidentally, such as when C# and .NET evolved to bump up against Visual Basic, or even NetDocs taking on email after starting from a word processor. There were also technology transitions resulting in a current and forward-looking product, such as Windows 95 and Windows NT, which was not resolved until Windows XP. Originally Windows NT was a server operating system, but over time it became abundantly clear it was the future general-purpose operating system.

The Windows competition was painful. It was not particularly secret, but once NT went from a side project to a real product and then to the strategy it is fair to say the competition was difficult on all involved. No one who went through that would ever think about having competitive groups on purpose. At least if we did, we gained lessons in how we might go about it. The resolution of this situation was painful for everyone.

Microsoft’s culture was to avoid being wasteful of resources or internal energy, and to focus on one solution, getting to market, and iterating to get something right (in three versions or so). As we’ve seen when confronted with intentional redundancy, we typically dealt with it before products got to market. If there was a competition, shipping first was one way to fix it.

Many companies, like IBM, famously maintained cultures of competition. Often these companies sent two or more groups off to build solutions to a specified problem, frequently unbeknownst to each other, hoping a clearly superior solution emerged. For an engineer, that was an immensely frustrating approach and rarely resulted in a clean win. Executives had a way of looking at competing projects and determining that the best path forward was to remove the negative attributes from both choices and use the good from each. That forced merger of two formerly competing groups usually marked the start of a long, friction-filled journey to market. Worse, tell me the boss of the new merged effort and I could tell you the winning technology. Such was another reason to dislike that approach (incidentally, one thing we got right with the Windows 9x/Windows NT era was in moving code from one to the other).

The task of redesigning Office to address the challenges described was so high risk and difficult that it seemed sensible to try a few different approaches despite the difficulties of doing so. The questions were how to quickly try multiple designs and if one team could sincerely experiment in an unbiased manner.

The user interface was one part of Office12. The next section will outline the full scope of the release.

Julie Larson-Green (JulieLar), leading the UEX (User EXperience) program management team reporting to Antoine Leblond (Antoine), settled on investigating two approaches in parallel. Julie knew she wanted to experiment but was acutely aware we did not have a year to wallow in design alternatives. We shipped Office 2003 at the end of the summer 2003. We needed a couple of months on the engineering side to release worldwide products, refit the engineering process with improvements, and to plan on the next release. The rough schedule called to start coding for Office12 in early spring 2004. Less than six months to have a firm feature list, a robust engineering plan, and above all a new cross-Office design framework for a product used by hundreds of millions of people over the past 15 years. That’s all.

Julie’s Office 2003 team began iterating with designs before the release finished early in the year. The second design came from members of the team that moved over from Outlook in the late spring 2003. Movement across teams between releases was encouraged and planful, with program management starting moves a couple of months before RTM. Our resource realignment or reorg process was routine at this point and began uneventfully with a memo from me in late May 2003.

The two groups shared the same hallway with knowledge and awareness of each other, like OneNote and Word previously. JulieLar’s leadership on this project across all of Office would prove immense. Her own evolution as an engineering and product leader set the stage for this project, starting from when we met at a C++ event at Microsoft Press more than a decade earlier, through her growth to leading the engineering team that created Visual Studio (an outgrowth of single-user Visual C++), then on Windows through the chaos of the browser wars, and back to Office to FrontPage and the incubation of SharePoint Team Services, and most recently to the shared user interface team for Office 2003 (then called UIS). While decidedly among the best product leaders at Microsoft, it was her natural skills at bringing teams and people in conflict together that would prove to be the magic behind this risky and complex challenge.

The two teams were each staffed by very solid product leaders with strong but differing views on the evolution of user interface. The teams started from different constraints or assumptions. Julie aimed to arrive at one clear choice, not a nonexistent mix of two options or a committee compromise. That way the designs and specs could be finalized in time to start coding.

Few outside of Office fully understood the scope of the product’s thousands of features—the prevailing view was neither could anyone nor did anyone care about all of the features. While we (in Office) could light-heartedly make fun of our 4,000 different commands across five main products, with very few exceptions there were no other products out there that had such a surface area. The only thing that came close was the Adobe suite of products and perhaps Visual Studio, but both of those were used by professionals who were specifically schooled in those products. Even big web sites on the internet were no more complex than the online help for Office. Recall during the most recent redesign of the Office user experience (the introduction of command bars for Office 2000) we had a full-time program manager just keeping track of all the commands, buttons, and keyboard shortcuts. This was a huge redesign, a jumbo-jet cockpit level design.

The world-wide web introduced an entirely new metaphor to the world with blue underlined hyperlinks, big buttons, and a good deal of text. It was a radical departure from overlapping windows, menus, dialogs, keyboard shortcuts, and all the other widgets described in the previous section. A key question for Julie was should the web influence the new user interface for a productivity tool as expansive as Office?

One team was heavily influenced by the early design directions of Longhorn, the next release of Windows, which was at that point two years into its somewhat interrupted schedule due to Trustworthy Computing. Longhorn was starting to feel a bit of mission creep. Working to extend the traditional Windows desktop to incorporate weblike metaphors, the Longhorn design wanted to achieve the feel of browsing web pages while launching programs and working with files and settings.

The resulting designs made extensive use of textual descriptions and a task-oriented interface. Rather than verbs such as Save or Bold, the experience was much more like shopping on the web with categories like Collaborate, Share, and Edit. There were even command favorites (favorite commands?) and history like a browser, as well as buttons and menus within a wheel of commands, sometimes called a radial menu. A radial menu, a favorite of designers (and in movies), seems to surface every 10 years or so even though it has a host of problems with scalability, discoverability, and general ease of use. It also happened to be quite popular with the fans of pen computing.

One of the consistent challenges the Windows team faced was designing a user interface paradigm for all apps developers without themselves really having an app to design. The desktop, managing files and folders, launching programs, and the control panel are interesting but relatively minimal in scope (says this apps person). As discussed in the Windows 3.0 era, Windows benefitted enormously from the Excel team’s input into what was required of Windows.

The first Office team’s design, called OfficeSpace, felt futuristic—graphically it looked like something from a movie. The name derived from the generalized notion of a command space from Longhorn and happened to (perhaps by no accident) reflect on the 1999 Mike Judge film Office Space that quickly achieved cult status among Gen-X. It aligned with a stated direction of Longhorn, which was quite appealing. Alignment between Windows and Office was always viewed positively, especially by enterprise customers, even if we didn’t always deliver on the details. In early 2000s, aligning with Windows was still a prime directive from BillG. We had just managed the impossible, which was to ship Office XP and Windows XP in rough proximity and the XP desktop would rival the 2000 desktop in excitement from field sales.

The OfficeSpace team created a high-fidelity interactive prototype called Strawman. It had a feel of Longhorn with a good deal of text in the interface describing commands in a command well that was like a taskpane. It also, however, featured traditional toolbars and menus. It was a strong design, but it felt additive to what we already had. The incremental addition of new affordances was described in the previous section and was how we ended up where we were in the first place.

The second team took a clean-slate approach. They started from the problems Office customers faced, rather than starting from a design language or set of abstract principles. The first thing they asked themselves was, “Why are things the way they are?” This simple question frequently proved liberating. Leading this questioning were Jensen Harris (JensenH) and Clay Satterfield (ClaySatt), both of whom joined Julie’s team from Outlook, fresh off its complete and successful redesign. JensenH insisted on trying something entirely different. Julie gave him that latitude. Jensen brought with him a depth of Office product knowledge that far exceeded his tenure at Microsoft, something that was an absolute requirement to making this project work.

Jensen and Clay asked themselves the “why and what for” of the top-level menus: File, Edit, View, Insert, Tools, Window, and Help, along with the many widgets. It became clear to them that product history was no longer relevant. A button that was a hot new feature a few releases back, or that a program manager insisted upon long ago, didn’t necessarily have a place in this version, nor did the widget that was added in an effort to make finding a command easier. Despite a deep understanding of what we aimed to do, those designs were rooted in the arbitrary history and evolution of the implementation of Office. This is why the history of Office as detailed in the previous section was such an important input to this design.

Taking a step back, as great product designers often did, the team concluded that features could be grouped in a much more systematic and logical way and, more importantly, by operations that were more familiar and easily labeled for human use. A reorganization was needed more than “pixel pushing,” as HeikkiK used to say. Imagine the level of boldness required to suggest moving not just a few but every command in Office. This sounded like “Who moved my cheese?” on a grand scale.

Julie let the process run for a bit more and then it was necessary to drive towards a single unified design. She was determined not to simply pick a winner herself but work a process so a shared winner would emerge. This was brave and not the norm for Microsoft. She essentially told both teams to lock themselves in a conference room and arrive at a shared result. There was a risk of compromise or design by committee, but she knew that going in and wasn’t going to let that become the result.

The teams hated this, as they should. It is exactly what no good product designer wants to do. As expected, there really wasn’t a compromise. This did in a sense force Julie’s hand. The purity of the latter design was great, while many questions remained about Longhorn’s text-heavy approach. At first Julie finessed the choice, but it is fair to say even years later that at that moment there were those that felt like they won and those that didn’t. Perhaps there really is no alternative with competing designs. The designs, however, gave us all much more confidence in the direction, having fully explored two radical alternatives.

Over the course of the next few months Jensen, Clay, and team created many visualizations. They created hundreds of prototypes. JensenH estimated that over 25,000 renderings were created. The teams used every level of fidelity from paper to PhotoShop to Flash (yes, that was still a thing).

Why did we have so much confidence though? Who makes such a huge change to such successful products? The user interface was the product and “who moved my cheese?” could result in an unmitigated nightmare for end-users and a disaster for the business.

Early in the process, Jensen’s team design centered on a small number of important concepts—concepts that provided an enduring framework for how the interface should be designed and evolve over time as the product expanded. Starting with PowerPoint, they sketched out a design that reflected their set of principles. Envisioning a design where each app had a dominant color consistent with the app’s existing icon, the sketch of PowerPoint had a ripe red tone, and so they dubbed the initial design language Tomatoey (tom-ah-tooey), because it was a tomato-ish user interface. Get it?

The original renderings were compelling, albeit a bit too colorful. The work was unbelievably impressive. I often stopped by their offices in our shared hallway to see the designs evolve and hear what they were up to, especially in the evenings when they seemed to work best. Jensen was still new to the team, and young, and he was a little leery of my walk-bys, but he and Clay were both often working in the late afternoon or early evenings, the best time to chat and see updates. These discussions continue today except they happen over text and we’re talking about the WWDC or latest hardware. I can say without hesitation that I had not had more interesting late-night conversations about technology since my days of AFX and talking to RickP about the early code in Excel and Windows. To be honest, given the risk of the overall effort, these conversations and talking to Julie and Antoine almost every day were part of my own risk mitigation therapy.

Tomatoey was the kind of design that people tried to poke holes in and find problems with but just couldn’t. It was not just a rendering or a rearranging of the commands—it was an entire system and framework for how the product could exist and evolve. We were still very early. When you listened to Jensen and Clay go through the thinking and when they showed demos it was abundantly clear they were onto something. Normally when a design is early and one asks questions, the answers can be vague or bring on a feeling of unease. In this case, it wasn’t just that answers exuded confidence, but the answers were often more thoughtful than the questions.

Too often the graphical aspect of software designs over-shadow the key tenets of functionality. We see this today in how designs so often start with or are communicated via graphics, or widgets, versus the problems solved or functional aspects of the solution. Even the names chosen for designs too often reflect graphical or aesthetic choices in the work such as Aero or Luna.   

I asked Jensen how serious they were about this design and he said, “Very serious. . . . We really went whole hog.”

Everything had a place, and there was a place for everything.

Even at this early stage there were a set of widgets or controls as the operating system called them. It would be easy to define the design by these mechanisms, but that would be incomplete and miss the whole point.

As with any great design, there were a small number of concepts reused with a clear set of rules. From the earliest days of the design, Jensen and Clay had a full framework and rationale for every choice, across every Office application. Early on the choice was to focus on the three main document creation apps, Word, Excel, and PowerPoint. The omission of Outlook proved to be frustrating for reviewers and those measuring us on consistency. Other document applications were pleading to get the new interface, but the need to focus was paramount.

The design was sweeping and all-encompassing. Considering the scope of the design this was an incredible accomplishment. Almost every system redesign I can think of started from a single dimension or metaphor—transparency, control palettes, a new command hierarchy, or our own command bar idea. The very notion of the first principles of Tomatoey was itself incredibly significant. As a reminder, the scope of this design was 4000 commands across three major products each used by hundreds of millions of people for some of the most critical work of their professional lives.

Jensen referred to this as a results-oriented design. The crux of the design was to pivot from thinking about individual commands and where they should go to planning the results of the document creation process. The design presented aggregates of commands at a higher level. The original bullets and numbering toolbar button in Word 6.0 was an early preview of this sort of approach, synthesizing a feature out of many commands that already exist in the code. Features are illustrated by results they obtain, not by a name. Instead of a Chart Wizard, illustrate the charts that can be created and do so using galleries. Users are far more likely to get the end-result they want by getting to an approximation quickly and then using visual choices to further customize it.

While the interaction design was one aspect of this work, and in general we tell stories about Office from the user to the feature choice and design then to engineering and quality contributors, I would hate for readers to think that I am failing to account for the immense impact of software engineering and testing to this work. As talented as JensenH and the whole PM and product design teams were, they had their match in equally talented engineering counterparts. They worked side-by-side at every step of the project—there was no handoff, but a crazy amount of iteration every day of the project. JulieLar’s peer in development Dave Buchthal (DaveBu) led the development team. He started at Microsoft in 1992 and was an early member of the Office Shared team. Igor Zaika (IgorZ) was a development lead reporting to Dave and an informal tech lead for the project who also had more than a decade of Office development experience. Sean Oldridge (SeanO) led the testing and quality team, putting his decade of experience to work. The engineering, not just on the code to implement the design but the high performance and backward compatibility across Word, Excel, and PowerPoint, represented the most intense re-engineering efforts the entire Office team ever attempted, even to this day. I hope all the design and feature discussion doesn’t take away from the engineering and quality aspects of this project.

The purpose of this section is not to be a tutorial on the design, as much as I would like. There is a 2006-era blog (this will be described in a future section) as well as videos from JensenH’s various conference presentations that are available online. Many are linked to at jensenharris.com.

When it comes to saying why the early design seemed so good, I would say was it a new reality where the Office user interface engaged users in a much more captivating way and users could see their work coming to life versus debugging the document. Capabilities existed in only one place and never moved around—and at the same time every feature was accessible by an equivalent (to Office 2003) or less (!) amount of command distance. Gone were the days of tunneling into dialogs or playing hide-and-seek. Embracing web paradigms, the design took advantage of longer, more conventional text labels (longer than tooltips) and a livelier interface that showed the results of a command even before choosing it, enabling users to pick from choices like a modern sketch artist. The design even took up less space and worked on a wider range of screens consistently. The focus was on features and results. Going back to our cockpit analogy, the design essentially programmed the capabilities of Office rather than just putting a bunch of mechanisms out there to find commands. It was radical. It also worked extremely well.

They called the design the “Ribbon.” The team described the design as visual, tactile, and responsive.

The Ribbon seemed not only to solve Office’s bloat challenges but to create an interface paradigm that would be the best, and most enduring, design for the desktop era. While we were normally optimistic before we began coding, it was rare to have this level of enthusiasm so early in a project. There was something special about what was transpiring, even with a list of issues that continued to grow.

Still, we only had the early design for the Ribbon. We needed to finalize that and an entire release of Office to be built by a few thousand people.

On to 080. Progress From Vision to Beta