Hardcore Software by Steven Sinofsky (Audio Edition)

Welcome to planning Office10 and going inside the strategy, synergy, unification engine that characterized the early 2000s Microsoft (beginning in late 1998). This is a beefy post (too long for email) and even includes an embedded PDF (a new Substack feature 🔥) of the entire Office10 Vision document.

This post is not paywalled. Perhaps consider sharing it with friends or coworkers. 🙏

Sync with Windows 2000. Sync with Whistler (the codename for Windows XP). Sync with Windows Server. Sync with Exchange Platinum (codename for Exchange 2000). Sync with Exchange Titanium (the one after that). Sync with SQL 2000. Sync with the one after that that didn’t even have a codename yet. Sync. Sync. Sync. That was what we heard from every corner of the company when it came to building the next release of Office. Sync wasn’t just about schedule. Sync implied deep strategic connections in the code and user experience—it was all about product synergy.

A remarkable accomplishment of Microsoft’s earliest days was entering all the major lines of software at the time. In a c. 1981 video produced by Microsoft, “A Hard Line on Software”, the company touted its product line.

A full line of system software not just one or two products, and all of our products are designed to work together…a full line. Microsoft products cover all three areas of system software: languages, operating systems, and end-user tools.

Microsoft’s core DNA was having products in all the major areas of software while also committing to products worked better together. This was BillG to the core.

By the late 1990s, Microsoft had spawned two businesses greater than $10 billion in Windows and Office and breaking those down further one could find multiple businesses closing in on $1 billion in revenue from Visual Studio and developer tools to the various servers such as Exchange and SQL to the new business of MSN and games. The breadth part of the DNA was firing on all cylinders.

The other part of our DNA was proving to be more difficult and at the same time the demands for products to work together were only increasing. This was happening as product complexity skyrocketed and the predictability of product releases was not improving. More importantly, each of these big products began to have significant overlap: Exchange and SQL, Basic and C++, Word and Publisher (and anything that edited text), Excel and the Access database (and Visual Basic), Internet Information Server and Windows file server, and the list goes on and on. Mind you, the overlap was not entirely obvious to most as the market clearly saw these as different products. Inside Microsoft, however, the overlap was at some deep architectural level worthy of debate and ultimately synergy and unification.

As enterprise customers came to dominate the business, strategy was no longer just about features. Strategy was how products were deployed, managed, and integrated into business scenarios. Something entirely clear at a usage level such as e-mail, a database for line of business data, and file storage became a galactically hard strategy problem when customers wanted to deploy and manage one scaled “place to store data”.

The technical leaders of the company spent most of our executive time on the collisions between products when it came to deployment and management and the seams between them when it came to user-experience and scenarios. Having more than one way to do something or failing to have clarity in prescriptive guidance to the field sales organization was reason enough for a big meeting or offsite.

Call it what you will, synergy, strategy, unification, consistency, or simply efficiency were the key attributes everyone was to aim for. It was assumed achieving this was part of the schedule, though this operational aspect was almost never discussed or even challenged. Unify was definitely BillG’s favorite way to describe his goal.

For better or worse, those of us with our experience in Office made oft-repeated calls that synergy comes from synchronizing ship dates across products. Surprisingly it seemed to have sunk in now that a big wave of server products (Windows 2000 and the 2000 servers) were nearing completion. So now everyone wanted to know when the next Office was shipping and importantly, would that date align with what they were planning on for the next releases. Such scheduling was of course impossible. Not only was no one in the company hitting ship dates but having any two groups first agree on a target and then hit that target was akin to bullets colliding mid-air downrange, on purpose. Important here is that we’re not talking about new groups or small teams, but massive billion-dollar products and customers spending tens of millions of dollars per year on their Enterprise Agreements. Each of the product teams approached 1,000 people at this point. The scale was immense.

As it would turn out and much to our collective surprise, the next releases of both Windows and Office (the releases being planned in the timeframe of this chapter) would in fact hit their target ship dates. Both of our teams came to the exact conclusion, independently, in the heat of synergy overload—shipping was all that mattered. Windows put in place a plan to add all the key consumer support missing from Windows 2000—the last features that remained from the 16-bit code base—along with a broad range of features and technologies from around the Windows team. This plan was codenamed Whistler, nominally named after the Canadian town and ski resort favored by many Seattleites. It was both remarkable and commendable to see this little part of Windows carved out and allowed to be, given all the strategic initiatives going on. To be honest, for most of the time we were working on Office it always seemed like the other shoe would drop and the product would slip. In hindsight, that was probably unfair. On the other hand, it might be the first release of Windows to ever ship on time.

In Office we were smarting from the lukewarm reviews for Office 2000, despite the groundswell of support from our enterprise customers for the complete Desktop 2000 that was just starting to deploy. Knowing that most customers were just beginning to deploy we could have taken out time with the next release, but I felt a strong need to get back in the market with end-user appeal and to bring some focus and attention to innovation in productivity and of course the internet. There were still deep concerns about the potential for relevancy of Office in an internet-centric world.

All this pressure about synergy and synchronizing pushed us to start planning for a new release in the summer of 1998 which turned out to be seven months before finishing Office 2000. My reluctance to even provide a code name, which would then probably leak, excite the field sales force, make it into the press, and so on, caused me to plainly title the memo “Next Release of Office”. Cleverly, the team immediately took the code name of the release to be the ambiguous “NRO”. I admit it now, but I kind of liked that. Security by obscurity. In short order the team started calling the next release Office10, because it was the one that came after Office9. That was good enough for us.

There was much we could focus on. There was also a great deal of low-hanging fruit we could pick off in terms of enterprise customers. This was in practice our big challenge. How can we find a way to balance all the various forms of feedback, knowing that the bulk of revenue came from enterprise IT, but nearly everyone sitting in front of the product for hours per day were just regular people? In NRO I wrote the following, accompanied by a fancy new OfficeArt diagram showing the full spectrum of feedback.

Getting the right kind of customer feedback integrated into the product is always a challenge. As Microsoft has grown the bias has been towards fewer people interacting directly with customers and towards over-representing the feedback from large and vocal customers. The following picture illustrates the current paradox for getting the right kind feedback. Today we tend to over value and over-practice customer “feedback” that is actually more valuable to the customer as pre/post-sales support than it is valuable to the product team during the design phase. This is not to say we should not practice things like EBC visits, or one-to-many presentations like the Global Executive Roundtable, but we should consider them for what they are which is a self-selected and large company focused effort. The more inputs we gather from the right side of the diagram the better off we will be at understanding the true problems we are solving. One way to consider this spectrum is that the left side of the diagram is where our decisions are validated and the right side is where ideas are elucidated. Despite the pressure in the company to focus on one-off customer contact from LORGs, we must not lose sight of getting the right feedback through the right mechanisms.

The competitive landscape remained clear. Our number one direct competitor remained previous releases of Office, and for enterprise agreement customers it was the still not deployed versions of Office customers already owned. To make this point clear, the memo detailed the fact that we could never ever again change the file format:

We must not lose sight of the fact that our biggest competitor continues to be our existing products and the inertia they have. The cost and pain of upgrading still overwhelms any sense of benefit we seem to be able to communicate to customers. We learned that if we ever change our file formats again we can kiss the upgrade good-bye. Literally no one will ever upgrade if we change the Word and Excel file formats-I hope that fact is engrained in everyone’s thinking. We must always consider the major competitor to be the Office release that is already deployed and running.

It became increasingly apparent that our competition would be new tools and new ways to be productive. In detailing the competition, NRO described a new category of products known as virtual office. These products were web sites that promised to have all the files and other interesting project information readily available from anywhere on the internet from any PC with a browser, primarily focused on collaboration. Somewhat related was the new area called software as a service (a surprisingly early use of the term) which aimed to provide similar functionality but to offer it as a pay-for-use license hosted by an internet service provider or partner. Already the industry was split between on-premises and what would eventually be called cloud computing but known as hosted or sometimes application service provider.

Virtual office products. The area of virtual offices has garnered a lot of attention for both small businesses and large corporations. These products such as eRoom, IntraNetics, Netopia, Vista allow for group collaboration over a web site. They can be thought of as both software and a service and it is the fuzziness between the two ends of the spectrum that make these products interesting. In terms of the product, the need for teams to organize and create “places” for the work and results to live is not new, but the web makes this a more immediate need with a much clearer solution for customers. Everybody can imagine a home page for their project, but few can imagine how to create one or keep it up to date.

Software as a service. The virtual office products are also offered as a service. Two that have received a lot of attention are HotOffice and Visto. Today these are all tend to focus on integrating Office’s binary file formats and thus leave out the innovations in Office 2000. These services are clearly the value add that people are looking for-how can I share my files, how can I backup my important information, how can I have a secured customer relationship, etc. Another perspective on software as a service is the role of very targeted web sites that allow customers to create certain types of documents. For example, if you visit the Kinko’s web site they have a multipage wizard that walks you through creating a draft of a resume that a Kinko’s representative will then fully typeset for you. It is not hard to imagine an array of services like this perhaps all being offered under one umbrella at AOL for example.

Over the subsequent months a growing set of program managers, then developers contributed to creating a product vision. The processes we used for Office 97 kicked into gear with much less fuss. There was almost no fuss at all. The lessons of building a team by forming, storming, norming, and performing were apparent.

That was within the Office team. Outside the team, it was proving much more difficult to arrive at a strategy that worked uniformly across the company. Partnering with one group would leave out a competing group. Aligning schedules with one product would preclude alignment with another. The crux of this alignment challenge was the server infrastructure which was also the lead dog in talking strategy with IT professionals. The constant pressure for one single answer, one product, one solution flew in the face of our disparate products, schedules, and technology approaches. And most of these did not align well with the rapidly expanding internet.

Every product was in early days of developing an internet strategy and was looking to develop that strategy by connecting to Windows or Office in order to design, develop, validate, and then distribute the product or more likely portion of a product such as APIs to be included as code shipped with Windows or Office. Across the company groups were always asked what work they were doing with Windows and Office. And Windows and Office were asked what they were doing with each other. The goal seemed to be to connect every team to each other team—just as we had joked about a few years earlier.

When it came to the internet, our Office strategy was to use HTML for Office files so they could be viewed in any browser, connecting to internet services for content like clip art and templates, and sharing files and collaborating with the web server tools based on FrontPage, which became Office Server Extensions which were implemented using standard web extensibility. We planned on an expansive role of the server extensions to build an “Office server” as we called it, a one-stop shop for all the collaboration needs for typical Office users. Many across the company looked at these technology bets and felt they were too open or did not represent a truly better together strategy with the rest of Microsoft, servers that longed for a world of tightly coupled and proprietary integration, while always promising a bit of openness. Enterprise customers were extremely skeptical of new internet technologies, viewing them as woefully inadequate for hardcore enterprise needs. Internet technologies were simply too immature, almost toys, compared to the industrial strength products the enterprise was just starting to deploy such as Windows Server, SQL Server, and Exchange.

Integrating with those servers epitomized this conflict—Exchange for email, SQL storing data, plain old Windows server for files and web serving, and even Internet Explorer connecting to those servers. BillG would constantly ask how there could be exactly one copy of a file on a network, no matter if it was mailed, used in a database, or stored on a team file server, not to mention a new web server. SteveB once cornered me in the cafeteria (this happened often) and scrambled to find something to write on (and settled on one of his business cards) to draw a picture of all the places he needed to look to find out “tell me what’s going on in Microsoft France” and begged me to solve the “where do I go?” question. This problem persists.

While we were busy pondering unification, customers were making long-term, strategic choices and there was a zero-sum, win now or forever lose information infrastructure being laid down in corporate America. A loss to Netscape, Oracle, Sun, or IBM/Lotus was not just a loss for the quarter, but almost certainly a loss for a decade. The stakes could not be higher and Microsoft was playing catch-up.

Pondering pure internet technologies could be construed as evidence undermining the goal of winning with integrated products. That is a dramatic way of saying what was going on—everyone wanted to build great products, but what defined great had many dimensions.

Many in the industry loathed proprietary approaches but at the same time sought the prescriptive and coherent strategic value a partner like Microsoft could provide, especially in a time of rapid change such as the internet was foisting on CIOs. The chaos of the internet was far more concerning than keeping promises of openness. In fact, there were clear signs that the standard-bearer torch was handed over to Microsoft from IBM and customers were seeking out Microsoft’s guidance on how to implement IT. We were happy to oblige, just as we had hoped at the 1993 offsite where we role-played a world after IBM.

To most of the world of Fortune 500 CIOs, Microsoft was being looked to as a place of comfort and reliability, in a chaotic world. Microsoft had replaced IBM as the safe bet to make and many of the new generation of CIOs were betting their careers on Microsoft’s strategy. The dividends of this change continue to pay off today.

Exemplifying this was the web server skirmish brewing between Windows and Linux—ground zero in the war over proprietary versus open-source software. This put Microsoft’s soup to nuts approach to building web server infrastructure and tooling up against the chaotic but customizable and fast-moving Linux (and Apache) server community. In the first years while the web was being built out, Microsoft gained mindshare and product traction. Over time, however, new technology layers that were being used by startups and the broad public internet came to dominate. Microsoft ultimately lost the server battle with Linux, in the short term for web servers and in the long term when it came to the operating system for the cloud. Customers might say one thing in the short term but over time competitors often acquire the attributes that appear initially absent as early adopters iterate and build out a more complete and cohesive solution. As we will see, complexity was also a key culprit in our loss.

Competition between IBM/Lotus Notes and Microsoft Exchange was intense because of the millions of dollars at stake, but more importantly the winner was certain to cement email infrastructure for decades. This latter epic battle came to define Microsoft’s enterprise culture. In hindsight, winning was also the defining product win for Microsoft in the enterprise—Exchange became proof of Active Directory and Windows Server, and with those pulled the whole client/server compute win to Microsoft. Client/server architected in this manner was relatively short-lived as the web dominated, but the long tail of the Exchange (and Outlook) win paid off for a generation. Even Microsoft’s future in the cloud with Office 365 was anchored by Exchange in the cloud.

Email infrastructure was slow to move, the battle having started five or more years earlier. Beyond just email, IBM successfully continued to raise the enterprise discourse from email to knowledge management, consultant-speak for the kind of work done by most PC users that involved writing, analyzing, presenting, collaborating, and sharing information primarily with email and Office. IBM did a better job positioning Notes to use Office than we did using Exchange and Office, except for the role of Outlook. This battle was far from over. With Exchange a peer to Office in our organization, Exchange became the right answer for anything to do with collaboration—right with customers, the field, and product groups. The implication was that the web and HTML were decidedly wrong. Also, using SQL Server or the Windows NT file server was the wrong approach. Storing data in Exchange was the most strategic approach. Technically, however, it was way off base.

As was too often the case, the Office team found itself in the middle of internal strategy debates. While no one could dispute the importance of competing with Notes, how exactly to compete was at issue for the Server and Tools teams. Many of the server and database thought leaders, such as David Veskevitch (DavidV), believed strongly that competing with Notes meant using a real database not an email database (whatever that meant—a debate itself). SQL is an industry-standard for databases—literally every major computer system in the world (financial, retail, customer service, etc.) was built with SQL, usually from Oracle and sometimes IBM, but not yet Microsoft. Winning the SQL market was as important to Microsoft’s future as winning Exchange.

In other words, Microsoft enterprise server strategy required winning in both Exchange and SQL. There was an elegance to SQL architecture and scale that most found quite appealing. Others were equally attracted to the flexibility and lack of forced structure that email provided. BillG was a big fan of SQL, something that remained true for a long time. Not surprising, what Notes accomplished, through the brilliance of Ray Ozzie’s architecture, was to develop a storage system that was a unique combination of attributes of both SQL and Exchange for storing data—called an object-oriented database, which by coincidence was what I had studied and built in graduate school. Because Notes was a hybrid, it landed squarely between the Exchange team and the SQL team, who routinely debated the merits of their approach at achieving competitive parity with Notes. Caught in the middle was Office, which was constantly being evangelized to support one or the other for the collaboration scenarios, and mostly to validate one product over another. In Office, however, we saw the choice of where to store data as an important implementation detail irrelevant to customers compared to solving the collaboration scenarios that were top of mind for us.

While this saga continued for 10 years at Microsoft, the first couple of years into it, Office made at least one wrong bet. There was a strong desire to see Outlook support SQL to store email, something Exchange did not yet do. At the same time some suggested using Exchange to store Office files for collaboration, something better suited to SQL as was done for the new OSE. In other words, it often seemed what the Server teams wanted was for us to do everything twice. To avoid going further into the weeds, I’m leaving out the fact that Outlook used only Exchange, and Excel and Access connected only to SQL. We frequently met with both teams trying to arrive at plans to unify in some future release—they were anxious to have the distribution of Outlook driving the use of and validating their server. To those readers deeply familiar with Microsoft’s developer API strategy for data, the parade of data access APIs (ODBC, DAO, ADO, CDO, RDO, OLEDB, ADO.NET and more) were a symptom of this unification fiasco.

Outlook was the team that seemed to do everything twice. Making email, calendaring, scheduling, and more to work with Exchange consumed the team for almost six years and it was still fragile and unreliable. When it came to broadly competing with the IBM message of knowledge management, Outlook plus Exchange was not competitive with Notes because it was not a full database platform to build applications like expense reporting or information tracking solutions. To build those applications, IT needed a SQL database and it needed to be both on the Exchange server and on desktop Outlook—that symmetry was the Notes innovation. Since Exchange server did not run on a desktop (nor was it SQL) a new Local Information Store was being developed—yes, that same project from Office 2000 was revived to become a key part of Office10. Local because it ran on PCs (versus a server, which was remote) and Information Store referred to data storage, abbreviated LIS. LIS would finally make it possible for Exchange and Outlook to compete with Notes.

Still, we had to write down what we were going to do. The process for building a product was now something of a cultural touchstone for the Office team. The next step for us was to develop a product vision document—a list of priorities, a set of scenarios, detailed value propositions, and above all a schedule.

Input and strategic direction like this led to a complex and gerrymandered Office10 vision, which made it seem like we were doing everything twice. I felt stuck. The foundation was moving under us, whether it was Exchange or SQL (or Windows NT file server). Collaboration, however, remained a key strategy bet for Office. The Enterprise Agreement selling motion required synergy and strategy across all of Microsoft, which ran right up against the Office view that customers just wanted things to work. A key challenge with strategy and unification is that most of our competitors did not have all these assets to coordinate and unify, making customer choice seem easier and more often than not the products seemed less complex. Little did we know directly, but at the time IBM was pushing this same level of unified strategy on our primary competitor, Lotus Notes. Over time, the Notes team found itself deep in execution challenges because of strategy initiatives.

In order to write the vision, we found ourselves pivoting the whole collaboration message around choice—customers could choose the infrastructure that worked right for them in their environment. Customers and industry analysts loved this kind of message. Customers always love choice because it is the opposite of lock-in. Industry analysts love choice because it creates an opportunity to help customers untangle the messy strategies of vendors.

In reality, choice is confusing because competing products are no substitute for each other even if an analyst says they are in the same category or magic quadrant, the tools used by the firm Gartner to explain relative strengths of vendor strategies. Beyond that, and it should be entirely obvious, a strategy based on multiple choice is wholly unworkable. Given two options to do something, customers will create a third option composed of the best attributes from the options. That third option will be impossible to build and thus out of the gate the product will be unsatisfactory.

The choice in the vision became Office and Exchange for Corporate Groupware and Universal Web Documents and Web Sites. Customers with Exchange got what they wanted through Outlook, unless they wanted something universal (or they didn’t have Exchange) and they got the parallel implementation (that happened to use SQL Server). (Not) surprisingly, customers preferred something like a universal web with Exchange, which didn’t exist. This frustrated BobMu, so we incubated a third project to build web-based collaboration using Exchange (headed by the former head of Outlook development, Mike Koss (MikeKo), a pioneer Excel developer). It was not just words, but even within the Office product we were literally building many scenarios twice.

It was a mess.

A bonus in this post is the actual Office10 vision. This PDF is created from the HTML file (trivia, saved as an MHT file) that was made available to me.

The team lacked clarity, and my primary job was to provide it. Everyone was nervous going into the release because the main pillars were so sloppy. The gerrymandered concept isolated the work on each of the three approaches to separate teams. In private, I was fairly convinced that only one approach would ship and the web would win out, but could never have said such a thing that early.

It was messy for BillG, PaulMa, and BobMu as well—it was messy up the entire management chain. They were uncomfortable with waiting for the work to get done when the new Exchange and other new servers were so close to shipping. Seemingly out of nowhere, there was a strong demand for a different product plan than we were closing in on.

I was enormously frustrated. Like every product-centric person I wanted a plan that was well-defined, tight, and efficient. The idea of duplicate solutions or scenarios was the opposite of unification that we so strived for. I would come to realize, partially through many conversations with BillG, such a perfect plan was also fragile and leaves little room for failed execution. I needed to get comfortable with a product plan that represented a portfolio of ideas. On the other hand, such an approach meant during development no one was sure where we would land, resulting in groups working against each other. It felt Darwinian. I did not like that. We had a way to move forward, and I needed to get comfortable in my own role as leader of ambiguity.

Then one day at a meeting I got asked point blank if Office could do a quick release of Office to synchronize with the new Exchange followed by an even more strategic release later? Crazy talk. This would have put Office on the two-release treadmill that was so common in Systems, so it was a reasonable ask from that perspective, ignoring that the second longer-term release never seemed to happen.

For a team having sworn off the idea of doing parallel releases ever again, this was a nightmare. For the execs, this type of planning and doing parallel releases was normal. It fell to me to somehow demonstrate that the second of the parallel releases never happened. While this was their culture, I felt a personal commitment to defending the, and now my, Office culture. The next Exchange scheduled to finish soon did not ship until months before the planned schedule of Office10 but spent most of Office10 trying to finish and unable to do new features that might help this strategy. The other servers were also late.

I spent most of the release defending our schedule.

To counter the complexity, the vision included concrete areas, each to be stewarded by the appropriate leader on the team. Of note were two somewhat classic investments. First, everyday tasks made easier through innovation was our catchphrase used to get back in the personal productivity game—repayment for when I made “Personal Productivity priority number 6”. In this area, AndrewK led the charge across the apps in toning down our approach to automatic features that got a bit out of control (the Smart Menus in Office 2000 that moved commands around unpredictably) and broadly adding a new user interface to present commands right when needed without having to navigate menus and toolbars. Office10, for the first time, shipped Microsoft-developed speech and handwriting recognition, incorporating pioneering work by Microsoft Research. These generated applause in demos, especially when reviewers considered their own use cases.

Second, nailing the fundamentals was a broad focus on product quality. Our experience with Office 2000 was that rallying the team around total cost of ownership (TCO) was boring and difficult to measure, but Microsoft culture loved performance. We rebranded TCO as fundamentals and it became a bit more interesting. In truth, enterprise-ready deployment (including setup and more) became a fundamental business need.

As a sign the product team was maturing, we rolled out the Office10 Vision with much less fanfare, and angst, than Office9. We held a team meeting with prototypes and fast-paced slides from each of the leaders. Everyone on the team received a one-page printout with the key product plans and a mock press release announcing the availability of Microsoft Office10 on “3/2/01,” ushering in a product cycle dominated by themes of rockets blasting off. Antoine and GrantG signed up to land this release on time. Antoine, finally, moved over to OPU to lead development after successfully leading Word 2000.

We changed the structure of the schedule to have only two development milestones, each 12 weeks duration rather than three shorter ones. The complexity that it required to exit, and then enter, a milestone grew over time, and we felt we could get more done if people worked longer, and continuously. We built on a growing maturing of the organization that kept the product in a working state and continuously integrated new code into daily builds.

With the completion of the vision, AndrewK chose to focus on features for end-users and joined a newly created team to build worldwide internet-connected features for all customers, marking the first time we built features assuming an internet connection. Obvious in hindsight, but at the time we even came up with new wording on the product box to explain that internet connectivity with a modem might be required.

HeikkiK stepped up to lead Office-wide program management. His no-nonsense shipping sensibility and embrace of enterprise customers further solidified the intent of the product and the culture of PM.

Work began with an incredible focus on shipping. The intense friction across the team over the shared work in Office versus the apps largely receded. I faced a new kind of stress, and that was all the strategy going on across the rest of Microsoft.

The team finally graduated from storming and forming to norming and even performing.

On to 059. Scaling. . . Everything

Welcome to Chapter IX, taking place 1999 to 2001 where the world realized just how dependent it had become on email and the PC when viruses became a mainstream part of the technology vernacular. In the halls of Microsoft, it became apparent that being early was as strategically deadly as being wrong. PCs sell more than 100 million units for the first time in 1999. Things start to heat up on the antitrust front. We are learning to plan a release in the context of a massive change in the business of selling software to the enterprise.

Back to 056. Going Global…Mother Tree

Enterprise wasn’t just the direction of the business—it was the only business.

But could we listen to customers and still fail? That’s what it felt like was happening.

Office 2000 had become entrenched in the enterprise, if not yet deployed it seemed inevitable. In the process, we left end-users behind. Those concerns over too much enterprise focus that were pushed aside to make way for Office 2000 became front and center. From a product development perspective, we were failing in the reviews that we had been trained to want the most to win. Starting with “nothing in it for the little guy” to “thousands of features, some useful and most not” the product was not something end-users wanted.

Business results told an entirely different story. Most quarters our Office finance lead would come to a senior manager meeting and discuss the earnings announcement and put it in context. As a public company these discussions were not news, but at least helped the broader team to understand where the money came from (and how much we were spending). Each quarter of results had a new entry in the filings and disclosure that went something like this from Microsoft’s 2000 annual report:

At June 30, 1999 and 2000, Windows Platforms products unearned revenue was $2.17 billion and $2.61 billion and unearned revenue associated with Productivity Applications and Developer products [Office] totaled $1.96 billion and $1.99 billion. Unearned revenue for other miscellaneous programs totaled $116 million and $210 million at June 30, 1999 and 2000.

It would be an understatement to say that finance was almost giddy over the unearned revenue number. It was growing at a crazy rate and the numbers were billions of dollars. Sometimes it felt like the world’s largest rainy-day fund (even though Microsoft’s cash on hand was also astronomical) or that we could stop selling software and run the company on unearned revenue for a couple of years. The company came a long way from BillG’s founding principle of maintaining a full year of cash on hand to weather economic uncertainty.

Revenue was no longer as simple as how many copies of Office were sold. The turn of the millennium was about selling multi-year contracts for Office (and other Microsoft products, often all together). While Office for $100 or even $150 dollars per desktop PC seemed historically low, gone was the angst over upgrades. The largest companies in the world were buying our software for every PC and committing to keep buying it for the next three years, called an Enterprise Agreement or EA. It was effectively a massive increase in revenue per customer, in exchange customers received the full enterprise treatment of support, sales teams, strategic partnering and more. Those benefits were known as Software Assurance.

Wall Street had to find new ways to think about earnings. Instead of booking the revenue for one box of Office entirely in the quarter it was sold, revenue was formally recognized over the life of the contract (usually three years). Contractually the revenue was guaranteed, but accounting rules meant Microsoft had to wait to recognize revenue. It is easy to see why this is a good idea, as absent that we could conceivably have monster quarters only to fail to sell more products in the future.

This created a radically new problem for how we thought of the business. Microsoft created a virtual line-item unearned revenue representing all the future payments yet to be recognized. Instead of topline, Wall Street was now focused on the rate of growth of the unearned revenue. Very quickly billions of dollars from Windows and Office were piling up in the unearned revenue line item. Unearned revenue would convert to plain old revenue on a schedule based on length of the agreement and would be added to the revenue line of reported earnings. As quickly as these agreements took over, we had to change how we thought about product development.

Unearned revenue (almost an oxymoron, and certainly not a phrase coined by marketing) could sound like an accounting gimmick and was especially tricky for the teams in headquarters that had no real insights into pricing, number of agreements, or even the promises and terms. We only had one important rule, which was that we could not (ever) disclose the future release date of a product. Doing so would potentially turn unearned revenue into earned revenue as the rights to buy an upgrade went from “if” one was available to “when” one was available. Disclosure would also cause customers to attempt to time their deals so as to maximize the number of upgrades they received. It felt super weird to be involved in this dance, but it was also very straightforward. There was even a regulatory investigation at one point because we started to deliver more software online and had to adjust the portion of revenue recognized immediately versus over time.

The problem was that selling Office to retail customers was a big business but going nowhere compared to enterprise licensing. Easily half the business was new volume licensing products, and the switch from retail, especially for medium and larger businesses, was progressing rapidly. Soon the bulk of all revenue would be volume licensing/EAs and retail would simply be, for lack of a better word, a rounding error.

Still, the Office 2000 product felt too enterprise. I was determined that Office maintain both end-user excitement and broad horizontal appeal—those were our roots and people sat in front of Office hours every day. Microsoft was rapidly becoming a company of extremes, with Xbox and internet services targeting the latest consumer trends and Servers at the extreme of enterprise. Office, used by most everyone with a PC it seemed, occupied a broad space in the middle as products used by individuals and teams, at home and at work, but purchased and managed by IT professionals. This was our product design challenge—how to build a product where the buyers and users differed so dramatically.

We were years away from phrases such as “consumerization of IT,” or the idea that people wanted enterprise software that felt and worked like the cool consumer software they used outside of work. Office, however, always occupied that space. Used by individuals, even if sometimes purchased by organizations, the software was decidedly built for people who had better things to do. Office was unique software designed for work but used up and down and across an organization in a myriad of ways. Almost no enterprise software was used the way Office was, by every single person in an organization.

Creating the Enterprise Agreement was one of the most brilliant decisions in all of Microsoft history, right up there with the MS-DOS license or committing to Macintosh applications. It is why the company today could so easily transition to selling Office as a modern software as a service offering. Microsoft developed and used a muscle, so to speak, for changing the business terms while maintaining product compatibility. Once again, we see the foundation of the company today form decades earlier. The EA, which got its start in the late 1990s, was also quintessential SteveB, combining exactly what the customer wanted with just enough nuance and complexity that Microsoft could stay ahead on the business side, and yes it was also ahead of where we were in the product groups. The EA started as an “offer” as Steve would say, and then we worked backwards and filled in the details.

Office was not like a magazine, utilities, or cable subscriptions with regular flows of some consumable resource. Office never stops doing what it was purchased to do. It keeps going and going. PCs got messed up (all too easily) with poorly behaved software, but corporate IT figured this all out and created processes to clean install a PC and refresh it with known versions of software but none of the bad stuff gumming up the system. Tech enthusiasts knew this too. In fact, the internet became a hotbed of tips and tricks to cure a sluggish PC of ills caused by downloading software from the internet or playing around with the registry. The constant need for security updates had not yet become a reality, but that challenge is just around the corner and as we will see, the enterprise model only made it that much easier for Microsoft.

Key to all of this when it came to product development was that new releases seemed to be able to bypass market validation to appear successful. Customers already purchased the next and latest release, which meant we could easily fool ourselves into thinking the product was a hit by looking at the revenue numbers. Customers were buying a sales and support relationship with Microsoft, as much or perhaps more than the software itself, even when running old releases. While this was not a short-term issue, over time the lack of individual buyers acquiring specific products seriously clouded Microsoft’s collective product judgement. In many ways the mostly captive Windows OEM model, selling to a very small number of enormous accounts, would presage this product-market challenge.

Unaware of what was possible, end-users never really demanded specific new features, but IT professionals were, and what they wanted was not necessarily representative of what individuals valued. Individuals, however, seemed to have a decreasing voice in what software a company used as IT gained control of the chaos that PCs unleashed. EAs were the tool IT needed—in their mind they paid, so they dictated every aspect of the PC.

The divergence of the target buyer from the target user increased with each new enterprise agreement. The success created a new kind of problem—when people at Microsoft talked about “the customer” we needed to calibrate to better understand who we were talking about. Windows meant PC and hardware makers, the OEMs. Server products meant enterprise IT infrastructure. Tools meant developers. Office meant individuals and teams. Most of all, the sales force always meant the C-suite sponsoring a sizable deal with Microsoft, the higher up the better. By and large, customer really did mean the high-ranking executives with a direct line to the account team, the executive briefing center/EBC, and SteveB.

The complexity of enterprise agreements was often comical. There were hundreds of thousands of different deal and price permutations. There was no easy way to sell billions of one thing, just like Coca-Cola didn’t only sell 12-ounce cans of Coke—so went the conversation I would have with those on the team tasked with implementing and tracking seemingly endless and ever-changing SKUs. Not all companies (customers) were on the current release; in fact, most were not. Not all customer EAs started in the same year or at the same time. Collectively, customers were equally spread into three cohorts expiring in a given year, and each of the following two. This meant that any given release was deployed by at most one-third of customers. When buying new PCs, the oldest customers upgraded from a version two releases back, a version none of us were running that Microsoft had long forgotten about. Seemingly overnight, EAs created a complexity matrix based on the outside chance that the most out of date customers might upgrade to the latest release. We were committing to upgrading from software potentially six or seven years old because at any given time, the current and previous two releases of Office were each used by about one-third of customers—a fact that remained stubbornly true for a very long time.

PCs were also starting to last longer. There was another decade or more left in Moore’s Law. It was Moore’s Law that kept people buying a new PC every other year or sooner, which was shifting to more like three years and, in the blink of an eye, to five. The first decade of the PC was marked by software consuming every bit of hardware that could make it to market (CPU, memory, or disk space). By 2000, typical PCs had ample specifications for business productivity. Laptops were just a couple of years behind on the price and performance curves but were getting there quickly in a highly competitive market. The guideline most businesses followed was that new versions of software rolled out commensurate with new levels of hardware. Many companies were trying to get on a cycle to regularly update hardware, but they were finding that doing a refresh of the software load got another year or more out of a PC. Windows gained the most by creating an incentive for new hardware, but they were more focused on the consumer and building a successor to Windows 2000 (what would become Windows XP) that equaled the legacy Windows 95 product and their product cycles were much longer. Whereas people previously wanted a new PC at work so much they would spend their own money, a practice eventually not allowed, everyone seemed content with whatever their workplace provided. PCs and software seemed good enough. There was only one customer segment larger than EA and that was OEM which meant by and large Windows continued to focus on OEMs and less so on enterprise customers, at least with the release under development.

This dynamic was entirely appropriate of the middle age of the PC era. Instead of moving to a new home it seemed far simpler to repair the existing one. As central as the PC was to the workplace environment and health, slowly businesses were making different choices. EAs were the perfect way for a business to make one decision and not worry about it again, even if it meant paying a bit more.

EAs also created a crazy environment where concerns over hitting a ship date for retailers and OEMs were secondary to those of IT professionals trying to time the start date of their enterprise agreement. They knew they owned the current version, but if they delayed purchasing for as long as possible the two next versions might be released and ready to ship as they signed. They deployed the current release and owned the next one, and if Microsoft hit a target ship date, then they’d also own the third. As the renewal dates for a given customer approached, the pressure from that account team to the Redmond marketing team for a public commitment to a ship date only increased. This was all invisible to the broader market, but the idea of renewals was front and center for the sales and business leadership.

Wall Street analyst interactions were similar. Analysts maintained an unearned revenue number in their forecasts. They would work hard to extract from me a target ship date which gave me the uneasy feeling that I was just filling in a cell in their spreadsheet model for Microsoft earnings.

My own ability to interact with customers in settings like the Executive Briefing Center (EBC) became its own game of schedule chicken. Customers assumed that Office continued to improve but were only marginally interested in the product strategy. They really wanted to know if a new release was due within their EA subscription window. Every EBC I attended turned into a contest of how many ways can I get asked about the ship date without answering. Often the sales team prepared me for a strategy briefing only to find myself on my first slide dodging questions about ship dates. My standard line was, “We aim to ship a new release of Office every 24 to 36 months, and we last shipped . . .” This was wholly unsatisfying to customers, especially to a specific customer with a specific date in mind for their EA, asking a VP, technically by then a senior vice president. Account managers and country managers were getting increasingly frustrated with me and Office in general for not being more open and committing to ship dates.

Then there were those pesky accounting rules, so I just couldn’t say anything. Still, if I were to give a more specific range to customers (or to the analysts, for that matter, who as a proxy for customers also needed to know) then I had to be right. The problem was we were never right. For customers, even a month error was a massive dollar-value issue. If we were a month late and a customer didn’t qualify for the product then every impacted customer sought compensation. Plus, a date range was a joke. Inside Microsoft if someone said “first half” of a year, as they often did, then other product groups might assume June 30. Customers hearing the same range likely assumed January 1.

A ship date is a date, not a range. A quarter is 90 dates. A half of a year is 180 dates. I hated this game.

It felt as absurd as it sounds. Yet, it was the reality. It made me look clueless at best; at worst, coy. I hated pretending not to know. I hated acting like we were ineffective at our jobs. So many customers commented, “In our industry we make a big giant complicated thing and if we told our customers we didn’t know when it would finish we’d have no business.”

Every time, I thought about industries from Boeing planes to Ford cars to Bechtel bridges and how late they were. I repeatedly bit my tongue.

Then I stopped putting myself in the EBC. It wasn’t the best practice but I just wasn’t wired for this type of tap dance. I have some regrets.

EAs came about to maximize an available revenue opportunity and customer relationship (thinking back to that 1993 retreat where we talked about filling the void left by IBM—this was it), even if the product or product development process had not caught up to that opportunity. As we bundled already successful Word and Excel into Office even though the products were not yet integrated, we were selling enterprise licenses even though our processes (and product) had not yet matured to that level. We were selling subscriptions long before subscriptions were cool, or even built—this is an important and hugely significant legacy of SteveB’s enterprise sales leadership (eventually these EAs would be called recurring revenue).

Given this, Office needed to create features that delivered so much value to IT professionals in the enterprise that they outweighed the cost of deploying and training employees. Simply making Office more enterprise friendly and easy to deploy were nice, but it was still more difficult to deploy than to do nothing. We needed to accomplish this on time and within the magical three-year window.

I genuinely believed that we had created an unsolvable problem—creating enough business value to justify an upgrade in the eyes of the gatekeeper. Imagine trying to make Word, Excel, and PowerPoint so much more valuable that the new features were worth more than the sum of all the old features? Difficult enough, but what made this even more absurd was that the IT people were actively customizing Office to disable features they deemed to be of low business value. It was not surprising to see companies disable access to HTML, templates, Visual Basic programming, or data connectivity features simply for concern, or fear, that they might get misused, waste time, or generate support calls. While this was acute for Office, upgrades were an industry-wide challenge.

Failing to create value, some in the industry moved to upgrades by force, by changing the file formats, creating proprietary connections between servers such as Exchange or the Windows web server, or by requiring the new version for patches or updates. Office generally resisted these artificial growth methods.

This ran counter to new internet era companies, which were not about tightly coupled software but about loosely coupled software. This philosophy was the exact opposite of how Microsoft created new features—the connection between Exchange and Outlook was as tightly coupled as could be—each required the other and without both there was no value at all.

Enterprise agreements were making it look increasingly difficult to build the right product. How ironic.

Grinding out relatively on-time releases that shipped on a certain date and doubled down on enterprise features seemed perfectly achievable. There was little risk that we could mess things up with such a plan—I would achieve all my performance goals relative to EAs. The product would probably stink, though, for the people that used it for their jobs every day. We would try to create metrics across the company, incentives to achieve customer upgrades, but no teams controlled anything that could dramatically alter customer behavior. From the product group our job remained the same, to build a great product. We could make a better Office, but that would not dramatically change how fragile a PC was, especially one loaded with IT software and customizations. This wasn’t an excuse. It was reality.

If there was one lesson building the apps business, it was that great releases empowering individuals and helping them to create compelling documents pulled Office into companies. There needed to be some balance. Achieving that balance was our goal for planning what would become Office10.

On to 058. That Dreaded Word: Unification

Launching a product in a local market, natively so to speak, is an extraordinarily special experience. It is so special that for nearly every product I worked on I chose to be outside the US and participate in some aspect of the global launch, most of the time in Asia. With this love of the market came a learning curve and some fun times. Office 2000 was my first chance to launch a product as an executive and in Asia—it was a dream come true.

This is the final post of the millennium and concludes the chapter and launch of Office 2000, which I think you can tell was a tremendous period of personal growth that went along with the scaling of our product team, and why the past three posts have been a bit more personal. The PC is entering a new phase, the maturing of the market as an enterprise product. The next two chapters cover this incredibly important time in an evolving Microsoft—everything was happening at enormous scale and global diversity yet coordinated in a manner consistent with the need to develop enterprise products. The stories of Microsoft during this time are few and far between and I’m hoping to fill that void because this builds the foundation of today’s Microsoft.

There will be no post next week due to the US holiday.

Back to 055. Office 2000 is Good to Go!

Everything about participating in our launch event in Japan was as orchestrated and as on time as the JR subway. For weeks before launch, I received down-to-the-minute schedule updates, “1635: move to event hall”, “0940: prepare with translator”, “1210: meet for the box lunch” and so on. I could not have been more excited to attend.

My friends (co-workers) in Japan were frustrated that I flew there by myself, navigated the city on my own, and declined being met at Narita Airport to be shuttled into town, a 2-hour trip. In the ’90s my ways were not how American executives did Japan, even though it was not one of my first trips (see Michael Lewis’s Liar’s Poker for how bankers did business in Japan). They were so concerned I might get lost that someone prepared a camcorder recording of the entire transit route for me from customs at Narita to the hotel, which they sent to me on a CD-ROM to view.

Using my video directions, I arrived in Tokyo. The head of East Asia R&D, Akio Fujii (AkioF) met me at the hotel—he insisted, no, he really insisted—and drove us (his car had a TV in the dashboard!) to the Windows World Expo/Tokyo 99 event, which was a 1000-person venue that we would fill. Oddly, a bright yellow Lamborghini was parked practically at the front door of the expo hall. Fujii-san explained that the launch event creative manager drove that car and that he was (very) big in Japan event circles. I was already off to an over-the-top start to the event.

We arrived and met with Susumu “Sam” Furukawa (SamF). SamF, a tech legend in Japan, was an original leader of the Microsoft subsidiary, MSKK, and served as Chairman of Microsoft Japan. He was a relentless champion for the PC, Microsoft products, and an advocate for Japan in the United States where he kept a home by Microsoft. In addition to his passion for every conceivable electronic gadget, audio/video tool, or handheld device, Sam was famous for his love of model railroads and built elaborate scale scenes often featured in the magazines. He was also known as one of Japan’s leading gadget gurus and had deep relationships with Japanese consumer electronics companies. His enthusiasm was so remarkable and infectious I often failed to keep up with him in meetings because his excited English ran together and sounded like one long word or sentence. Then once BillG mentioned to me that he was pretty sure no one could keep up with Sam in Japanese either, which was quite a relief.

The stage seemed rather stark. Draped over most of the front of it was a plain gauze curtain, a scrim. Puzzling. SamF arrived and was his incredibly excited self. He secured “the brightest high-definition projector in existence from a best friend at Hitachi.” The Hitachi crew in matching jumpsuits and hard hats was up on the catwalk calibrating the projector.

They gave me staging for the next morning’s event. There was no room for improvisation. The translator was briefed. I was to say only what I was told to say—“Konichiwa, Sinofsky desu” and then recite the English script, ending with “Arigatou gozaimasu.” That became my Japanese business vocabulary that served me for decades. It was Lost in Translation happening to me (also I was staying at the relatively new Park Hyatt). It took hours to get everything right. At least I thought it was right.

They told me that after my rehearsed words, music would play and the scrim would drop, revealing a Hitachi projection of Office 2000. Sam had me leave the stage so I could see it all from the audience perspective. We headed to the back of the room by the control board that must have been twenty feet long staffed by six people.

The stage lights dimmed, a spotlight lit up where I’d been standing, and Sam said, “Pretend now you are finished.”

A rising crescendo of strings and wind instruments, like Yanni, rose in volume to almost an ear-crushing level. Then the scrim dropped in rather dramatic fashion. The stage lights went up. There was a giant backdrop projection of a single huge Bonsai tree brightly filling the brilliant and enormous screen that spanned the stage.

Over the tree in white letters it read Office 2000 with the new logo. There were some Japanese words that I could not read and in the Japanese font used for English letters the words “Mother Tree”.

Sam was blown away. He said, “Isn’t it amazing?!”

I said it was. “Amazing. Beautiful. Brilliant.” But I had absolutely no idea what Mother Tree meant.

I bowed to everyone I could make eye contact with. I said, “Arigatou,” while deeply expressing appreciation.

I had no idea what was being said on the giant display.

When I asked Sam for the meaning, he said, like he often had before, “It can’t be translated.” I asked Fujii-san and he said the same thing. I even asked the head of Office marketing, Nobuyoshi Yokoi (NobuY), who in MSKK was known as Mr. Office, and he simply pursed his lips, pulling in some air, creating a Japanese thought-bubble implying difficulty, and said, “So sorry, Steven-san, but there is no translation.”

The best I could gather was that it was marketing the importance of Office and how it was a strong collection of tools growing from a solid and enduring foundation.

Maybe?

While I never truly learned the full meaning, I loved it. It represented the hard work and dedication of MSKK and the incredible effort they put into the launch. I brought back a giant poster of the image (they packed it incredibly well) that must have been four feet high and six feet wide and hung on my office wall for years. Like every single thing I experienced in Japan, the poster was magic and evoked the warmest of emotions.

In Japan, as in the rest of the world we coupled the launch of Office 2000 with the long-anticipated beta release of Windows 2000, in a campaign informally called Desktop 2000, aimed at defining a new standard enterprise desktop PC. The launch event was a mix of enterprise and consumer though it was clear the emotional connection was to retail customers. This should not be a surprise because of how the business was structured in Japan.

Unique to Japan, Office at retail was a huge business because it sold for the full retail price with newly purchased PCs. Japan had not yet embraced the top-down IT model of purchase and deployment, which was okay because the retail model was more lucrative for Microsoft Japan (so long as new PC sales kept growing). Originally offered as a service by PC stores, the idea of installing Office for customers—pre-installed PC, or PIPC—was a special offering of Word, Excel, and Outlook (with an option to upgrade and add PowerPoint) that was offered with a new PC for what amounted to full retail pricing. This offer was wildly successful and popular, though could never be replicated elsewhere. For years people would assume Office came “bundled” on new PCs, but really that was only true in Japan where the price stickers on new PCs made it entirely clear what the price was with or without PIPC Office. So successful was this business in in Japan that it was a significant part of the overall subsidiary, so profitable that it was a noticeable part of all of Microsoft’s earnings.

BillG’s investment in and focus on the Japanese market is not often appreciated. Very early in Microsoft’s journey BillG began a partnership with legendary Japanese technologist Kazuhiko “Kay” Nishi founder of ASCII Corporation (a magazine publisher), eventually partnering to bring MS-DOS based PCs to Japan. In the 1980s, Japan was innovating in PCs in an isolated way but also represented a huge market. Japan was the world leader in electronics and had a powerful government ally known as the Ministry of International Trade and Industry (MITI) that was often in the news here in the US because of concerns the US was falling behind in computers, chips, and software due in part to the intense involvement of the government in directing innovation. In the 1990s, the specter of the Japan economic engine was vast, from chips to New York real estate to autos.

It took a great deal of partnering and Japan-specific development to break into the market and ultimately win over in-country rivals. For many years until Windows XP was in stores, it was not uncommon to see DOS/V compatibility indicated on products, the variant of DOS supporting Japanese characters and video devices spearheaded by IBM. Working with Kay Nishi, Microsoft collaborated on PCs with Japanese companies and eventually sold Basic and then DOS to Japanese companies. In 1986, Microsoft opened the Japan subsidiary. BillG hired SamF to lead it. Sam immediately began hiring among the very best recent graduates and software people he could find to lead Microsoft’s first international research and development office.

Among those hires was Akio Fujii (AkioF, or as I generally preferred Fujii-san – in an interesting twist, Microsoft’s email people wrestled with reversing Asian names to be more proper but could never quite get that right, especially in Chinese where to IT the first and last names were often not obvious, much to the frustration of employees). Under the leadership of Fujii-san, the Desktop Apps development team in Japan coordinated the development of most all of Microsoft’s products for Japan and led development across East Asian products (Korean, Traditional Chinese, and Simplified Chinese) with teams in several locations, known as East Asia R&D. Fujii-san was one of the earliest employees hired by SamF. Many of the people working at MSKK today trace their own lineage directly to SamF and AkioF and the original opening of the subsidiary, which has grown to thousands of employees and just celebrated its 35th anniversary.

In the early days, simply getting software to work with the mysterious double-byte characters used to represent Japanese in DOS and 16-bit Windows was a huge technical challenge. While standard practice today, almost no code from the early days of the personal computer was written to be localized or translated into other languages, and certainly not work with the alternate characters or vertical text used in Asian languages. Many early Asian-language products were created by taking the English/European source code and hacking away at it for an entire product cycle without much help from Redmond, often taking more than a year to release.

The financial motivation and advancing technology brought this “delta” (the time between the US release being complete and localized variants of the software being complete) down to a predictable number of weeks. Aside from making the code simply function with Asian language characters, there were thousands of user interface strings and many thousands of pages of help files that were translated each release as well.

Even after all that, early products were simply wrong for the market, wrong as in customers were often puzzled by the missing features or the type of documents that were extremely difficult to create with Office, even as late as 1995. Fujii-san and team would perennially raise issues about the missing features or difficult to use features in Office for the Japan market, but these would often fall on deaf ears—not deaf for lack of empathy but simply because of the ongoing competitive battles just trying to win in the US.

A symbolic example in Excel was the lack of donut charts which are used routinely instead of pie charts but did not exist in Excel. After much consternation, donut charts would make it to Excel albeit much later. I could make many excuses from too busy to too complicated to have developers in another time zone on the same code base (a real challenge back then), but it really was a failure at making a distant market a priority. I previously faced this when I first met the MSKK development team trying to build Visual C++ for Windows, which also had local market challenges.

The Word team set out to address this, in particular by hiring native or near-native Japanese speakers on to the team in Redmond. Several other members of the team took Japanese lessons as well. This began a long and sincere effort to fully adapt the product to the needs of Japanese users, working closely with and often with contributions from the engineering teams across East Asia. With this came extended visits to Japan to learn directly from customers and upon returning to Redmond, educate the team on the cultural differences. The hallways were filled with Japanese documents illustrating the differences in how features were used and what the difference was in printed output.

This animation above is a quick demonstration of “Table Pencil” in Office 97. Creating a table was as simple as drawing out the borders and erasing ones not needed. Text could be shown vertically as well and cells could be colored as they could be in Excel.

One of the most memorable examples was when the team explained how many Japanese customers preferred to use Excel as a “word processor” to create standard forms and templates rather that Word, which seemed a bit crazy to us. What followed was an endless series of example documents that were far more focused on grid-layout than anything we’d see in the US. As any English-native who has flown to Japan, checked into a hotel, and filled out an exit visa can tell you the documents are filled with boxes and lines, as well as vertical text. Word simply couldn’t create those documents and Excel was great. This changed in Word 97 when a feature known as table pencil was added, which let users draw (and erase) grid lines in a table and create documents that were literally elaborate tables.

Following this and several other lessons, the team got much better at integrating feedback and eventually features and entire market-specific products for Japan. The East Asia R&D team developed some of the most innovative and earliest linguistic features for Office and Windows, features few today can imagine living without. Asian languages based on characters and not finite numbers of letters that fit on a keyboard require input via phonetics that translate that into suggested characters, which the user then chooses from. This is called the Input Method Editor, IME, and was one of the most significant innovations in the PC era for Asian languages. Starting with Japanese, then adding Korean and Simplified and Traditional Chinese, the team created the user experience for typing. In many ways, today’s mobile phone experience we share with autocorrect and fixing mistakes resembles what Asian language users have been experiencing since the earliest days of the PC. Early on they shared many of the same complaints about incorrect guesses and awkward suggestions that we still live with today.

While most new software companies were content to battle in the US and expand to Western Europe, Microsoft was early and aggressive about expansion into Asia. For me personally, the Office 2000 product launch marks the start of strong devotion to working in Asia and elevating that work. I had many fun product launches and visited multiple times per year, creating many strong friendships that continue today on social networks where these stories are shared. In 2004, I spent my Microsoft sabbatical (technically the Microsoft Achievement Award, MSAA, a three month break to do what you’d like, earned after seven years of service) living in Beijing and working with the subsidiary on local market issues with the government.

Back in the US, the product launch was decidedly enterprise focused. In fact, much of the fanfare would wait until the arrival of Windows 2000. The enterprise sales team geared up for a massive push of Windows 2000, Windows Server 2000, Exchange 2000, and Office 2000, then even added SQL Server 2000.  The launch of all this software—perhaps the release that came to define the company as an enterprise provider of software—was inspiring. Microsoft was indeed firing on all cylinders as an enterprise company. It would take a few years for customers to digest such a wave of software while at the same time we were relentless in releasing even more.

Video of the public Office 2000 enterprise launch event at the Metreon San Francisco, June 7, 1999. The Metreon just finished construction and would formally open the following week. (Source: personal collection)

The enterprise launch of Office was held at the newly opened Sony Metreon space in downtown San Francisco, featuring the long-forgotten first Microsoft retail store, MicrosoftSF, which featured displays of products you could look at and not buy. Steve Ballmer, in his first major launch as President of the company, brought his undeniable enthusiasm to an enterprise product launch. San Francisco Mayor Willie Brown also proclaimed it “Microsoft Office 2000 Week” saying he can do that because he’s the “Bill Gates of San Francisco”.

The event was also first of many of a new style of Microsoft event that reflected an enterprise level of information density. Every keynote or launch featured strategy slides, multiple demonstrations, video testimonials from customers and partners, and then a long-term vision for the industry by a senior executive. At this event in the IMAX theater, we even had Q&A with the customers and partners in attendance. It was quite a show—in length and density.

If the wave of products defined success in the enterprise, it was decidedly the opposite for consumers or just regular people, even small businesses. Across the board our traditional reviews were underwhelmed or even perplexed by the focus on collaboration, web standards, reducing cost of ownership, and other big company features.

With two launches and availability dates, the reviews came in two waves. The enterprise reviews for Office 2000 were extremely solid. I don’t think we could have wished for better enterprise evaluations. With enterprise availability that April, InfoWorld, the go-to source for enterprise computing news, said:

Its many enhancements should ease IT administration headaches, reduce overall ownership costs, and improve the workgroup collaboration experience. For companies who are already standardized on the 95 or 97 versions of Microsoft Office, the move to Office 2000 should be a no-brainer. And even for those who are not, moving to Office 2000 offers some compelling benefits.

The consumer launch in June brought another wave of coverage. Only this time, the words were not so positive. As successful as we were at orienting the business around enterprise, we clearly did not deliver what the consumer reviewers were looking to see. Walt Mossberg, with whom I personally met several times during development, wrote in an article headlined, “Microsoft Updates Office Suite, but It’s Not for the Little Guy.”

However, I may be able to save you the trouble and expense. I’ve been testing Office 2000 for months now, and I believe that most individuals and small businesses that already use one of the last two versions of Office will gain little or nothing by upgrading. It’s not that the program is a dog. It works well, in fact. But this version has been engineered almost entirely for big corporations with speedy networks. Its most significant new features are aimed at helping people who collaborate over a network and post a lot of documents to the Internet or a corporate intranet. . . . Some new features look great on paper but work well only for corporate users. . . . The bottom line for consumers and small businesses is this: If you have a very old version of Office and a fairly new PC, or you need to post a lot of business documents on the Web, it makes sense to upgrade to Office 2000. Otherwise, forget it.

The sting was real.

I was hurting. Was Personal Productivity Is Priority 6 the wrong approach? Did we really mess up? Should we have seen this coming and adjusted along the way? It seemed so obvious in hindsight. On the other hand, we did exactly what we set out to do. In Microsoft performance review lingo, this was a 4.0 (on our 2.0-5.0 scale of the time, where almost no one ever got a 4.5 or 5.0).

The answer, regretfully, in some ways, was that we (or specifically I) did not mess up. The Office business depended on building a product for business customers. The reviews were positive in that regard. The consumer reviews were not the key to the success we were achieving and needed to achieve going forward.

We built what could sell. And we were selling what we built.

We should do both was a constant refrain over many discussions—we should have a great consumer product and a great enterprise product. On paper that is the ideal situation. In practice it was not that the needs and desires of each type of customer were diverging; they were increasingly in conflict. It was not that consumers wanted different features; they also explicitly did not want the enterprise features. This worked both ways, as the enterprise IT view decidedly did not want more features, but rather fewer.

Practically, anytime one tries to take on two conflicting perspectives in one product, the product comes across as a compromise. It is neither one nor the other, but a displeasing mess. The hope I had at the start was that by making personal productivity Priority 6 we avoided the messy middle. We succeeded at that, but I was struggling with how unsatisfying this felt.

Even with all these challenges, the launch of a new release of Office was still a noteworthy news event around the world. Above is a collection of clips from local television news and the ubiquitous airline television programming showing off the successful efforts of the marketing team. (Source: personal collection)

The middle age of the PC was upon us. The age of designing for the individual, the lone hero using the PC as a tool of empowerment, was over. The tinkerer and influential end-user moved from the garage or basement to the office of the chief information officer, the new power seat in the boardroom. The PC was a tool of corporations, and Office needed to deliver that if it were to stay relevant. With Office 2000, the business results suggested that we were spectacularly relevant.

I still held out hope that we could find a path forward that was more appreciative to the individual sitting in front of Office with a job or schoolwork to do.

Reminder, taking a break from posting for the US holiday.

On to 057. Expanding Office in the Enterprise—Enterprise Agreements [Chapter IX]

Office9 (aka Office 2000) was the very first release of Microsoft Office built by a team that began the project and ended the project as one. Well, almost as there was that pesky Outlook challenge. That said, the project was coming to a close by the end of 1998 and it was late. It was not terribly late or out of control as I reflected on my 1:1 with SteveB, but late nonetheless. The way old-timers would talk about projects to me was that product development slogs “really sucked” and then you ship and that is the “best feeling ever” and it is worth it. I was hoping to feel that way soon. The last month of 1998 would be eventful for me personally and the team in ways that were unexpected, both happy and tragic, and a reminder of the scale at which we worked.

Back to 054. Steve and Steven Get New Jobs

Not only were we five months late by the end of 1998, we also faced the lag time that would happen on the other side of our pending a holiday break. It became clear our end-of February completion date for Office9 was going to be a challenge.

At least we were on the glide path to completing the product before we left for the holidays. As far as the enterprise sales team was concerned, we were going to finish in the first quarter, which was important for customers buying or renewing volume license contracts. Office 2000 was shaping up to be a significant release for the end of the millennium. And yes, Office 2000 was Y2K ready.

As I prepared to head to Florida for holiday vacation to see family, JonDe let me know that I was being promoted to corporate vice president. This was truly a big deal personally, and as I look back I realize it was a big deal for the company. Along with BrianV leading Exchange a press release would go out announcing our promotions in about a week—the ranks of executives were small enough then that not only did we do press releases for promotions, but we became named officers in the company and the two latest additions from the product development teams. If you’ve ever been part of a rocket ship, what you experience is growth in executive promotions when you start to wonder if this is a worthy promotion or will people outside your immediate group roll their eyes. NatalieY, the spiritual and cultural leader of the company in human resources, sent me an incredible note telling me how “real” the promotion was which meant everything. These insecurities come with what does seem like one of the most significant milestones in a career and for me, I will always think of this as the most significant, owing much to JonDe and all of the Apps people before him.

While everything was the same organizationally, what was simply a title change in the Exchange address book was the start of being treated differently, particularly by those I did not yet know, especially in the field sales org, and, perhaps even more entertaining, by the various Microsoft systems and services.

In short order, Colleen Johnson (CollJ) was being briefed on the exec travel desk (EXTRAVEL), executive tech support (EXECSUPP, yes, there was special on-call PC and tech support for executives), executive shuttle (sort of an Uber for VPs to go between buildings that I almost always walked anyway), and even the special team that helps make PowerPoint slides for execs, and so on. I knew these existed, but I thought they were for Bill, Steve, the CFO, and Board, not all the VPs. Oh, and my card key worked in all sorts of places it used to not work, like weekend access to the Executive Briefing Center! I did have mixed feelings about special treatment for run of the mill execs in product groups. The teams were all incredibly nice, but this felt like excess to me.

CollJ was a key addition to our team who had an outsized impact on our operational excellence and culture. Hired as an administrative assistant, she quickly and quietly assumed the role of indirectly managing the dozens of administrative/group assistants across the team (on average one for every 100 people) which was the front line of our culture of careful management of resources. She also took on the role of formalizing all our headcount tracking which was a key enabler for how I would manage the team. A dumb example was instituting a code in our SAP-based system for what individuals worked on (Word, Excel, Office shared, etc.) and what functional group they were in (dev, test, program management). Amazingly our systems did not track that and yet it is all that mattered in managing a significant team. For decades neither she nor I managed to coach other teams into managing this way, even after the yearly visits from teams being told to learn a best practice from how we managed things. There’s a lesson in there—you can’t manage a big team at scale if you don’t know what people are working on and how humans (not dollars) are allocated!

Colleen also led our efforts at developing a new more scalable Office culture. Too much of Microsoft was still acting like it was college when it came to team outings or now operating like a fancy Wall Street bank when it came to using company resources for events. From figuring out how to get a huge discount on team movies by renting all the theaters for morning shows and offering family friendly and alternatives to the current sci-fi release, to helping teams to know about $250/day offsite locations (including a stop at Fred Meyer for snacks) instead of the $2,500 locations (before the required hotel catering), Colleen instilled a broad sense of fiscal and cultural responsibility across the team of admins. She helped to create whole classes of events such as our product vision meetings, the “tradeshow”, and especially our launch events. As the team grew, the tradeshow became a hallmark event where every member of the team had a chance to experience all the other teams building Office as though we were at a tradeshow. Years later, Microsoft Research would adopt this format for what became the Microsoft TechFest event.

As a VP I quickly learned people I did not know would no longer email me directly and even people I did know would soon also employ the level of indirection afforded by CollJ. The Microsoft culture had developed an arm’s length VP culture, where contacting a VP meant going to the Exchange address book and looking up the direct reports of a VP to find their Executive Assistant to contact about “getting time with” or “what is the best way to email them”. Exchange had a unique feature where you could offer an assistant direct access to an email account as a delegate. Suddenly VPs were having admins screen email and even respond on their behalf. How quickly we became “big”. Along with helping people to email me directly, Colleen had to remind people of one other quirk of mine I insisted on, which was I managed my own calendar. I was hardcore about this because of what I’d gone through in terms of the ripple effect of scheduling. A meeting was scheduled with an exec, the executive assistant moves the meeting for something important, then everything dependent on that moves as well. Soon the one person who needs to get out of the way, the VP, is the barrier to making progress as a routine course of business.

I think I spent the rest of my years trying to hold on to a feeling of small, and avoiding the distant feeling new hires (and we had hundreds every year) would have towards execs. I think I had varying degrees of success at doing so and certainly made my mistakes at trying, but with Colleen’s help I worked hard at that for my run, even as we scaled.

The press release went out while I was on the way to Miami. I was expecting an uneventful time in condo haven, North Miami, aka Del Boca Vista. Working to avoid the tourists in the city, I was reading the pre-holiday Miami Herald newspaper (scoping out a holiday movie to see). The paper contained a story of tragedy at Disneyland. Anything to do with Disney received a great deal of attention in Florida and caught my eye having grown up in Orlando. A guest was seriously injured on a ride, through no fault of his own, and later reporting said he died on Christmas Eve. The first coverage did not have a victim’s name but soon the details emerged.

Almost at the same time as the first story, an email arrived from Jeanne Sheldon (JeanneS), who was leading Word testing at the time, asking me to call as soon as I could, which was not routine. Over the phone, I learned from Jeanne the victim was a senior test engineer on the Word team who, like me, also started at Microsoft in July 1989, after first emigrating from Vietnam to attend university in Paris. His wife was also injured though expected to recover. Their son escaped injury. JeanneS took it upon herself to craft a note that was to be the first email I would share as a vice president to the entire division. The subject line read, “Sad News.”

Microsoft was still young enough that we did not have in place the big company processes that eased these tragic situations. Much of the grieving happened in email over the holiday. It was an awful time for such an awful tragedy. I was starting to learn that at a certain scale, every kind of life experience, joyous and otherwise, would be part of our team. Microsoft had a few sad times before, and even some close to home in Apps, but this was difficult in its own way.

As we returned to work the project was winding down and we were in bug fix mode where only critical bug fixes were “taken” meaning only the most serious bugs were addressed with code changes.

Despite being a team always worried about engineering productivity, we were in that phase of a major software project where 2,000 people came to work every day and basically did nothing, if the measure of something was making changes to the product. Testers ran and re-ran tests. Developers investigated bugs and decided if the code change risk was greater than the risk of leaving a “bug” in there. Program management was fielding endless inbound requests for just one more thing or digging into one last potential oversight. Documentation and Localization were working on producing international releases. Lawyers were combing through marketing materials and documentation, and of course adding more words to the end-user license agreement (the EULA). We were all using the product as end-users and testers on every computer we owned.

The biggest disappointment we were having about the new release was the lack of excitement within Microsoft. Whereas people were beating a path to the servers to install Office 97, we struggled to get Office 2000 deployed in large numbers across the company. This was, in reality, a sign of changing times.

Broadly pushing, perhaps forcing, internal use prior to shipping was another cultural difference between Apps and Systems. The Systems view was always hardcore—hardcore about pushing internal use, sometimes even too early, and hardcore about not using competitive solutions. The first was enabled by the long end game of shipping a Systems product, for example, Exchange Platinum (Exchange 2000), which began use inside Microsoft in 1998 and did not ship for almost two years. SteveB even apologized at an all-Company meeting one time for the bumpy Exchange pre-release. It was in beta for most of the entire Office 2000 product cycle. Competitively, Systems often rooted out competitive products and made it a goal to remove them (like Oracle server or later Google search).

The Apps view was always a bit less aggressive. The time from the product working until shipping was much shorter—there was less time when the product was usable by the typical employee, and by then a typical Microsoft employee was not much different than a typical employee in most any large company. We always viewed the use of a competitive product as a failure on our part, but one to learn from not to force away. If an individual or team wanted to use an alternative, then we would not object but want to understand why. The biggest example at the time was the growing use of Adobe’s PDF instead of using the native file formats that BillG had insisted upon.

Our testing and release process did not rely on an extended period of internal testing or external beta tests. The nature of our products and process enabled us to achieve a high level of quality, even during these maturing days of the PC. Perhaps this was misplaced confidence as there was little data to base this on, but we closely tracked support calls and enterprise customers to have a good “feeling”. In the next chapter we will have an eye-opening experience when it comes to data informing these decisions.

In the case of Office 2000, we were starting to see a sea change in Microsoft and the industry. Office was not the only place (or even a place) for excitement at the time. Browsers were really exciting. Consumers were excited by new MP3 players, not laptops. Most of all, enterprise IT was not excited by anything that caused them work—their cycles were being used trying to stabilize internal infrastructure, convert legacy client/server to the web, and prepare for Y2K.

We were losing competitively but to different competitors, not the alternatives to Office we feared.

The biggest competition for Office 2000 was . . . Office 97.

We were so heads down finishing Office 2000 that we didn’t realize how well received, and how good, Office 97 was. Everything we announced at our Office 2000 enterprise event in New York was solid and the feedback from the beta was good, but we faced resistance to upgrade because it took work. While customers already owned and paid for Office 2000 with their multiyear agreements, the cost to deploy (the cost of change, support, labor, etc.) had to be considered. To deploy Office 2000 or not was a major decision point within IT.

The sign-off for Office 2000 took place on a sunny April day in 1999. The product was eight months late from our original schedule we picked in March 1997. Unlike Office 97, however, the team was not frazzled, but tired. We faced the complexities of pulling everything together, but we improved the process and came together as a team. Still, an eight-month error is big on a 24-month schedule. We would conduct a detailed postmortem and make a series of changes.

CollJ and the admin team commandeered the fountain area between buildings 16-17-18. The makeshift stage and a megaphone were ready. Continuing with the theme of a maturing culture, Colleen instituted limits on alcohol and everything went smoothly except for a minor champagne incident inside Building 17 that the Art Committee was rather upset about. We grew up a little bit more this ship day.

Earlier in the day we met in the ship room, with one representative from each of the 20 or so teams. Going around the horn like Mission Control at Cape Kennedy (1999 was the 30th anniversary of the moon landing so space was everywhere), we proclaimed Office 2000 “ready for the web” and “good to go.”

I missed signing off on Office 97, but this time, as the VP of Office, I was going to get the “special treatment,” meaning I was going to get thrown in the fountain. To everyone’s surprise, I came prepared, wearing a bright yellow rain suit and goggles (to protect from flying corks). CollJ printed out a giant copy of the paperwork that went to the manufacturing plant that duplicated DVDs and we did a ceremonial sign-off with BillG, who made a fast getaway to avoid the celebration.

The surplus air raid siren, a desktop applications cultural touchstone, sounded (though technically illegal to set off in the city of Redmond), as was DAD tradition for every ship party and sign-off. The next thing I remember was sitting in a fountain soaking wet.

The events of the day were memorialized with a videotape (an actual cassette), which each member of the team later received, including a congratulations from BillG at the end after rolling the credits for the release. Almost 2,000 names scrolled by while the Office Assistant PowerPup looked on. Still always looking to save money, we didn’t do anything fancy for the credits—it was a Word 2000 document that I scrolled using support for the wheel mouse (introduced in Office 97).

Our growing business with enterprise customers and the arrival of the internet introduced a new step in releasing the product. Enterprise customers would now begin deploying Office 2000 right away and would not have to wait for the retail arrival of boxes. We announced RTM for enterprise customers with a press release. In a few weeks we would actually launch the product for the retail market with a global series of events. I was off to Japan.

It wasn’t just mission accomplished. It was my first mission as a general manager and executive, and it did feel different. Standing on the makeshift stage in my protective gear and signing off on the product—the first release of Office as a single team—was an emotional product moment.

On to 056. Going Global . . . Mother Tree

Steve Ballmer was named Microsoft president in July 1998. There was not much fanfare because it seemed an entirely natural progression of his role at the company, partnership with Bill, and recognition of the incredible accomplishment in building a world-class sales force over the past few years leading that effort. At the start of his tenure, he set out on a schedule of 100 one-on-one meetings with people across the company. Just as I was about to meet with him, I was promoted to general manager of Office. How did the meeting go?

Back to 053. Strategy Tax: Outlook Storage, First Attempt

Subscribers, be sure to check out the subscriber only bonus post Competing with Lotus Notes

The full-page story in InfoWorld July 27, 1998 began ominously “Most new presidents can count on a 100-day honeymoon...but for newly appointed Microsoft president Steve Ballmer, that blissful period is probably going to be something less than 100 hours.” This wasn’t the typical coverage.

In fact, most of the coverage reflected the broadly shared internal view that Microsoft was growing up and needed an executive structure to match. It was growing up in precisely the way Steve had orchestrated and been leading—Microsoft was becoming an enterprise company. The coverage was by and large friendly and reminiscent of the close connection Bill and Steve had and the natural evolution of the role he had been playing in the company.

Previously, Microsoft had a legendary President/COO Jon Shirley (JonS) who brought 25-years of experience from Radio Shack and was responsible for building out Microsoft’s business infrastructure through 1990 and remained an active board member for years. Microsoft brought on several other senior leaders, but like many growing companies had a difficult time helping them to fit in and thrive. Bob Herbold (BHerbold) joined from P&G in 1994 and remained as COO reporting to Steve through 2001. Steve, with his connection to Bill and his strong role in shaping the new Microsoft, was a more certain appointment.

SteveB was named president of Microsoft in July 1998 (Microsoft’s fiscal year ended June 30, and frequently big changes happened either right before or just after the end of the year). For many, me included, this was viewed as a natural progression and one that most felt was entirely right for the company. Steve was managing worldwide sales and support and was promoted to lead the product groups and all the operational groups.

BillG emphasized that he still planned to devote time to product issues, and with so much to do he saw himself spending the next 10 years as CEO, perhaps to put people at ease. To be clear, this was a huge change for Microsoft. For the first time, we had a non-product/technologist managing all product groups. In a 1:1 with Bill he emphasized to me this “10 years as CEO” talking point which was in most of the press, countering an oft-repeated assertion that Bill might be making room to spend more time on the looming regulatory challenges Microsoft faced. Bill assured me that he was going to continue to spend time, now more time, immersed in product development. After the recent email debates, over HTML, it wasn’t as clear to me that was a positive. I kept that thought to myself.

Steve orchestrated perhaps the largest and swiftest pivot (a phrase that became deeply rooted in Microsoft lingo due to Excel’s successful feature) to an enterprise sales operation ever seen, expanding and building out a global sales and support organization that easily matched in quality if not scale any of Microsoft’s competitors, from Oracle to Sun to IBM. From databases to networking to directory to email to productivity, SteveB’s sales machinery across LORGs, MORGs, SORGs (large, medium, and small organizations), governments and education, and industry verticals from finance to health care all were covered. Operationally, the enterprise sales force was a machine. It was present. It was loud. It was visible. And mostly it was all new, as if synthesized from thin air. The field, the collection of account managers (sales and technical), country general managers, and business segment leaders, is often hailed as Microsoft’s biggest asset, and what has certainly fended off many competitive challenges (even if product people like me like to think the product did the heavy lifting). It is the field operation that carries Microsoft today.

SteveB never approached a job with tepidness, often employing a saying from his father, “If you’re going to do a job, then do a job.” He began his tenure as president by a widely known (and followed via backchannels) series of 100 1:1s with leaders across the company (and innumerable calls and meetings with customers and partners). Mine was scheduled for the end of August. It was not like a list was published or anything, but among many there was a desire to know, “Did you do your meeting?” I knew SteveB from working with Bill, showing him the internet, and many meetings with the Japan subsidiary BillG often met with. I figured our meeting was intended for Steve to get to know me and my role and for me to understand the new role of Microsoft president.

Shortly before Steve’s promotion, I was named general manager of Office—meaning I would be managing all of product development for Office (Word, Excel, PowerPoint, Access, Outlook, and the Shared Office Team as we were now calling OPU, all together about 800 full time engineering). While it was a natural progression (though not one I was seeking out), and a huge promotion, we were mid-cycle and I was hesitant to change anything or distract from the work being done. Plus, I was only 32 and was deeply worried about losing connection with product and technology as I discussed with BradSi then the divisional executive. Still, this management consolidation, especially bringing Outlook with the rest of Office under one manager, was clearly going to happen—with me or without me. At the time, taking on the job was at least as much about the opportunity for me as the worry about who they would pick instead.

I walked over to Steve’s office which I hadn’t been to since I was doing demos of the internet a few years earlier and immediately noticed it was different. The apparatus around him was much larger than the one around BillG, PaulMa, or MikeMap. He had a chief of staff, multiple executive admins, communications people, finance, and more situated in the same hallway. The worldwide sales team was much larger than the product group, spanned the globe and time zones, and involved thousands of customers and partners always seeming to need or want SteveB’s attention, of which he gladly offered. So this all made sense.

When I walked into SteveB’s office I received my familiar greeting, a bellowing “Sin-AHFF-skeee.” I remember the meeting vividly for no particular reason other than the ceremony around it was so grand and it really was a big transition for Steve and the company.

Without much small talk or easing into the conversation, SteveB started by offering me feedback about how I needed to be easier to work with. That my reputation was such that I ran Office [note, I was not running Office except for the past few months] in a way that made it difficult for people to get things from Office. To be sure it was a tight ship—that was how we shipped. Was he saying Office was hard to work with, or maybe I was hard to work with, or maybe I was hard to work with so Office was hard to work with, or perhaps the other way around?

It was a lot to take in, considering I thought I was there for a quick reiteration one normally sees at announcements like this. I expected to hear nothing would change, everything needs to keep going, and so on.

What I did not know was Steve’s context for saying this. What was he told he needed to do in terms of hitting the ground running? What were the immediate big problems? I knew for certain that BillG would always be pushing on more architecture, deeper alignment between Office and Windows, and starting work on the next release. I also knew that BillG would not have pushed him on the slipping or fantasy ship schedules that plagued the company.. Perhaps there were there already doubts about me in the general manager role?

I did fail to appreciate that Steve did not need guidance. He ran the field. He spent every day with enterprise customers. He was feeling their pain. In hindsight, and knowing Steve even better over time, I should have realized what he wanted to do was fix that pain as soon as he could. In a sense, he had been given the keys and wanted to drive. How often it is that a new manager or someone new to role takes such an approach?

I wasn’t exactly making a first impression, but rather I was being told what the first impression of me was. It was bad timing. It felt baseless or at least lacked actionable evidence. That’s almost always the way everyone sees unanticipated negative feedback—make it specific, make it actionable.

While I didn’t agree, I understood where he was coming from. Mostly what was on my mind was how screwed up everything was that the field was being told was going to make the next killer fiscal year: Exchange Platinum, Windows NT 5.0, Office9, plus our collective effort to compete with Lotus Notes (the field’s number one priority). Beyond that were a host of new enterprise products for systems management, knowledge management, database and storage, development tools, and more that were far from shipping let alone deployed by customers.

Everything we in the product group were working on had one common thread—it was late, off schedule, or worse not even on a path to ship and no one was fessing up. Maybe I was the only one who cared about ship dates (highly doubtful) but for sure I was going to be the one to say we’re living a fantasy if we think FY99 was a big product year. That’s right, everything the field was literally gearing up to plan to sell from July 1998-June 1999 was not going to be available. I was on firm footing because by now I was fully aware that the original planned ship date for Office9 was already upon us and we were going to finish March 1999. In other words, just a sliver of FY99 would remain and hardly enough time for enterprise deals to complete based on Office. And Office was the very best case among products it seemed (Windows 2000 shipped February 2000, Exchange Platinum/November 2000, SQL 2000/August 2000 and so on).

Everything was out of control precisely when the field was expecting a tight ship. The processes Steve had pioneered—the budgets from the field, the forecasts from headquarters, the business plans for each product that had been run up, down, and across the company, all culminating the country managers meeting followed by the global sales meeting—all presumed product team execution on a banner year of products, though many of the plans and communications from HQ were the kind that looked like tempering expectations without exactly saying so. The way this was done in the new enterprise model was to talk about the next milestone such as a beta test release or big customer event, instead of RTM of code.

Additionally, Steve was dealing with quality problems direct from customers (performance, reliability, early days of security). The flagship Windows 98 product was buggy. The flagship next operating system was very late, impacting server and client. Even with new products, new versions required time to deploy. Realistically, he was about to hear how nothing was going to get substantially better until at least FY00. All this, on his first weeks on the job.

And he was going to hear that from me, the reluctant new GM of Office, 32 years old.

In real time, I figured that the best course of action was to be more abstract than pick on my fellow product groups and offered what amounted to filibuster on the complexity of software projects. Steve was not new to big software projects, though the scale we were operating at was new for everyone. He personally oversaw Windows in the early days and then later LanMan. All projects back then were also late. I hardly needed to remind him, but it was on my mind. Recent Windows projects including the current NT5 were all late as well (NT5 was in development and ultimately shipped as Windows 2000 but took four years to finish, August 1996 through February 2000, an important and big release, but late).

My view, expressed to Steve, was two things. Microsoft products shipped late and that had to be fixed, especially in the world of LORGs (I went for empathy). Office was the most reliable of major products, but with Office9 we were already plus five months and that likely meant we could be as much as a year away from shipping, which meant Office 97 to Office9 was 30 months from shipping, or the outside limit of the delta between releases acceptable to customers. Beyond Office, Windows was late with every release after Windows 95 which was late enough that most long forgot the original target date. Often projects were so late there was not even agreement on the planned ship date or typically all that mattered was the next milestone such as completing a milestone build, beta release, or release to be distributed at a conference.

With late products came quality issues. With quality issues came the need for larger service packs and updates. With those updates came additional slips to new products under development, and so on. With those came even more disgruntled customers. Enterprise customers were newly demanding point fixes for specific bugs blocking deployment, a practice new to the company and inconsistently managed at best. The company was in a quality and execution tailspin, I believed.

Second, I really wanted to express my view of how fragile our Microsoft product processes were compared to other industries. We lacked a process to plan and commit that was uniform enough to enable collaboration across products. The plans that were in place were hardly more than sketches. When collaborations between groups did happen (I used Office 97’s work on Visual Basic as an example), they were efforts where personality overcame the organizational and planning hurdles.

Beyond that, the enterprise sales efforts took it as a given that selling the Microsoft enterprise platform meant selling the next release, making the release of the product, with contents as marketed, even more important. This introduced a fragility into the product development process. If something was discovered or learned, or a new customer understanding, then it was added to the schedule, but without changing any of the milestones or goals. If a product is late, it should be obvious adding more only made it later—every single developer new-hire received a copy of Frederick Brook’s The Mythical Man-Month, the established canon on software development processes. Yet the most critical teams were solving key customer satisfaction problems by just adding more code, later in the project, and dealing with that issue even further down the road. The new inability to cut features to make room for other features of a higher priority was a guarantee for even more fragile schedules.

It was this type of work process that made everything going on seem to hang by a thin thread, on the verge of spiraling out of control, if it was even under control in the first place. I tried to paint a picture for SteveB of “You want me on that wall. You need me on that wall.” I would not be exaggerating to say my tone was not that far off from the courtroom speech immortalized in the film A Few Good Men that every team probably saw for movie night.

I left the office feeling that what I said did not resonate. In fact, I felt like the idea of hanging on by a thin thread, which I viewed as a negative, was seen by SteveB in a more positive light. Almost like living on the edge was cool. Years later, the Windows Vista project frequently reminded me of this conversation, and frankly any number of projects between that summer of 1998 and the next decade.

Still, the tone that was set was not great. My monologue had not helped. I was already in (or put myself in) a penalty box, it seemed. The rest of the meeting was uncomfortable for me. I did not do well.

As the conversation continued and Steve started talking more about the organization and how he saw things. The framework he laid out made it abundantly clear (even) to me that he was already planning a reorg. It would have been naïve to think there would be no reorg with such a big change at the top, especially since the field organization all but formalized a yearly shuffle to align for the fiscal year. I thought to myself, when your new exec offers observations on the organization, the next step is an org change. Words to live by in the corporate world.

There would be a reorg halfway through the fiscal year but it would be talked about for months leading up to it.

I walked back to building 17 to focus on shipping Office9.

On to 055. Office 2000 is Good to Go!

Most tend to think of Microsoft strategy as the march from BASIC to DOS to Windows to Azure. While that is a robust external narrative, the more interesting view is how the company changed strategically and organizationally as we transformed from a consumer to an enterprise company. We changed from relatively independent (and culturally unique) Apps and Systems organizations to increasingly interconnected strategies with a growing list of top-down initiatives. The ultimate expression of these strategic goals came in the form of the transformation of the senior leadership who increasingly emerged from the System/Platforms teams. No single initiative would be a bigger symbol for top-down strategy, and execution failure, than unified storage, a grand vision for the one-database-for-everything technology providing the underpinnings for everything from email to photos to documents while scaling from laptops to servers. In creating Office9, Outlook was on the front lines of the start of this journey. This is the first of three attempts, but also the start of increasingly challenging strategic initiatives across the company. Working through and managing such initiatives proved quite difficult for me personally.

Back to 052. Alleviating Bloatware, First Attempt

During a visit to Japan, I ran across a new Sony laptop, the VAIO C1 PictureBook. What a wonderful machine. Crammed into a half a sheet of A4 paper in length and width was a laptop processor, 64MB of RAM, a 1024x480 screen, and a PCMCIA slot for wired or wireless networking. It also had a port replicator to support the new USB connector, CDROM, and floppy drives. It ran Japanese Windows 98. One of most distinguishing features aside from size and weight was that it was one of the first portables to have a built-in webcam. It was my new favorite computer.

I spotted this machine at Yodobashi Camera at Shinjuku Station, which was always my first stop after landing at Tokyo’s Narita Airport. In order to be prepared to meet with the Japan team, known by the corporate moniker MSKK, I needed to see first-hand what was on display at the world’s largest electronics store. Each year more people visit Yodobashi than visit Disney World. Among the hundreds of computers, cameras, home appliances, and everything imaginable, Sony reigned supreme. Something stood out this year. Sony products, including PCs, were starting to support a new kind of removable storage card, like the CompactFlash cards in use by the first digital cameras, but smaller and proprietary to Sony (I learned it was designed to compete with a new standard memory proposed by all the other Japanese electronics companies). It was called the Memory Stick. Sony had been trying to create proprietary formats and consumables ever since it lost the Betamax battle and this seemed the latest effort.

What was more interesting was how it caught BillG’s eye on his own trip to Sony meeting with Idei-san and Morita-san among others. He too learned about Memory Stick (and also the digital rights management features called MagicGate that he really loved) but more interesting than the storage technology was how Sony seemed to rally around adding new memory stick support to every product, whether it needed it or not. Camcorders, cameras, mobile phones, music players, televisions, and more were all outfitted with Memory Stick slots.

At some big meeting I was using my PictureBook during a conversation about Microsoft’s own storage technology, then known as Web Store (as in web storage, as it was going to be a place to store files in Exchange mail server that would make it act like a web server), and the desire for it to be used across all products. The topic wasn’t new, and we’d been going in circles for quite some time already because it was clearly too early and the technology was, as far as I was concerned far in the future at best. My skepticism frustrated BillG and those making the technology, primarily in the Exchange team where they were building the next release called Platinum. If that’s all too many codewords, don’t worry you weren’t the only one confused (This might be one of the few stories that even those that lived through it cannot agree on the precise terminology used and codenames as the technology evolved). Web Store ran on Exchange. Local Store was a similar technology that ran on laptop and desktop PCs providing symmetry between the server and PC. It was at first a generic term and then morphed into a project called LIS, local information store. These all represented the same concepts at different points in the evolution from 1998-2001, sometimes on the PC and sometimes on the server.

I made a semi-serious/semi-sarcastic statement about how we should all have to use Web Store the way that Sony was putting Memory Stick in every product.

Bill jumped on that comment in a way I did not quite expect, proclaiming something along the lines of “Yes, that’s called strategy. Why can’t we have that?” He wasn’t really asking. Oops.

The specifics of this technology weren’t as interesting as the fact that the company was really in a new phase. We began to have huge technology projects that were just getting started and before they were fully defined it was important for all the biggest groups, like Windows and Office, to sign up to use these technologies and make big bets on them no matter how irrational that might seem. There were faint memories of how Excel bet on Windows, but long gone were the realities of what it took to get that done and importantly that neither Windows Excel nor Windows itself quite existed when those bets were made. Now the bets were about replacing huge swaths of existing products—billion-dollar products—with unproven technologies with far-reaching, often abstract computer science goals. A key part about this new phase was a technology like LIS was talked about with customers and analysts, and even appeared in the press, long before there was even a plan or code, just boxes on “architecture” slides. LIS was solving problems long before it existed, so it seemed.

In the case of LIS, the vision was for all of Microsoft’s products, especially Windows and Office, to store data in a new kind of database that provided capabilities going well-beyond what the existing operating system for storing files could support. Eventually this storage system would replace files itself. In the meantime, the first goal was to store all the kinds of data routinely stored in Outlook, such as email, contacts, tasks, and calendars. This storage system, the APIs and protocol, would be built so it could run on a single laptop PC but also scale up to run on the huge Exchange server as well. LIS with Outlook was simply the first, and most important, step. Using LIS would imply a wholesale replumbing of Outlook.

Exchange was incredibly early in its evolution but was doing extraordinarily well. It was exactly the product every enterprise wanted and the synergy with Windows Server (as detailed in Chapter III) was proving an enormous business and strategic win. Exchange was building their next version, codenamed Platinum, with a major focus on scale and performance as customers were deploying the product to huge corporations with hundreds of thousands of mailboxes around the world. Web Store supported a new range of sophisticated data features, on the server, and was making real progress in development. In theory, the desktop/laptop LIS and the server Web Store would support the same features. This is how the main competitor Lotus Notes worked, called client/server symmetry. This theory was not supported by the way Microsoft’s efforts were being organized and built, but it would take a long time to surface.

Outlook was critical to Exchange success, and it too was very early in its evolution. While Exchange was experiencing growing pains in scale, Outlook was simply experiencing pain. It was a complex product that received lukewarm reviews at best, but it was the way to use Exchange, so customers put up with it. Outlook was called Byzantine in reviews, complex by our own Product Support Services team, and was taxing on the limited and expensive memory in typical PCs. Email was not just about Exchange, however, and Outlook also had failed to live up to the needs of the broader Office customer base that used AOL, internet mail, and more.

LIS was to be built by a partnership between the Exchange team and the SQL database team to replace the storage technology created for the initial release of Exchange. The fact that two big teams were building one piece of code for use by a third big team is noteworthy. One can begin to get a sense of how taxing this situation was on the individuals simply trying to ship their respective products by a predictable date with acceptable quality and performance. For all the institutional memories of Microsoft and IBM trying to coordinate building software, we seemed to be immune to thinking such problems would arise internally at Microsoft.

Those old enough to remember using Outlook might be familiar with an infamous file type called PST, which was the file that stored all the Outlook data (infamous because it was the precious place with all your email and yet also a file so big it was difficult to backup or copy). While Exchange was working at one end to scale mail storage to massive data centers for terabytes of mail, they were also busy trying to squeeze some subset of that technology onto the lowest power mobile computers of the day (like that new Sony VAIO). Outlook was supposed to simply replace what already worked with an implementation from LIS—replace the code that handled the most important and difficult to manage file on your PC with an entirely new technology. Sure, in a computer science sense with all the right layers and architecture, “it should just work”. Whenever someone says that you know it isn’t really the case.

This kind of architectural replacement is exactly the kind of thing BillG loved to hear. With the right API or interface, the new code just plugs in and everything gets much better. Yeah right.

Was this what corporate strategy is like? This was still the only place I’d ever worked, so I had no idea. If Sony was an example, it seemed kind of dumb. It felt like a tax on every group, not something useful. When you think of something you’re forced to do and have no say in, you think tax, and so this definitely felt like a tax.

For example, digital cameras were using standard CF cards and this meant Sony cameras would use a different card, and cards were expensive. If I was at Sony and was trying to beat Canon or Fuji, this sure seemed more of a problem than an advantage. Regardless of the quality of the idea or ability for a team to execute, they had much bigger problems like megapixels. Implementing a Memory Stick card added cost and complexity to a product but did not help it win in the market or solve existing customer problems, at least from the perspective of the team making a product. It was (and would prove to be) a strategy tax.

The biggest challenge of the release proved to be right where we left off with Office 97—getting Outlook to the finish line. That had nothing to do with replacing PST files and the vague scenarios that might come from the new technology.

The enormous effort to release Outlook 97 was followed by the organizational split and Outlook turning to a short release (independent of the Office product it shipped with) to gain traction with features required by the huge and growing number of internet email customers. Ironically, this was completely off-strategy relative to addressing the needs of Exchange customers, the very focus of our sales efforts and business strategy. In other words, the strategy Outlook was executing was disconnected from the overall corporate strategy. The short release, called Outlook 98, shipped eight months after Office 97 (and Outlook 97), in mid-1998. The internet support was beefed up, but that came at the expense of enterprise customers who got little from Outlook 98 even with a long list of issues and complaints. The immediate strategy for Outlook was working against the strategy from Office 97 of making Outlook an integrated part of Office. Go figure. This was very difficult.

The rest of Office9 completed our scheduled coding milestones just as Outlook was joining the project—right as we were winding down the project, Outlook was ready to start. The rest of the calendar for the project was supposed to last about five months and include two beta releases. All the Office teams, as a practical matter, were behind schedule, though Outlook proved an easy scapegoat. Unfair, but the last to finish received the bulk of the blame even when everyone was late. Symbolically, I struggled to maintain the hardcore shipping culture of DAD while letting Outlook slide through, breaking the spirit of the process by doing new work after the coding milestones. For me personally, this made me look like I wasn’t serious about shipping and importantly the Office product unit, OPU, was not serious. We didn’t have a choice. Besides, everyone was late. The risk was just making everyone even more late by acting so careless about Outlook.

Office9 declared code complete in March 1998, only about four weeks later than planned. Code complete meant coding milestones were complete, features were finished, and all that remained were performance and quality issues. But we were kidding ourselves. The project wasn’t code complete. Declaring code complete when it wasn’t was a violation of our own process. We spent a great deal of time figuring out how to adjust and what needed to be cut, focused, and rethought. We were not out of control. We knew what needed to be done. We needed more time, but a knowable amount of time. Any notion of slipping, even though the product would be what we had said it would be, had implications within the team, primarily schedule chicken. This is a lot of words to say that our execution was sloppy.

There were also deep concerns from marketing and ultimately the field sales organization. The business was in transition. In huge numbers, customers were moving to sign 3-year agreements with Microsoft where instead of buying just one version of Office (the current one) they would own all the versions released during the 3-year term. We were still working out the implications of this. For now, this seemed to imply that many newly signed deals were waiting for Office9. This meant a late Office9 was delaying deployment of a new 32-bit Office as those customers were still figuring out Office 97 after slow-rolling Office 95. What a mess.

With the development team declaring code complete, all of marketing became fully engaged transitioning from supporting the field on Office 97 to preparing to launch the new release. Immediately the press, and our own salespeople, dubbed it Office2K, or O2K (internationally some would call it “Office 2 oh oh oh” or “Office two zero zero zero”). That irked marketing. We considered Office 1999, but Y2K, year 2000 preparation (making sure computer systems were able to properly handle dates in the year 2000 without causing mayhem), was everywhere. An ill-prepared sounding name wouldn’t work (also all I could think of was Space 1999). So, Office 2000 it was.

Just as we named Office 2000, Outlook made a heroic transition from finishing Outlook 98 to figuring out how to quickly build Outlook9 (aka Outlook 2000) and align with all the initiatives, especially deployment and cost of ownership. For example, we rebuilt the installation and setup program for Office9 and had to find time to integrate Outlook, which ironically had rebuilt setup for Outlook 98 to use another new and different setup technology specifically for internet products (for Microsoft trivia buffs, this was called Active Setup and the new Office technology was called the Microsoft Installer (MSI), codename Darwin, which is still in use today).

The team hardly caught its collective breath. The whipsaw with which we treated Outlook’s strategic direction was in full force. Straight from focusing on consumers and internet protocols, Outlook swung the opposite direction to be entirely focused on enterprise features, which meant being a great mail and calendaring client for the next Exchange Platinum release. Kurt DelBene (KurtD), leading Outlook, partnered with Gord Mangione (GordM) on Exchange. Kurt switched the team from a crisis of internet protocols to a new crisis of Exchange protocols and storage: LIS, WebStore, and a protocol known as DAV (Distributed Authoring and Versioning.)

The huge technical problem for Outlook and Exchange to address was called always offline, which is an odd sounding phrase for email, which was all about being online. This meant changing the original model for using Exchange to a more internet-savvy architecture. Originally, Exchange was designed to work exceptionally well when connected to robust, high-speed networking. Unfortunately, that was almost never the case. When using a dial-up modem or a flaky emerging-market connection over ISDN or X.25, Outlook and Exchange routinely hung or often crashed. The internet, especially the WWW, was designed for a less reliable network and much of the success of those designs was this architectural decision and associated implementations.

Perhaps the most expensive possible way to demonstrate this design failing of Outlook and Exchange was when KurtD was offered a flight (actually summoned by the then CEO of Boeing, Phil Condit) on a Boeing Business Jet—the kind of plane used by CEOs and billionaires. The privately owned jet was a custom-outfitted Boeing 737 that cost something north of $30 million at the time and designed to seat ten or so people in posh comfort rather than the normal 150. One of the new features offered then was internet access, which over satellite was the perfect torture test for how bad Outlook plus Exchange could be. Kurt took a trip to Montana and back. A $100,000 trip for an owner, just so Kurt could experience Outlook not working over a satellite link. Boeing was one of the earliest and biggest Exchange customers.

The design and implementation proposed to address this involved reworking the way networking and mail storage worked in Outlook, which also loosely coincided with BillG’s strategic goal of building a fancy proprietary storage technology across all the products. The networking part was relatively understood. Rebuilding storage was made enormously complex by coupling the fix to a new storage architecture to the Web Store/Local Store (or LIS). From a competitive perspective, such storage functionality was the major advantage Lotus/IBM Notes held over Exchange. It was, therefore, a critical advance. In other words, the solution to this problem and to beating the main competitor were both wrapped up in what seemed to be a strategy tax.

The Exchange Platinum Release delivering this, also behind, was originally scheduled for some time in 1998/1999 (around the same time as Office9). The storage work had been underway for quite a while. When people study large organizations and want to understand why and how it is so difficult to do projects that span those organizations, a feature like LIS is a case study in great intentions, positive working relationships, but differing methodologies and approaches that make these efforts difficult to nearly impossible.

The Exchange team built out their processes for building and releasing software such that working extremely closely with a small number of customers early was the primary test of readiness. That work was relatively unpredictable because there was no way to ship without those customers signing off, so the process ceded control to a set of independent customers who held out for all the promised features for however long it took. This was the classic Systems, particularly Server, methodology that made any changes, specifically cuts, to the product plan costly in relationships with customers, prioritizing features over the date.

Outlook, as part of Office, was part of a methodology that made a product plan upfront and reevaluated the details at milestones, scaling back as needed in order to deliver on dates (even if these dates were never perfect). This date-focused methodology was rooted in the need to regularly update the product for retail customers or for business customers with multiyear agreements.

Neither of these were wrong or right in absolute, but relative to the major customers and business models each was appropriate. Outlook was caught in the middle.

This was especially difficult for BobMu, the new senior VP of our team, renamed to Applications and Tools Group (ATG). While most of the Server products worked in the Platform division, Exchange was organized in ATG specifically to bring synergy between Office and Exchange for email, and other products as well. Literally the organization was put in place to deliver on this strategy tax and that put me in the middle of it.

In reality (meaning in the code) solving this problem had little to do with using LIS. Many developers on the team thought using LIS to address this critical challenge was off base and simply wrong. The strategy, however, was about using LIS everywhere and using LIS in Outlook would somehow contribute to a much easier solution for flakey Outlook. This was a prime example of a strategy tax—being asked to take on a significant technical dependency while facing enormous product challenges knowing that this dependency doesn’t help solve those problems while those making the strategic call actually believed they were helping. One person who was not helping was me and I felt, well, helpless to support the team’s view that this wasn’t going to work or help Outlook. With the new organization the management chain was unified with the Systems view that the right way to solve this was for Office to just make the bet on the platform technology. It was my first time as a manager having to keep up the appearance of making this work while the team struggled. It was disempowering to put it politely.

Not only was there a shared Systems view of how the products should evolve, the recent executive organizational moves, in the midst of product plans already in place, only served to up the ante on this level of collaboration between Exchange and Outlook. The fact that the field sales group was briefed on the potential for LIS was another part of the overall squeeze on Outlook and Office (and me). Every time I expressed doubt about LIS I was told to head over to the Executive Briefing Center and “learn from customers”.

No amount of business strategy or management saying we needed to work better together could change the reality that LIS was simply not far enough along to support Outlook, especially with such a short schedule. The chosen design was too far away from being even functional, let alone performant. It was super tough, but it was the kind of effort where the further away from management the questions were asked, the more definitive the answer became “no way.”

Collectively, we needed to cut LIS integration with Outlook, and in doing so lose a significant competitive feature versus Notes, a strategic initiative for the company in data storage, a commitment to engaged LORGs, and a cross-group collaborative effort that many worked hard on. Any time a choice like this is made those close to the work feel a sense of relief, but those (almost always organizationally above) continue to blame others for the miss or assert it will eventually work. We collectively cut LIS. We were collectively relieved. To be completely fair, the actual engineers on Outlook invested little code in making this work and mostly went to meetings for a couple of months before this idea was abandoned. The real waste was minimal. We would not be so lucky the next time this strategy would be required. We took up the storage discussion again for the next release of Office (and the one after that).

The decision put the entire Office9 product back on track. Outlook9 moved forward with both feet firmly planted in Office9. Outlook wasn’t in the first beta release, Beta 1, a fairly limited test anyway. A few press leaks and first looks commented on “missing” Outlook. The larger issue was unwinding the communication with the Microsoft enterprise sales machinery, which briefed and effectively pre-sold LIS for some time. We received a good deal of heat for this type of change. The cost of winding up and then winding down the sales force on a feature that was high risk became a worthy lesson. It was especially problematic for the Boeing account team.

LIS was the first strategy tax for me and the team that also crossed into the field sales force, the press, and enterprise customers. It would not be the last. The company was changing, and the appetite for such unifying themes and grand bets across products was growing, even as our ability to deliver them was not. In fact, the strategies were becoming more complex and less likely to get delivered. It would have been good to have a single success at scale. To date, the most significant win (and it was huge) was the delivery of Visual Basic for Applications (VBA) throughout Office 97, which became a model of cross-division collaboration. We in Office would use this as the template for how things should work, while we continued the quest to make other strategies demanded of us live up to that example.

In Office we remained conflicted between making features that were easy to explain to individuals creating documents and investments that played well at the enterprise strategy level, even at the expense of individual end-users. In that sense, LIS felt a bit “too strategic” for me as I would often joke. Saying something was too strategic was my way of saying that it felt a combination of too abstract and too focused on the CIO slide deck, and also probably not achievable. The company was not confused. We were all in on enterprise, all in on strategy. We’d made that bet. Could we deliver?

On to 054. Steve and Steven Get New Jobs

What happens when your biggest strength and greatest asset as a product development organization becomes your biggest weakness? Perhaps that is inevitable. With so many potential disruptive forces, at least that’s what we were hearing, it was almost too much that the very thing we really excelled at—building new features—would become a problem. While the idea of software bloat or even the phrase bloatware was hardly new, it was being applied increasingly to Office. This is the story of the first attempt at doing something about this issue.

Note to readers: Substack introduced a new feature this week—free excerpts with the remainder of the post for subscribers. I’m trying this out to see what subscribers and potential subscribers think. I do welcome feedback. The proceeds of this work do not benefit me, and subscribers can also join in the comments and discussions.

Back to 051. HTML: Opportunity, Disruption, or Wedge

Features. That’s all we ever talked about. Adding features. Fixing features. Missing features to be added or fixed. Office achieved the position it achieved, as precarious as it seemed now with the rise of the WWW and Internet, by adding more features with more regular releases of new versions than competitors. Reviews focused on features and we won reviews. We had built a team, an engine to add features.

As fast as Clippy could appear after hitting the F1 key, it seemed as though our greatest strength and our most significant asset—features—had become a great weakness. We went from dominating with more well-executed features to being crushed by the perception of the weight of our products. The industry latched on to the expression bloatware to describe products that seemed to have too much—too many features, too many megabytes, too slow, too difficult to use, or simply too much.

It was one thing to develop a strategy to address a customer problem we had created, albeit inadvertently, when it came to total cost of ownership. We even committed to building fewer productivity features, despite the internal backlash over personal productivity moving to priority six. It was entirely another thing, however, to look at what we built and be pressured into admitting customers didn’t want or need it. Still, customers were buying Office by the tens of millions of copies.

Were customers, press, and analysts right? Did we have a product problem, a technology issue, or a marketing challenge, or some combination? Of course, the development team was certain marketing wasn’t convincing people how amazing the product was. Marketing was certain the dev team was not delivering business value. Press and analysts were relentless. What could we do?

Our hometown Seattle Times reporter, Paul Andrews wrote “already some have nominated Office for Bloatware of the Year.” While unclear who “some” were and knowing there was no actual award (thankfully), that was a sharp dig in an otherwise positive Office 97 review.

Worse, however, was the headline in the Wall Street Journal that simply stated “Microsoft May Face Backlash Against ‘Bloatware’” right on the front of the Marketplace section. The article used every possible way to explain the scale of Office as big from “two years and several hundred million dollars [in R&D]” to “appetite of companies for such programs” it did not let up. The requisite quote at the start of the article from an IT professional was brutal “couldn’t care less… there was nothing from a business point of view that was a compelling reason to upgrade.”  To this day I still get a sick feeling in my stomach from the box in the story stating, “Microsoft’s Office 97 contains 4,500 commands for features both useful and arcane.” Each of those features meant something we were so proud of and represented real effort. Plus, during the interview the reporter kept pushing for ways to talk about how big Office 97 was. I resisted and let this slip in a moment of pride, only for it to be used against me. I added this article to the binder I carried around and had it at the ready whenever the topic of bloatware came up.

Bloat was a constant source of strain in conversations with field sales, in the Executive Briefing Center, and with the press. Each time the topic came up I used my go to answer, which was that there is a set of features that everyone in Office uses and those are easily understood such as open, save, print, copy and paste, and a host of basic formatting commands. Everyone nods. Then I would talk about how each application has features that a few people use, perhaps footnotes, financial formulas, or animations in PowerPoint. Most would agree with that.

A common variant of this discussion was “your bloat is my crucial feature” or “yes this is bloat, except that one time a year I need to use it.” Most PowerPoint presentations are minimal when it comes to production values, except for that one time a year when the stakes are high and huge effort goes into making a great show. A favorite example is that few claimed to use Mail Merge in Word, until they find out they need to send out holiday cards or invitations to a large group (and yes, it even works with email!). Bloat rarely considered the frequency of use and often presumed infrequent use meant no use.

I would point out the significant business value of Office was that any person could use their set of features in any one tool and seamlessly share files and collaborate with someone way more advanced than they were. For example, I don’t know how to draft a contract and use “red lining”, but a lawyer could use those tools and send me the contract for review. Intellectually people understood, but almost always would shrug and still say that the software is “bloated”.

To each constituency, bloat implied something different. There were mundane answers like how much disk space or RAM Office took up. These Moore’s Law measures were easy to complain about but were especially incorrect relative to competitive products, Office was far and away the best. Unfortunately, no one ever experienced more than the one product they used so if Office seemed slow and all conventional wisdom was about needing to upgrade hardware with more memory or a laptop that ran out of disk space, then bloated Office was to blame.

Some believed that literally having too much stuff on the screen is what made the software slower or bloated. There was some truth to this in that the user interface of Office—the menus, toolbars, wizards, and more—was rapidly growing and exceeding the available pixels on the most common screen sizes, especially on new laptops. While desktop computers were getting larger monitors, laptops, still uncommon, were also a generation behind in the amount they could fit on the screen.

The industry analysts believed in something of a combination of all these factors. There was a view that the older legacy features of the product were weighing the programs down with old code, or cruft, and that if the product could just be “factored” [a technical programming word, to break the code up into smaller pieces] then we would have much sleeker and more tuned products that took less memory, less screen real estate. Analysts viewed the disruptive technologies of Java, HTML, and components discussed previously as somewhat magical answers to bloat. Frustratingly, many thought these new technologies not only made better products, but the results would be bloat-free as if by the magic of the programming language. In moments of frustration I would point out the obvious, that if a product didn’t do very much it would of course be less bloated. There’s a good lesson in potentially disruptive technologies in how all the positives flow to them and none of the negatives, with little proof along the way.

These stories and definitions of bloat were endless. I received letters, emails, and every Briefing Center visit offered more anecdotes. It was exhausting. Perhaps the worst part about every one of these encounters was that after complaining about bloat, the customer would invariably start talking about new features in the product they so desperately required. And as if to rub salt in the wound, a good portion of the time these requests were already somewhere in the product submerged in the user-interface.

We had a good deal of intuition about bloat but not a lot of hard data. While we had our instrumented studies and knew without a doubt that much of the surface area of the product was used in practice—in total, not by any single person—we were working with limited data sets. It would not be until the next release that we would greatly expand our use of the internet to understand real-world usage.

When companies in the 1990s needed to understand customers, they did focus groups. Researchers fanned out around the world on a series of focus groups to better arrive at a shared meaning of bloatware. While we did not learn anything new, we did obtain some more anecdotes and lots of hours of video tape of people complaining about the product.

We had to do something.

One way we reduced the perception of bloat was to not install less frequently used bits of Office on the hard drive, and rather to install them on demand. This was a feature designed specifically for IT professionals who were touting the advantages of disruptive components. In every story about components, especially those built with Java, the idea of loading features as you need them “on demand” was an advantage. The Total Cost of Ownership efforts built an entire infrastructure to load less frequently used features in this manner, conserving disk space, not bothering anyone. IT professionals hated this in practice and immediately loaded everything on the PC to avoid any “on demand”. Exasperated, we learned the idea that someone (mostly an executive) might be on an airplane wanting a template or a help file that was not loaded on the PC and seeing the “Please Insert Your Office CDROM” error message was unacceptable. Why take the risk, they would ask, it was just some extra disk space!

We really wanted to do something about the feeling of bloat. How could we make Office feel lighter weight, less overwhelming, and more approachable? Hanging on an interior office relite near DHach’s office the whole release was an old cartoon from a tech magazine titled Office 2000 proclaiming what a future word processor might look like. The drawing was of a Word document surrounded on every side by toolbars, buttons, widgets, and more—almost the entire product screen was consumed by interface widgets with a tiny little spot to type. This really was the bloat we needed to fix. But how? We knew the features were used and we couldn’t just delete them.

A common refrain from focus groups and our own intuition was that customers really wanted Office to be tailored to their own usage patterns. It seemed obvious that if Office just knew what customers wanted to do and only presented those options then it would be more valuable, rather than pushing a bunch of features that might confuse or slow down work.

Rooted in our own history was a hint at a possible answer. A decade earlier, as the early Macintosh and first Windows versions of Word and Excel were being built, the teams implemented a feature known as Short Menus. This was an early answer to a common PC paradigm of sort of a beginner and expert mode. Even Macintosh had two modes for the desktop, a standard one and a simplified one called Simple Finder. Short Menus would show only the most common menu commands. One could easily choose a menu command (the irony was not lost) Full Menus to show off all the possible commands in the product. Switching back and forth could be done by just choosing the menu.

This was supposed to make the products more approachable. Instead, it just introduced another menu command that made little sense and added a step to using many commands, assuming one even knew to consider this modality in the first place. This idea came and went with the early PC era, along with the idea of expert modes.  As the products evolved and added toolbars, the idea of simply hiding menu commands made little sense given the importance of toolbars. But toolbars also contributed to a bloat perception.

DHach who was leading the user interface program management team in OPU, along with a college hire from Cornell, Mike Arcuri (MArcuri), created a new interaction model based on an idea originating on the development team. We were certain they helped reduce bloat. We called this IntelliMenus (as in IntelliSense) or smart menus as a working name, and ultimately marketing referred to them generically as intelligent menus. The implementation was a smarter take on Full Menus/Short Menus, and also applied to toolbars. It built on our investment in the unified codebase for menus and toolbars that was working so well for us. It was clever, intelligent, and used our code architecture well.

The Office9 feature was subtle. First, it was always on. By default, the product curated short menus; based on the instrumented studies. We were confident of what was used frequently. Second, MArcuri created a series of heuristics to determine if a user might be intentionally browsing for a command or lost trying to find a command, and at that time the short menus or toolbars automatically expanded to full menus. A user could also click on what looked like an arrow key to manually expand to full menus. Intelligent menus were an IntelliSense answer to the age-old idea of having special modes that were hard to find and often confusing, and instead they learned from how the product was used and adapted over time. We built a personalized Office.

The feature proved attractive in early previews. In press briefings, we were lauded for taking on bloat and no longer ignoring the rampant problem. While most feedback was positive, as we expected, in beta feedback those who understood the product felt this was a bit of a who moved my cheese? scenario. Interestingly, the OAC representing LORG desktops had a unique take—there were some views suggesting that the shorter menus be permanently on so as not to confuse people, along the lines of the old short menus feature. Others were concerned about the training costs and, in particular, what a how-to call would be like if the person at the other end of the phone could not be certain of which menu items or toolbar buttons were visible. Hypothetical calls were always based on a VP calling at odd hours on some important trip with little time to spare. Again, as with the trendy on-demand, the reality is the enterprise IT world aimed for stability and completeness over anything dynamic or adaptive.

Smart menus were a solution to take on bloat of known features. They did not solve the challenge of discovering new features. We were keen to add new features as well as make the existing features easier to use. That included how Office could better support creating documents by gathering up information from the web to create a document. Researching a topic of interest changed dramatically with the WWW. Instead of writing memos or slides from paper notes or cards, research was increasingly based on browsing web pages and stealing bits and pieces from around the WWW. The workflow for this was incredibly difficult: see something on the browser, select and click copy, and then back to the document to click paste, over and over again. Taking a few different parts from the same document was a window-switching pain. DHach’s idea was to be able to just keep clicking copy, select more content, copy again, over and over without returning to Word to paste every single research find. Then when ready, the user went back to Word or PowerPoint and clicked paste, paste, paste over and over. This was also a great use of HTML because the formatting from the web could be maintained (at least with Internet Explorer).

The Office clipboard was a fantastic demo showing integration across Office and any browser and even other applications. The brilliance of the feature was that it created a whole new scenario without adding more menu commands (no bloat) or new features to learn, sort of. The feature activated if the user copied twice in a row quickly and no one did that by accident. We were, however, quite stuck on how to make this feature more discoverable so the user would know all those bits were sitting in a magical clipboard. We were constrained by perceptions of bloat, yet like so many new features, we needed a way to surface it to customers and decided to take the same route as AutoCorrect, which was a minimal user interface.

The Office Clipboard was a notable example of a feature already in one product (Word at least) and then added to all of Office but was routinely requested by customers. The feature was demanded so frequently that there were dozens of separate add-ins, products, and downloadable tools that offered a shared clipboard feature. As was often the case, when a feature was part of a large and complex product bundle it was often easier to find a separate, stand-alone tool that did what was needed instead of finding the feature in the big suite.

The struggle of discoverability and bloat continued to be enormously challenging for Office. It was fascinating how our skills at creating features exceeded our ability to make those features discoverable or create a product overall that remained easy to use for the broadest set of customers. This was an existential problem for our business as the WSJ pointed out— “One worry is a market nearing saturation”—if people have the product and feel it does everything they need, then our business is shrinking.

This kept us up at night, but not for the business reasons as much as the reality that we just knew people were constantly asking for Office to do more and to make it easier and faster to get work done. I used to say “Office 97 is hardly the ultimate achievement in creating, analyzing, and presenting information. We know we can do better.” We were primarily competing with our previous version—also bloated with all anyone might ever need—and that proved to be a tricky situation. This was especially difficult in the enterprise market where the benefit of any new feature was weighed against the cost and challenges of deployment and re-training. Given the investment customers made in that prior version, we were limited in how much we could market against it. It was not lost on me that the competitors we did have (Star Office, SmartSuite, Perfect Office, and Arae-A Hangul and Kingsoft WPS outside the US) were consistently adding features we already had and touting them as new. Each was making the mistake of competing head-on with the incumbent. It would be years before a product would take web-based productivity tools in a different direction.

Otherwise, there were no lean or unbloated alternative products people could point to that were in use. There’s much more going on to bloat that we would need to discover. What was the relationship of Office to Windows, and the rest of the PC? How were PC problems such as grinding hard drives, degraded performance over time, or just flakiness, bugs, and instability related to bloat? How much of the problem of bloat was being caused by enterprise IT software that people disliked (who likes their work software?) and worse the security and management tools that took ever-increasing control of the PC. The problem of bloat is bigger than just Office. It was the product’s ubiquity and, frankly, high customer satisfaction (no matter how we measured it) that made it a symbol of a much broader challenge for Microsoft.

In this work, I want to share the lessons with plenty of context and not a lot of certainty about how lessons might apply in a different context. The notion that products get easier to use and more approachable simply by hiding or deleting features is something I’ve seen disproven repeatedly. Rarely can simplicity come from simply hiding capabilities that people use, and in fact as we saw in this story, often in the process of obscuring features the product becomes more difficult to use. Lesson learned.

I wish I could say that slowed our feature machinery, but it did not.  We were doing more than ever, faster than ever, but we were at least more aware of the challenges we were faced and every day becoming more empathetic. The dialog around adding features changed from how fast to how well, from must have to will it work. We were maturing as a team. This became more important as the demands for features to support broader, and much less clear, strategic initiatives increased as we built Office9.

On to 053. Strategy Tax: Outlook Storage, First Attempt

While we knew the time was wrong to build a whole new Office out of one of the new disruptive technologies, we did need to arrive at a strategy for HTML. After the debacle of the file format changes for Office 97, the allure of HTML was everywhere. The enterprise customers we intended to impress were fed up with the traditional (and ever-changing) binary file formats in Office. HTML had achieved the status of “magic beans” and could solve any (and all) problems. But how?

Back to 050. The Team’s Plan in the Face of Disruption

First thing Saturday, 9:44AM December 5, 1998, so might as well have been 5:44AM, I received an unsolicited mail from BillG subject line “Office rendering” and copying the full management chain in case they weren’t busy that morning. I joke, this was normal even though Bill had been increasingly focused on broader issues lately. For some reason (no context provided), Bill read something somewhere that gave him concerns about the use of HTML in Office. We already had a plan, which he knew about but was now having second thoughts or something. It was not unusual to have to back up and go through our logic and approach to get to an admission that we were not nuts, or perhaps to tweak something. This was a big issue though and cut to the core of our second highest priority in Office9, “HTML in Office9”.  Bill had some concerns, to put it mildly.

When we changed the traditional binary file formats in Office 97, we caused a real disruption in work. Suddenly files were being emailed within and outside the company and they simply couldn’t be opened if the recipient had the wrong version of the application. Worse, even if a converter was available there was a pretty good chance after a few edits the document returned in email would look funny or even wrong. What had served our industry so well—the binary format that represented the internal data structures of each application—had hit a wall with the combination of email and slow deployment of the latest version of software. Without new file formats we were really stuck because every new feature was represented as a change in the data structures and file formats. That’s just how things were done.

The browser and HTML were the cool new thing, but they also held out a promise of a universal platform for viewing documents. Enterprise customers and industry analysts were enamored with the idea that HTML was a resilient, text-based format. If people used different browsers, they could still read documents with just a few formatting hiccups and all they needed was a browser and not some expensive new version of a productivity tool. Plus, everything just seemed better in a browser, better than the old File Open dialog, connecting to network drives, endlessly navigating folders in hopes of finding something. Just click on a cool blue link and up pops the most current sales numbers or marketing plan. Little details like being connected to a high-speed internet from a laptop, something that was nearly impossible outside large office buildings in major cities, would take years or a decade, to address.

We knew all this. Solving these problems was our plan. The big problem? No one knew how those cool documents that were so easy to read, so resilient, so friendly, so snappy, and so much better could be made. What tools would typical knowledge workers use to create web pages? What server would they be stored on? Our strategy: Office and FrontPage.

Even if we had some ideas, there were many questions about the role of Word and PowerPoint, and to some extent Excel, given the increasing preeminence of browsing. In a world of browsing web pages created with the relatively simple formats in HTML, where and how would tools designed for sophisticated print-formatted documents fit in?

The most complex cross-group feature of Office9 was the second pillar of the vision, HTML file creation. Demonstrating that these large apps could be relevant in the face of the WWW was a major part of our strategic challenge, especially within Microsoft.

Our choice not to do browser Office, Java Office, or components of Office was a big miss for many in the company who saw those technologies as synonymous with embracing the WWW. The answer in the vision (and in High Hopes) was using Office to participate in the WWW, using the apps to create HTML documents that could be viewed in the browser. In a sense, this was turning the WWW into a giant online printer or document repository for businesses. FrontPage powered this ability to publish documents from the desktop PC—we called it the two-way web.

A response to potentially disruptive technologies is for the incumbent product to do a bit of a jiu-jitsu move and attempt to turn the disruptive technology into a feature within the product—rather than build a whole new product out of the new technology, embrace the technology as part of the existing product. That’s what we were doing with HTML. Rather than rewrite Office in HTML, what if we made HTML a feature of Office? Strategically, some might view this as defensive and certainly not as dramatic as turning the existing business inside out or upside down, as championed by some. The bet was as theoretically cool as Office in HTML might be, and realistically we were a long way off from browsers being able to do that. Even with Internet Explorer rapidly gaining share and Netscape seemingly unraveling, we were years from Internet Explorer dedicating their efforts to building productivity tools like Office on the browser platform.

Our Office Advisory Council was extremely positive about HTML. There was a huge wave of effort at large companies (the OAC represented over one million desktops) surrounding questions about how to use the browser for intranets for collaboration and document sharing (like our http://officeweb). OAC members loved the idea of having a focus area beyond deployment and administration aimed at LORGs because it gave them a seat at the strategy table, not only operational efforts. They were excited to be evangelists of creating documents with Office that could be viewed in a browser and easily saw potential for solving their document distribution challenges.

To make this work, we needed to do a crazy amount of work to twist HTML into representing as much of Office capabilities as we could, no easy task. We knew ultimately our goal was to move to HTML as a fully native file format, meaning it could be used in place of the de facto standard .DOC, .XLS, and .PPT. The capabilities of HTML were rather spartan compared to Office and difficult to work with. HTML was designed for minimal online documents in a browser. Office handled the myriad capabilities for print documents and sophisticated online presentation. Myriad is an understatement. Typically, people think of Office in terms of document formatting commands, but that leaves little room for even basic formulas in Excel, or presentation template semantics in PowerPoint, or even the simplest of page footnotes in Word (just to name a couple of examples out of thousands I could list). All of those would need some representation in HTML as well.

This is where my view diverged with BillG’s view. Having gone through the painful Office 97 transition and not wanting a repeat, I saw our file formats as a liability—something to mitigate. BillG saw them as a significant asset, a proprietary asset, and he loved proprietary assets. File formats raised the switching costs for customers who would move to a competitor. He was right. Unfortunately, our biggest competitor was our old version and what we were inadvertently doing was raising the barrier for customers to upgrade (also known as buy and deploy) the new version of Office.

While we often had disagreements, we didn’t often see things as so starkly opposite. BillG had historically focused on those proprietary levers because that’s how the industry grew up. All products were open because everyone was building a platform, while at the same time those points of openness were “protected” by proprietary defenses. An API, user interface, data formats, programming language, were all combinations of wide-open platforms and proprietary elements.

When the topic of HTML as a file format came up in strategic conversations, especially with BillG, the discussion quickly turned to a view that HTML implied ceding strategic control of file formats to either a competitor or to what might become a standards body—that was the worst of all outcomes. Seeing this type of situation, as an advantage or risk, was something BillG was always good at. While I might have personally recoiled at the idea of having something proprietary simply to have those control points in the product, it was not just good business, but the kind of business routinely practiced across technology. In an era of open source, proprietary innovation is often viewed as old school or passé, when in fact it is more vibrant than ever (behind today’s cloud is all open-source software made proprietary by remaining in data centers).

The debate for Office9 was far more grounded because the current state of the art for HTML was so limited. The most recent innovation in HTML was the addition of tables, enabling many scenarios, such as presenting financial data in a spreadsheet fashion, though they still lacked most of the formatting used in Excel. More interesting was a great lesson for me in how rapidly new technologies diffused when there was an incredibly strong demand to improve them immediately. Every content website, those trying to show stories like a newspaper or magazine, struggled with the most basic formatting problems while trying to get something, anything, that looked reasonably professional to display in a browser in a reliable way. With the original specification of HTML, most sites looked a bit like ransom notes—lots of colors, font sizes, bullets, and that awful blinking text. That’s all that people had to work with.

Tables were designed for presenting data, tabular data. Quickly, web developers realized tables were perfect for placing text on the screen in precise spots. They could be used to create columns like a newspaper, or place photos such that text wraps around them, or even nifty tricks like headlines that span columns. Suddenly, sites were using tables to make fancy documents. These did not look like tables one might see in a statistics book or financial report with bordered rows and columns, but what could be seen were aligned text, spanning headlines, and images with wrapped text. Many web purists were troubled by this because the purity and simplicity of HTML were lost. In practice, this abuse of HTML, as I called it, also made it difficult to realize many of the benefits of the web like processing documents on servers, automatically generating documents, or even searching and indexing documents as Yahoo was doing. Tables made HTML more complex, but they also made sites look great in the browser. In a sense, HTML was evolving to be a complex file format tuned to online documents. Not what the original creators intended, but it was the browser makers who started calling the shots.

Tables were an opportunity for us. They made web pages more complex, making things more difficult for everyone but nicer for humans reading pages. Office tools were perfectly tuned to handling complex user interactions to create nice-looking documents, which could be seamlessly represented in HTML all while editing in Word as one normally did.

Much to the dismay of purists, HTML was quickly becoming an implementation detail that few humans would deal with directly. Computers could easily absorb the complexity while the human just worked with a tool. Office was a great tool. We received many requests to convert Office documents into HTML documents, especially from small businesses and students. While HTML was originally simple to use, perhaps even a bit like using WordPerfect because of tags or codes, as WordPerfect called them, doing anything one could do in Office was impossible. Professionals were using tables and creating increasingly difficult-to-code sites. There was room for Office to make this easy.

Our strategy was to make the most we could of HTML to publish documents, essentially thinking of HTML as an online print command. Program management fanned out across the products to map formatting capabilities of each product to capabilities of HTML. At one end of the spectrum was PowerPoint, which could always save an entire slide as a single image, as was done by early third-party tools. For PowerPoint, though, this lost out on animations, scaling or selecting text, and the richness of the tool. Tables were a perfect way to maintain the layout of slides in a way that worked much better with browsers. PowerPoint had an early start on converting to HTML and was already pushing the limits of what could be rendered in a browser, but it was fantastic. Slides that acted like real web pages where you could select text, resize the window and scale the slide, and even use full screen presentation view.

At the other end of the spectrum, Excel saw little value. Was this another case of “Excel users are different” and trying to foist a one-size-fits-all OPU consistency on to Excel, or was there real utility? One look at what was being published on early websites and one could see the same type of needs that the print world saw, which was that Excel was used to create charts, graphs, and numeric tables that were then incorporated into Word documents. Some of the first uses of the WWW were sharing corporate financial filings, tables of income statements, and balance sheets. While we could push all this work to Word with copy/paste, most of the time that rendered Excel tables as images, making them difficult to print, select, and scale to different size screens. We decided that Excel needed to be an equal citizen in saving HTML. This also made our Office consistency story stronger.

Word’s opportunity was larger, primarily because most people saw what was in the browser resembling Word documents. Just as most of what we read in print was originally created in Word, the early internet was taking on those same characteristics. Leading the efforts on Word’s program management team were KayW, who had early on recognized the power of web authoring for Office, and Eric Levine (EricLev). EricLev started his career at Microsoft in marketing after college where he was coxswain on the Harvard crew team. A giant oar adorned the wall of his office (always a pain when he moved offices). Together, KayW and EricLev drove much of the strategy across Office for HTML. Coincidently, my office was between them, putting me literally in the middle of the HTML strategy.

Kay and Eric were strong proponents of developing what was called round-trip HTML, which meant Word created brand new documents (or read in old documents) and saved them as HTML and later opened them again to make changes. HTML as a first-class format, not only a publish-only format, was as brilliant as it was difficult. As an example, consider something simple like a page header. On a printed page it is obviously a header centered, but how it got there could be the result of many different paths, and to open a file for editing later we needed to preserve that path. A centered heading could be created by hitting the center button obviously, but it could also be centered using tabs, changing the margins, or even putting it inside of a table and then adjusting the table. The text itself could be formatted using the bold button and font size, or it could be adjusted with the Heading style. Looking at an entire printed document and thinking about the permutations for every bit of formatting quickly boggled the mind.

The complexity of simply copying and pasting formatted text from one product to another was already mind-boggling—and an ongoing source of frustration, product support calls, as well as a competitive problem. HTML was an opportunity to improve because all the products worked on supporting the format at the same time. The clipboard, where information is temporarily stored, relied on an age-old format called RTF (rich text format) that many tools supported, but unevenly. If all the tools supported HTML natively, there was a good chance sharing data across tools would improve. That was our plan.

Solving any problem in Office across the main applications was an enormous task because there was so much history. The product, even in the late 1990s, had thousands of features. But HTML and keeping track of all the formatting and how features were saved in files was a next-level effort. KayW and EricLev amassed an incredible amount of knowledge about how HTML was implemented across the products. It worked so well we found many places that browsers were not ready, or, according to the browser teams (including Microsoft’s), we used features in unintended ways. For example, saving a spreadsheet could easily create a table that essentially caused the browser to choke on too many rows or columns. New browser features used by PowerPoint were unevenly implemented across different browsers, making slides show up incorrectly depending on the vendor or version of the browser. Professional web designers were experiencing these same problems in their handcrafted web pages, which they would debug by trial and error in different browsers.

These problems led to the rather heated and ongoing debate between BillG and me. He was itching to tell me, “Told you so.” He saw an opening because he believed we were limiting ourselves to a lame foundation. I saw the foundation as moving rapidly and one we could exploit. He saw the foundation as one that would constrain us and commoditize our product.

Bill was nervous about using HTML because of the loss of proprietary features. Would HTML be slower? Would files be bigger? Would it be easier to clone Office if we constrained it to only features the browser could render? Would fewer people buy Office and rely on a small set of licensed users to do document creation while others skipped buying Office to use a browser? These were not just good questions, but they were all answered in ways that made the strategy appear flawed. My view of the strategy was simply that the browser was happening, and either Office created content for the browser and remained relevant or other tools, not Office, created documents when they needed to be viewed in a browser. This was a ride the horse in the direction it is going strategy.

Bill’s mail to me that Saturday morning generated a response from me. That’s how we always worked together. Writing long detailed responses to even polarizing assertions was kind of my thing. Bill’s thing was poking staccato style with a list of assertions, an argument. My replies were many paragraphs with context, pros and cons, and conclusions. I often included screen shots or supporting information. I did that quickly. If Bill’s approach was to “shock” then my response was to “awe”.

In this case, Bill’s shocking email was more than enough to garner interest by the antitrust regulators and our trial—one of hundreds of mail threads that were entered into evidence of Microsoft’s monopolistic behavior. We weren’t thinking about that on Saturday morning. My reply only showed the tension and, in a sense, amplified the negatives of his comment. This thread was just one of so many like this. The most mundane conversation memorialized in email just never goes well. Mark my words.

Bill’s provocative statement was definitely dramatic, but typical:

[A]llowing Office documents to be rendered very well by other peoples [sic] browsers is one of the most destructive things we could do to the company. […] We have to stop putting any effort into this and make sure that Office documents very well depends [sic] on PROPRIETARY IE. Anything else is suicide for our platform. This is a case where Office has to avoid doing something to destory [sic] Windows.

Things were not that bad. But I somehow managed to make them worse, especially in the eyes of the regulators. Because of the variances in browsers and our desire to use HTML, we were working well with the Internet Explorer (IE) team as we looked for ways to maintain an edge over Netscape in rendering documents, and maybe Netscape was not all that keen to work with us. The potential flood of Office documents seemed like an opportunity. On the other hand, rendering better in IE than in other browsers could also be perceived as a corporate initiative.

One person’s strategy, however, is another’s nefarious plot.

My reply:

For all practical purposes, Office 2000 requires Windows and IE. We started the project trying to be great on all browsers, and even greater on Internet Explorer (from our vision and presentation we did for you), but the momentum inside the company essentially prevents that message from making it through development.

That was what every observer’s worst nightmare might have been. The momentum inside the company was solidly behind IE, as naturally expected—no one was thinking about helping Netscape. Office didn’t require IE. Rather, IE was the only browser interested in what amounted to standard use of HTML in Office. The trial offered up some of the many times Office and Netscape tried to work together, but it is not difficult to imagine that went nowhere.

BillG would almost always default to a proprietary solution as I had learned in our very first meeting when we discussed C++ and his desire to extend C++ to make it easier to create Windows programs. That point of view was most effective when the playing field was level. The tables had turned, and Microsoft benefitted from the use of open standards. The risk was low as I tried, but not so successfully, to explain.

We finished the release with an incredible implementation. The demonstration included being able to have incredibly rich documents in Word, Excel, PowerPoint (and Outlook with fancy email that could read by any HTML mail client) saved out to a web site running FrontPage. We did have endless debates with HTML purists who absolutely hated how we “abused” HTML. In demonstrations with that crowd, I was routinely asked to show the resulting HTML which was not human readable. This aspect of our implementation was well ahead of its time, as today even the source to the simplest web page is impossible for a human to digest without tools. Everyone abuses HTML.

For much of the project, BillG and I went back and forth in email. History was not entirely kind to either of us in this debate—while we both got elements right, ultimately where HTML and Office ended up was kind of boring, albeit successful. Given that most reading this never directly experienced Office using HTML, I should fast-forward a bit and finish the story.

To this day, Office is as widely used as ever, and it continues to dominate any other document creation tools. Word, Excel, and PowerPoint ended up contributing massive amounts of information to the WWW, as neither .DOC/.XLS/.PPT but rather as PDF, Adobe’s ancient portable document format, which is essentially a printed version of the document.

Nobody expected PDF to dominate. It was some combination of the deployment cycle of new Office apps that supported HTML, lack of awareness that Office could produce HTML, and especially a lack of ways for regular people to share Office as HTML. The biggest thing PDF brought to the solution was a single file, that always looked the same and looked exactly like it would look when printed. The problem we could never solve (and we tried) with HTML was how to deal with the explosion of files such as pictures, charts, illustrations, and so on typically found in Office documents and intrinsic to the browser.

There is some irony in this endpoint. These portable document formats were my first project when I was Bill’s technical assistant, a hand-off from my predecessor. AaronG and I both thought PDF was potentially super useful (the Acrobat product was new when I became TA). Bill disagreed then for the same reasons HTML with Office was considered not the best idea—he wanted to see Office’s native formats. For any number of reasons, PDF never became the liability he thought it could become. My dream of HTML documents created in Office, showing up in browsers, never quite materialized. Neither of us got to an end-state we wanted, but Office remained relevant. That is an advantage to product-market fit.

HTML proved to be enormously beneficial as the underpinnings for an entirely modern and newly designed Office file format, Microsoft Open XML, which became an open standard and eventually used by other products (and was regulator friendly). HTML was also instrumental in making copy and paste across Office, and from browsers, vastly more reliable. Word can still publish to HTML, and it is still pretty nifty.

We were both partially right. We were both also quite wrong.

On to 052. Alleviating Bloatware, First Attempt

With the looming threat of disruption, at least according to everyone at the company and the desire to get moving on adding new features to the apps, there was a need to have a strategy in place. Putting together a plan is never easy, and at Microsoft in the late 1990s you’d be challenged to find something that looks like a complete product plan combined with an execution plan. Starting from Basic for the Altair through DOS for the PC and even Windows itself, Microsoft asserted what a product was with little more than a meeting, some slides, or just an announcement or commitment. Execution often fared no better with even our best products, as we have seen, shipping a year or years later than expected. Even the Office apps individually, while having the best executed plans, had not yet combined that execution across the apps into a plan and execution for the suite.

What follows is the story behind my favorite process that we developed and honed over every product release that followed Office9 and ultimately Windows—affectionately called “the vision process”. It is also a real lesson in culture and how even with well-documented artifacts and tools, delivering and executing was really a product of the people.

Back to 049. Go Get This Rock

Leading the plans for Office9 placed me decidedly in the role of the incumbent in the context of “technology disruption,” as was being thrown around the hallways (or thrown at me). We were moving forward with a plan that was either going to work or prove to be one of the biggest cases of disruption ever, not to mention biggest mistakes ever made for an incredibly successful business on a huge upswing. Therein is the most counter-intuitive aspect of this plan—almost no one on the outside would think we needed to do anything to “save” Office, and everyone on the inside had wildly different theories on how we must save Office, all relying on nascent (at best) technologies.

I committed to create a document outlining the plans, a vision, for the whole Office9 product and my self-imposed deadline approached. The High Hopes offsite and memo turned out to be a draft, which was helpful. When I wrote the Priorities and Processes for Office9 that declared there would be a unified plan for the release I didn’t quite know what I had signed up to create. The offsite and accompanying memo were clarifying.

The bet the product team made was on transforming us from a machinery adept at making new productivity features for individuals—IntelliSense, formatting, document creation and editing—to a new execution machine aimed at creating tools for a whole business. The cost of entering that market as a leader was to significantly improve deployment and manageability, or said another way reduce the total cost of ownership. The features we would aim for were not personal productivity features that saved minutes, but business features that saved teams hours and saved IT headaches and dollars.

In other words, the plan for the product—the vision—would completely upend the historic priorities for the product. This was a big change years in the making but faced with a single moment, the distribution of the plan to the complete team, to most the change would happen suddenly. While we were busy easing a group of 50 or so senior managers, the other 1500 people were mostly hearing rumors while they were busy working on their own team’s features. There’s no easy way to make a big change in a big company.

I took what I wrote for High Hopes, removed the defensive tone, and made it much more forward looking, focused on what we planned to deliver to customers, detailing the state of the business, and how we would work. It was an exciting document, if not a bit overly poetic as I’d not yet found a style for these. I wrote it using Word’s Internet Assistant and would eventually post it in HTML to our new http://officeweb running FrontPage sitting on a machine in my office. In 1997, almost nothing was written for an intranet website. The text was in the new sans serif Verdana font, blue with a muted yellow background, as I tried to make it look cool like a web page. It was rather unreadable and mostly unprintable, and with Office 97 copy/paste from the browser really did not work yet. We learned quite a bit from forcing ourselves to use web technologies in this way.

It is important to the process to understand that the past few months were spent in offsites and meetings, and a host of cross-team efforts, arriving at features that would be done by each app and the shared OPU team. High Hopes itself was a summary of what we had iterated on up until that point. This is the heart of what is meant by the Office process of “the best of top-down, bottom-up, middle-out.” The vision is not a news event when individuals see their own work and their features, but a chance to see what the rest of the hundreds of people will be up to. It is also a tool for the all-important process of adds/cuts—when each team (or feature team, the smaller unit of a team within an App team or OPU) figured out what they could really do with the resources they have. Thus the document also served as a check on resource allocation—ensuring the people where the work is needed.

This ongoing iteration within a decision-making framework is sometimes depicted as a funnel in consulting diagrams—lots of ideas come in and a process narrows them down. I think of it as a refinement with increasing levels of specificity. This refinement is also what leads to accountability. By the time the vision document is in the hands of the team, not only is it a reflection of the best efforts of the teams but it is also an execution plan, and it is also the accountabilities for the team. There’s a development schedule, at least the first cut, and a target ship date. The vision document itself is not a refinement but a summary of the refinement that has been happening all along.

That’s the view on paper. In practice, this first attempt would be a bit rough and contentious. The lessons learned would be super valuable the next time we went through this when the team would understand collectively that we were serious about the process. It is fair to say I brute-forced this first vision document through.

I wrote the vision on my own, circulating it for feedback first to OPU program managers and then to senior leaders and forging ahead without really considering the immense implications of what we were up to. Unfortunately, people reading the draft were reading for how it changed or affirmed what they already thought they were doing, not to learn what we were doing together. This was the first attempt at building a shared plan. While we were making progress, the Apps teams hardly surrendered their autonomy. The good news was that I captured most of what everyone was working on and laid the groundwork to unify the expression of why we were doing all that we were doing—that was the goal. The vision was a leading, but also lagging, indicator. The later steps of resource allocation would help to make sure the plan was executed as intended and agreed. This step, resource allocation, is what was almost always omitted in transforming a plan to execution.

The multitude of offsites and planning discussions paid off. Collectively, we were close to being on the same page, at least as close as could be for a team of senior managers who previously were working autonomously with OPU trying its best to be the glue across teams. The rest of the organization was starting to worry, something I heard in hallway grumbling.

Our team administrative assistant CollJ booked the big conference room, Kodiak Room, for March 15, 1999, for an all-hands meeting for the team including satellite/tape for Asia and Ireland where we had large teams. The last time we did this was for developer demo day when each independent app showed off features of Office 97. The night before the presentation I had an idea to make a cheat sheet or one-pager highlights. I quickly excerpted the 12-page vision document, choosing the goldenrod paper stock from the building 17 first floor copy room and made 1000 copies. I was there late in the night and most copies ended up crooked. I had to finish in a second copy room because the machine kept jamming. It makes me smile now to look at the crooked paper that remained on my cork board (adding subsequent cheat sheets each product cycle).

The vision began by stating that Office 4 through Office 97 changed the way people worked, but that was the past. A paradigm shift was underway (Microsoft, especially BillG, loved the word paradigm, in the Thomas Kuhn sense). This shift was toward the internet. Office9 declared itself to be “the best execution of an integrated suite of Internet-centric communication and productivity tools for creating, editing, sharing, synthesizing, and analyzing business information.”

This was my way of pushing back on the idea that the internet, by definition, implied new productivity tools. My point: The internet could make existing tools better and more relevant. The team liked this, or at least reacted positively to it, even if implications were unclear. Office9 declared Office 97 the end of an era of individual productivity and the start of a new one.

Later, I realized it was the beginning of the middle of the PC era, an era defined by expansion into business combined with a shift to enterprise features and sales motions.

An interesting note relative to disruption is that one response incumbents have to new technologies is to attempt to absorb them into an existing product, failing to recognize the substantial changes the new technology might ultimately imply. This was something I did not consider but thought a good deal about a decade later in Windows.

In order to outline the strategy shift, the vision explicitly stated the six priorities:

* Migration, Administration, Deployment, and Management

* HTML Document Creation

* Outlook and Outlook + Application Integration

* Web Collaboration and Solutions

* Web-Based Corporate Reporting

* Personal Productivity

Of note were the first and last. In the vision I used a bulleted list (HTML tag

) and went back and forth myself over whether to number the items (HTML tag
) to further emphasize the priority. As it would turn out, everyone mentally numbered the list anyway and I got the benefit of the full effect. I explicitly rejected the traditional business notion of having one single priority, say the internet. Such an approach only looks good on paper. In reality a single priority leaves most everything to chance as it is necessarily too abstract. Eight or ten priorities seemed too many so this release and others would arrive at five or six.

Migration, Administration, Deployment, and Management declared the most important thing we were doing—making Office a LORG product. Suddenly, the thing that was always last, always assigned to interns, always fixed as blockers in later product updates, was moved to the very first priority. The problem was that by talking about migration, administration, deployment, and management, I made Office9 seem like the dullest product ever. These features were always the last to get completed. The thought of doing this work as a first-class effort became an eye-roller. The vision called this the TAO of Office, or totally adminsterable [sic] Office.

HTML document editing was the second major area. Much of this work was already underway in the form of Internet Assistants for Word and PowerPoint. There were two controversial elements to this. First, Excel had done little by way of HTML and pushing an investment there would ultimately drive a great deal of effort on performance, rendering, and capacity in Internet Explorer (who loved web pages they could display but would crush Netscape). Second, we had not put much effort into ingesting HTML (versus outputting HTML). By developing the ability to open HTML files, as difficult and not particularly useful as that was, we laid the groundwork for using future HTML as a native file format (instead of our crazy binary formats that had caused us so much trouble in Office 97) and importantly for a format to interchange data between applications and the browser using copy/paste. This was the start of a multi-year, multi-product investment that would pay off immensely over a long period of time. The controversy around this choice will be explored in the next section.

In the past, the buyer and user of Office were the same person—the individual productivity user or the power-user/developer we called influential end-users. Apps previously segmented customers by end-users and influential end-users (power users, techies, were other names). Excel segmented bankers. Word segmented lawyers, and so on. Office needed to mature and build a product for segments the way we were selling software. The vision made a case for this level of importance by highlighting different customer segments and the value each would see from Office9.

For the first time, we declared that administrators and CIOs were users, not just buyers—they just wanted entirely different features. We also made a consistent appeal to developers, something we had done unevenly across the product.

The team understood this and making a case with the financials and sales of the company reinforced the new reality for the business. This information also reinforced the dominance of the suite in defining the product.

What turned out to be unacceptable was the last priority, personal productivity. Historically, personal productivity meant features customers liked and made the product easier to use and demonstrate. Anything and everything could be personal productivity since we made personal productivity tools. The personal productivity bucket consumed all development schedule hours and made the product appear as a long list of features to marketing, rather than any theme. That was old-school personal productivity, priority 1 (and beyond).

The plan constrained the definition of personal productivity to features that were unique to each app—features unique to spreadsheets or word processors, not general user experience or ease-of-use features. By allocating development resources to productivity features shared across Office and reducing app resources to focus on each app, the plan was to have a more coherent product to communicate to the market, and one that emphasized the suite nature. Most of the personal productivity features in Word and Excel in the past were similar ideas done differently, inconsistently. Office9 moved that work to OPU and away from Apps teams.

Immediately, program manager leaders across Apps threatened to quit, even raising the issue to BillG. It was not the reaction I expected. They felt disempowered and felt that I had kneecapped the apps. The need to build a suite for LORGs seemed like the obvious plan—to me. Also obvious to me was that Office 97 won. I was experiencing a reality of management: Everyone went along until something changed—they were in favor of change, and even change advocates, until the actual change.

I was disrupting Office not with a new technology but a high-priority focus on a new customer segment and target. Disruption does not always have to be about a new and unproven technology.

It was one thing to declare the need to build a better LORG suite. It was quite another thing to choose to build one at the expense of other features.

Word, Excel, Outlook, Access, and PowerPoint believed that the battle to win in the categories still raged. Outlook had been poorly received (and was now busy on their own interim release that would stretch out much longer than planned). PowerPoint was consistently viewed as the weak link. The general utility of the Access product, and our move to upsell Office Professional, which counted on demand for a database, was still too early to declare a success. Lotus and WordPerfect were rumored to be releasing Windows versions that transitioned their MS-DOS product leadership to Windows. From an app perspective, there were plenty of reasons to worry about losing category reviews, should there be any.

Winning in each of these categories, the PM leaders told me, required freedom to innovate in the base experience. There was no way for Excel to beat Lotus 1-2-3 unless they could build an experience tailored to the unique needs of spreadsheet users.

Repeat for each app.

We were right back to “Excel users are different.”

Independently, Excel was planning a unique user interface re-architecture that was “weblike.” This sounded crazy to me and was the exact opposite of an integrated suite. It was also something that had not been broadly shared or considered across the teams. I could not imagine how we could be a productivity suite if the flagship product, alone, had a new user interface just as we finished launching on the merits of consistency across the suite.

The two weeks from presenting the vision at the all-team meeting we were consumed almost entirely with defending Personal Productivity Is Priority 6, as it became known. My inbox was filled with subject lines like “#6,” “Priority 6,” or “Why such a low priority?”

What seemed easy, took a turn toward the impossible.

To make the most difficult even more difficult, BillG appeared in my inbox. He asked me why Office was going to have a plan that did not advance productivity and was not going to innovate in user interface. It was a direct shot at the plan even though he only knew a small piece of the story. Clearly, he had heard from a leader on the Excel PM team.

Here I was again on the defense, though, logically, I was certain he was going to be okay with it. He knew the importance of the suite and LORGs, intellectually but not emotionally. Bill had not really faced a product team intentionally constraining a release up front. Of course, that is why so many things were late.

Once he read the vision, BillG switched from being concerned about the product to being concerned that all the smart people would leave the team if they weren’t allowed to innovate. I went from preventing productivity features from making it into the product to the manager who smart people did not want to work for. This felt personal and more of a character trait assault than a list of adjustable features.

This wasn’t the first time in my tenure as a manager and later an executive that I would defend the team that was in place over a single person leaving. One of Bill’s most enduring and appreciated traits was the loyalty he felt to those committed to Microsoft. This trait surfaced when someone telegraphed that they might potentially leave. In this case, Bill’s first reaction was to go to the manager assuming something was wrong in the environment that was causing this. Almost always, this was difficult to handle because the information was one-sided (regardless of how BillG found out) and the only thing a manager (me) could do was then talk about all the ways that the team was trying to move forward and how the disaffected person wasn’t on board.

I had been defensive in this case. It was early in my career (I was still leading OFFPM, which had grown to about 65 people). And BillG was concerned about any thought leaders (a great 1990s word) leaving. After some back and forth, however, he was supportive of the bigger picture. Despite all the changes in the vision and the demotion of personal productivity, the team was overwhelmingly in place as we planned and only one PM leader of about 15 bailed, and that had worked out best for everyone.

The rollout of the vision kept moving.

By spring of 1997 we still had two or more years of tight collaboration ahead of us, much tighter than with Office 97. We could not afford a misstep. We rephrased a section in the vision, tenets, that defined the cultural priorities for the release. We made them explicit in the vision document so we could refer to them later in the project:

All members of the Office9 team, regardless of the reporting structure, are responsible for the innovations in the Office9 product. By corollary, the shared feature teams are responsible for the integration of their work in each application.

Development and process efficiency is critical to the success of the Office9 schedule, and therefore it is better to do things the same way once rather than doing things in multiple places. This refers both to features and process. In other words, it is better to be the same rather than different.

We took this as a chance to create a new employee orientation for the Desktop Apps division. By instituting a small amount of informal training during new employee onboarding, we were able to show employees the vision document and detail the organization and priorities. Almost immediately, the vision document took on an even broader role than originally intended.

The vision even included specific tenets when it came to the product, schedule, and how we would manage the team. The goal was to have a set of non-negotiables across the App teams and OPU to effectively centralize what mattered. Even something simple like which non-English languages we would focus on (German and Japanese) was previously a big headache that we just decided up front. Similarly, we committed to the platform requirements for the release which included working on the new 3-year-old Windows 95 and also that we would make sure our HTML worked on Netscape Navigator, which was almost heretical (more on that in the next chapter).

Rolling out the vision for the first time to the entire team was stressful. There was the ever-present fear of leaks, leaving someone out by accident, typos, and oversights. Most importantly, the people who didn’t agree wouldn’t tell the sender (me) but would create a negative vibe across the group. We saw some of this in the original 12/24 plan. People who didn’t agree stayed on the lookout for what wasn’t working and were right there to call this out. For Office9, we knew those who wished to prioritize apps would do the same. All of these were signs of an organization still finding its way from storming to norming.

Given how late Office 97 was, a significant concern was any doubt about the overall schedule. Those manifested as schedule chicken between apps, with each app betting they would just finish ahead of another, rather than working to be first.

The key to a robust schedule was buy-in from the test and dev managers. GrantG already harmonized the schedule across the test discipline, when he wasn’t personally testing the latest build or filing bugs. While there were differences in style, they really snapped to the same page under his leadership.

DuaneC rallied the dev managers behind the schedule. Duane’s style, much like JonDe’s, was quiet, understated, factual, and exceedingly straightforward. While directly managing nearly 100 engineers and having responsibility over the full team of over 350 engineers, he still managed to own code, fix bugs, and add features.

It all worked. Following the team meeting, the dev schedule was in motion. Code was being written. We officially started coding in May of 1997 (about 8 weeks after the vision meeting), with a beta scheduled for a year later after three milestones. We planned an RTM of July 1, 1998. There was a big risk to a summer RTM—another DAD rule of thumb along with not releasing on a Friday or before a holiday was avoiding an August RTM. If we missed it, there was a cascade (summer and global holidays that broke up the work calendar, followed by end-of-year) that almost automatically pushed us into the following year.

We were off.

One final note, the group program manager for PowerPoint, BrendanB, was so amused with the vision process and especially the cheat sheet that he went one step further and made a version I could hang from the rear-view mirror of my car along the lines of Repo Man (“there’s one in every car”). This became his tradition and I have a whole collection of these that I maintained on my cork board.

On to 051. HTML: Opportunity, Disruption, or Wedge



This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit hardcoresoftware.learningbyshipping.com

The most difficult thing to do in a big company is change a core belief. Microsoft was going through a late 1990s change, and rather unevenly. We were moving from a company primarily or almost exclusively selling products to consumers to one selling to IT professionals. The unevenness was seen in customer engagement, product roadmaps, release dates, and cross-company strategic alignment. It was also seen in how various executives perceived each team, and importantly how Office was viewed now that our management chain at the executive level was rooted, for the first time, in Platforms history and not Office history. This transition to an enterprise company was happening in parallel with every major product quickly embracing (and extending) the Internet. Across the company a new book, The Innovator’s Dilemma, became ever-present in conversations, debates, and characterizations.

Back to 048. Pizza for 20 Million People

Please consider subscribing

Planning Office9 was going to be difficult because it was the first time we would plan a release from the start as a suite. We soon realized most other groups thought Office was being disrupted by the Internet (disrupted, as I will explain was all the rage in business jargon). To address this challenge, or I should say inevitability, Office needed to navigate external competitive forces and internal strategies that conflicted with each other, even before taking into account what Office might do for customers strategically or technically.

Windows existed in a parallel world where the Windows 95 consumer code base was almost entirely engrossed by the Internet, while the NT code base designed for business and IT was working to add a modern graphical interface and then build up compatibility with the consumer ecosystem (a project that would take three releases and 6 years.)

The server products such as Exchange and SQL were built around IT as the buyer and the user, which led to a world view exclusively about the enterprise, where embracing internet technologies had a less urgent need. Windows Server, the core platform product, had a clear mandate to be a great WWW server, building on the early work of Internet Information Server which was itself in a bare-knuckle competitive race with both Netscape and the open source Apache web server, both of those primarily running on Unix and increasingly Linux.

Office 97 finished the last consumer release and as a team we were in the process of figuring out how to focus on enterprise customers, while also recognizing that our buyer was IT, but our user remained the individual or workgroup. Our internet plans were based on what we had started years earlier, apart from Outlook which was in the process of its sudden embrace of internet protocols resulting in the off-cycle release separate from the Office suite. Nevertheless, in many markets Office was going to remain a consumer or retail business for some time to come, especially Japan which was approaching half of our business.

With the organization above me in flux and the executive overseeing the Office organization during Office 97 changing a couple of times, I discovered that sometimes there was opportunity in chaos. During this time, I experienced my own evolution as a leader, learning to be focused on the team and getting the product built, while stuff above me just sort of happened. I began planning the release in my role as program management leader for the Office Product Unit (OPU) but finished the release as the General Manager and then VP for the entire Office suite, though the team experienced none of the “big reorg” issues. My manager was JonDe for the entire release as he endured the changes above him, and diligently worked to minimize the impact of the chaos on the Office team. There’s no way we would have finished Office9 without that support.

As a program management team, we held offsites for several months prior to Office 97 shipping. I scheduled one to kick off the process of buy-in from upper management. I structured it in the way I believed the Platforms culture (our new executive leadership) preferred, which was a series of slide decks presented by area experts with interaction and discussion including a deliberate description of architecture. This differed from how Office usually handled offsites. I saw these cultural differences in working across teams and as BillG’s technical assistant and knew how important it was to have discussions culturally in sync, even if I did not always do a good job myself.

The plan was to have BradSi (now JonDe’s manager and Senior Vice President Applications & Internet Client Group) and PaulMa (Brad’s manager and Group Vice President of the new Platforms & Applications Group, which was everything but MSN) attend, as well as my manager, JonDe, and his reports, plus the group program managers (the product leaders across Office and also several teams from Windows and across Platforms) and of course marketing.

But then a wrench was thrown into the planning. JonDe told me the Office9 plans were creating angst among execs. This was a bit puzzling and somewhat scary because the plans were not known broadly. Actually we didn’t have any plans at all and the product hadn’t even officially started the schedule yet. How could they already be concerned and about what?

In JonDe’s office on the third floor in building 17 we grumbled about the challenge of Office being managed by Systems execs. We felt similar to a couple of years earlier sitting together in that very same office pondering the idea that the Apps teams said we in Office lost our marbles, before we finished the successful (but late) Office 97 product. This was different though because, as Jon relayed, Office9 wasn’t exciting enough or soon enough so it seemed. We were told the “rest of Microsoft” felt like Office didn’t get the internet and was not embracing the future—it was those kinds of vague assertions that made their way to us. I felt certain that I had credibility when it came to internet religion. What could such feelings about the team be based upon?

There were forces at work, or, more aptly worded, criticisms of Office based on nascent technologies that might prove competitive. Innovator’s Dilemma, the seminal 1997 book by Harvard Business School’s Clayton Christensen, was fresh off the presses and like every large company facing the internet, the book’s lessons were immediately extrapolated to the strategic challenges posed by the internet. The original article upon which the book was based, “Catching the Wave”, was widely distributed among teams at Microsoft. The book was not without controversy when it released and increasingly so as time passed. The disruptive force, as it related to Office, was the internet and what it brought to productivity and document creation. Unlike the concrete examples in the book (such as the switch to 3.5” hard drives from 5.25” ones) there was no lower-priced, less-functioning product competing with Office…yet. Office did not understand the internet, so our bosses seemed to suggest. I had, apparently, lost my marbles. Every discussion would somehow come back to the new and ever-present theory of disruption, though everyone seemed to have a different interpretation of the book.

Yet, there we were facing our own management team. In the context of planning Office9, we were being told Office was being disrupted. It was not a question if or when, it was happening right now.

In the Systems way of developing a strategy, problems were generally distilled down to specific technologies or architectures that would be used to out-architect Microsoft. The conversation almost always started from the technology end-state and from that basis one countered. Communication challenges would arise when the discussion turned to or started from scenarios or customer perspectives. Disruption facing Office was not a specific product, but the way future products were being built or contemplating being built. Somewhat like Christiansen’s steel mini-mills, Office faced a technology challenge.

Our technology approach was customer focused, not technology focused. Still thinking from a customer perspective did not preclude technology. Rather, we faced the belief that technology defined the starting point and context for the conversation, not the end point in solving customer or market problems. It should be no surprise, but technology driven is what makes sense for much of an operating system. This different focus is not a problem, rather it is why Microsoft had two wildly successful businesses. Even to this day there remains a nuance to this heated topic. Every company, especially mature and successful ones, claim to first and foremost listen to customers. Whereas every new startup is almost always highly technology driven. As we will see, Office was and remained customer focused while making significant and seemingly anti-customer bets on major technologies. Systems would continue to be primarily technology focused which both served it well and also created challenges within the team and for Office.

There were numerous technologies in play that were, as we came to say, poised to disrupt Office. Key among them were the browser, network computers, Java, and components. This might all sound like jargon or at some level interchangeable buzzwords of the era—and to those who know the jargon these might not sound like particularly discrete choices—but the importance of having a strategy discussion based on these technologies was key. Each one of these technologies was deeply important to a different part of the overall product organization. Each was viewed as the most important competitor for at least one part of the company.

As I discuss these, it is important to consider that the technologies while related were at an important level mutually exclusive—we could only build Office once and had to pick one technology approach to build the product. Office was being disrupted, but by which one of these? It also meant we were by definition currently building Office on the wrong technology for the internet—could it be that using Windows was wrong, in 1997? The problem was not just that we were wrong at the start, but we would have to pick one approach from several and in the process we would still be wrong for some executives and their view of disruption. How would we possibly align? Importantly, every division wanted Office to align with and validate its strategy.

Windows and equally about the bets we did not make. We took this responsibility very seriously. Even small things like what version of Windows was required by Office were galactically important—the teams building new versions of Windows wanted us to require the latest version because doing so drove new PC sales through PC makers with a one-two punch of a new Windows and new Office together. The newly powerful enterprise sales teams wanted Office to run on the existing OS and installed base of PCs.

At any given moment, about 30% of our customers were on the one before the previous version of Office (in this case Windows 3.1 and Office 4), 30% on the previous one (Windows and Office 95), and then in about 2 years the rest would be on Office 97 (probably with Windows 98 and a little bit of Windows NT in the enterprise), just in time for Office9.  Repeat this for every new technology and you can start to see how difficult it became to release new capabilities that required a new OS, a new PC, and a new version of Windows. We were already stuck and didn’t even realize it.

First among technology equals was the browser. There were advocates that believed productivity tools like Office hosted in the browser were imminent and Office’s days running on Windows were numbered. In early 1997, HTML was made up of a collection of about 20 formatting elements and the programming language JavaScript that was about 18 months old, both experienced over 56k dial-up connections for most people. Internet Explorer supported both JavaScript and of course Microsoft’s own VBScript. Microsoft would tiptoe around the most strategic choice for scripting and the launch of JavaScript was one of the earliest “Anyone But Microsoft” (ABM) moments in the browser. The market made its choice of scripting languages clear with JavaScript the obvious winner. Office was already iterating on saving documents to HTML and making progress. Still, many thought the combination of the latest HTML 3.2 and scripting along with future browser enhancements meant the replacement for Office was looming.

PowerPoint was a canonical example of an Office app to be replaced by HTML. As it turned out, a dozen different sites were doing pages that from 10 feet away looked like a slide-creating program. The ability to make big title text with bullets was grabbing attention. Unlike PowerPoint in Windows, where most people used the default look reminiscent of color television of a blue gradient with yellow text. These new browser slides had cool texture backgrounds (like fabric) and blinking title text (thank you, Netscape, for that one!). These were absolutely trivial slides and there were no real tools for editing. In fact, these worked by typing lines of text into a form or series of five text boxes and clicking “submit,” and the slide came back as an image with bullets added. The image didn’t scale to full screen and most of the time picking the size of the image was done at create time. PowerPoint, however, was going to be the first victim of the browser, or so it was suggested.

Reading this, one might say that of course this happened, evidence today’s Google Workplace apps. Two decades is a long time—that is like saying the iPod was going to come along and disrupt the Walkman so the Walkman team should have just given up, long before the iPod arrived. Still, Google today has not commanded more than a small slice of the productivity tools business dominated globally by Office. Whether that is still changing or not, only strengthens the point about the timescale we are talking about. As this book shows, and will show, frequently being early is not always the best path.

Netscape was already building email and that was going to displace Outlook, as it was put bluntly. There was more credibility in this only because Outlook lacked support for standards and was still far from the most loved product in Office (“Byzantine” as it was called in reviews). Netscape was building an internet native email client, not unlike the current favorite Eudora that the Internet Mail and News app (Outlook Express) was going after. Rumors were swirling about a word processor and tools for collaboration based on a significant acquisition Netscape made. I was concerned. Netscape was a force. We were already on edge about word-processing with the rise of email, which is why we did so much to integrate Word and Outlook. A word processor that shipped with the browser was exactly the strategy the Office team proposed at the company’s very first Internet offsite.

For the rest of our Internet Division, however, the browser was everything. Having Office commit to the Microsoft browser was not only good for Office but would enhance the unique, proprietary aspects of Internet Explorer that Office would use to deliver a product in the browser.

I was not alone in questioning the maturity of browsers to build document creation tools. Sun Microsystems introduced a new programming language called Java that addressed the lack of power in the browser to create full-featured applications. Java was getting a great deal of attention from enterprise IT strategists because it came from Sun, leaders in the server world (and main competitor to NT), and because Java more closely resembled the client-server world they were used to. In many ways, Java was viewed as the successor to Microsoft’s Visual Basic with the added benefit that Java was touted as “write once, run anywhere,” which meant it worked on any computing platform. Enterprise IT loved to hear about technologies that avoid platform lock-in, the theory of Java was just that. Adding to the strength of that message was the rebirth of IBM under CEO Lou Gerstner as a company free of the shackles of proprietary technology and open to supporting all the popular platforms. IBM was “all in” on Java and emphasizing it as a key technology across their product line. The embrace of all competitive or alternative technologies as a way of leveraging account control was now the IBM playbook, and one that threatened to slow down Microsoft’s emerging opportunity in enterprise accounts.

JonDe and I grappled with the notion that writing programs in Java was a significant risk to Office. It wasn’t just technical reservations, but our life experiences. Java was an interpreted language, which meant that the programs were represented by code that was converted to native machine code as it ran, unlike Office, which shipped as fast compiled native code, as most all modern software did. For JonDe the idea of using an interpreter for programs was close to home. His first job at Microsoft used an interpreter (pCode as previously mentioned) specifically to write apps once that ran on many computers of the day using as little memory as possible—Microsoft had its own proprietary dialect of the C programming language and an interpreter for an array of different computers. Over the past few years, all interpreted code was removed from Office products as modern operating systems made using an interpreter unnecessary and slow. Interpreted programs made sense when the scarcest resource was memory, which was no longer the case.

Finally, the GUI programming model of Java was strikingly close to the big fat AFX class library that was thrown out and a huge failure much earlier in my career. The idea that the way to work seamlessly across multiple platforms is to invent yet another platform seemed doomed to failure. In the case of Java, Jon and I sat in his office reliving years of our shared experiences, making it difficult to think there was any reality to this technology. Cross-platform, interpreters, big class libraries—what a horrible foundation. Add in the promise of write once, run anywhere and it seemed obvious that Java was set up to fail as a tool for writing client apps. We’d seen these movies before. Or was that a warning sign to us to be cautious in fighting old battles again?

There were at least a dozen different companies building what were casually called Java Office products including consumer favorite Corel. There were suites of tools, attempted clones of Word, Excel, PowerPoint, and integrated products like Works. There was a huge investment from Silicon Valley venture capitalists to fund Java-based companies and many of those were going after Office. Like JavaScript, Java was supported by the loose consortium of anyone but Microsoft.

Therefore, Java was enormously important to the Developer Tools division where maintaining the mindshare of developers was their key mission. In another aspect of embracing technologies, Microsoft released Visual J++ as part of the family of Visual tools, side by side with Visual Basic and Visual C++. Visual J++ was a technical tour de force, but Microsoft was strategically conflicted over embracing it because of the loss of control on the client where Win32 was strategic and on the server where Java could lead to a stronger position for Sun (Microsoft .NET was still a few years away). Office was a big user of Visual Basic and enterprise customers were deeply committed to it for client-server development, at least for the moment. It was clear that Office could not bet on Java for those reasons, but then again what if Java were to win in the market?

The network computer, or NC as it was called, was particularly troublesome to the Windows operating system team. Larry Ellison at Oracle championed the NC, a simple computer that only ran one program, a web browser. For the NC to disrupt Office, browser-based applications offering some functionality like Office were required. The real fear of the NC was that enterprise customers would adopt it simply because managing Windows PCs was so painful and expensive. PaulMa and the people on the Windows team thinking about TCO spun up an initiative ZAW for zero administration Windows. It was a classic sales tool to solve a deep technical problem. While I was as worried about the NC as anyone, from an Office perspective it still required HTML Office (or potentially Java Office), which was, at the very least, a stretch. The NC was a strategic threat for every aspect of Microsoft. The question was on what timeframe and again with what technologies?

The fourth technology movement to navigate was the idea of components. Components were not a specific programming language or even technology, but the concept that component technology would replace tools such as word processing and spreadsheets with much smaller and lighter components. Components might be viewed as an expression of object-oriented concepts in the context of resulting products rather than programming techniques. Components could best be thought of as basic building blocks of applications from which a customized version of a full-featured application could be easily created with the benefit of having only the capabilities required resulting in a reduced need for system resources like memory and disk.

Components were a response to the feeling that suites were bloated with too many features no one used, making them inefficient for the enterprise. IBM, who did not have a competitive suite even after acquiring Lotus, was the leader in touting components. IBM repurposed Lotus SmartSuite as components, more sleight of hand than technology. Components were attractive to industry analysts like Gartner who believed that enterprises might construct purpose-built desktops tailored to workers by using components. This type of design was exactly what I saw at the bank in New York when I went to learn about total cost of ownership. Java was the new way to implement components. We were sort of going in circles. That was sort of the point—the proponents of Java did not want to compete with Office so they created a product strategy that was something Office could not do even if it wasn’t something humans wanted to do.

To cover all the bases, a newly created alliance of various Java vendors announced a component architecture called Java Beans, to fill the architectural holes in using Java for components. This technology was aimed squarely at Microsoft’s own ActiveX (or earlier technology COM). Many in the Microsoft platforms ranks viewed COM as something of the crown jewels of our overall architecture approach. This made competing in component technology even more important. Office already used COM and it was tightly integrated with Visual Basic. This was good for strategy, but again if Java or Java Beans became the defining technologies to disrupt Office then we would lose out.

In addition to technology, the concerns about Office included cultural and process issues starting with the length of time Office was going to use to create a new release. The Internet Explorer team became quite enamored with the concept of “internet time.” Internet time was a key element of the ongoing browser wars (as they were called) between Microsoft and Netscape.

Unlike Office, where releases took 24 to 30 months, browsers were being released every nine to 12 months (at least for the past two versions—any two data points can make a trend). On the face of it, releasing the browser that quickly did not seem risky—the main characteristic of browsers was that they were viewers, and if they crashed a user could revert to what they were previously reading. No work was lost, unlike if Word crashed. Plus, HTML was designed in a fault-tolerant way, so any coding mistakes in displaying it on the screen were minor annoyances more than anything else. This relaxed a huge constraint on engineering and certainly made release velocity possible—that and the fact that these were not big programs yet. HTML and the browser user experience were maturing rapidly—there was so much low-hanging fruit to get right just looking at how other browsers worked. Basic, and known, features like clipboard, printing, accessibility, and more needed to be added. Most of all everything was new so there were few pre-defined criteria for features, other than what Netscape was doing.

To some, this was another point at which Office didn’t get the way the world changed. Office needed a new architecture and to release faster.

Office9, the product that few knew about and that even we had not developed full plans for, was not exciting enough because Office was being disrupted. It was also taking too long to get done, even though we didn’t have a schedule. To thwart the disruption, we needed to build a new Office that was more exciting, but to do so meant solving a complex web of technologies and competitors, none of which seemed remotely up to the challenge. Every time I said something like that I was literally the punchline (punching bag?) of Innovator’s Dilemma or sent another link to a press article about a new startup building Office in HTML, Java, Components, or Network Computers.

My emotions ran from angry to upset to frustrated as I tried to figure out how to have this conversation without being the person who said, “All the new technologies won’t work,” while also being the person who said, “Office won’t change.” That was a dangerous combination when the phrase “disruption” was being tossed around because such a reaction was literally the one written about in the book. In other words, everything I might have said was going to be viewed through the lens of me playing the role of the executive with his head in the sand. Oddly, I was one who helped get everyone excited about the internet in the first place. More than anything that stung, being painted as a luddite so soon after running around the company trying to get people excited about the internet.

The feedback felt to me was like an allegory of Go Get This Rock, that was told to me by members of the original LanMan team (the failed but still legendary networking project that was originally managed by SteveB).

Elder: I wish to be clear and helpful. Go get me a rock.

Student: (runs to riverbed to get a rock and picks out a nice one) Here is a rock.

Elder: No, not that rock. Try a bigger one.

Student: (runs again) Here's a bigger one.

Elder: Yes, but that isn’t smooth enough.

To the elder (the manager), this was the process of managing by “I know it when I see it,” which was certainly one valid school of management. To the student, this was unwanted insanity.

The kind of feedback we were getting felt like getting rocks. No product approach was right. No technology choice was right. Nothing was soon enough. And it was frustrating. It was, unfortunately, also the default executive management approach. At the time I was miserable from this and of course did not handle it well. This manifested itself in endlessly long email threads, which I feel I achieved a varsity letter in writing. With the benefit of hindsight, this was a product of the uncertainty. No one knew what to do and everyone was kind of worried. We simply entered a period where the prevailing view was knowing what to do once the right answer was presented, and at the same time there was a belief that the right answer was higher in the organization where there was more context about the risks to existing businesses. In many ways, this was the innovator’s dilemma we faced (all of us)—the question was if the new technologies could be fit somehow into existing strategies or we needed a whole new approach. There was also a great deal of Microsoft’s universal cultural attribute, paranoia.

Writing memos in addition to email became my tool for processing my own thoughts and, in a way, getting my act together for confrontation, at worst, or at least a strategic discussion. Writing was my way of saying, in detail, “Here’s a rock,” and a way of documenting promises and commitments in one place for all audiences. It was also a way of saying “This would be a dumb rock and here’s why”.

I wrote a dense 20-page memo called High Hopes for Office9. This set a tone that was, in hindsight, overly defensive. Caffeinated on Diet Coke and wound up, I banged out this memo in an evening. It served as a precursor to the strategy offsite for Office9, detailing the main product pillars. I took on all the technologies and strategies I could and did not hold back.

In the abstract, I needed to find a way to at least suggest that the main technologies being talked about as disruptive to Office might pose a threat but not in any reasonable time, even though this was tilting at windmills. We already planned to embrace internet technologies. Primary among these were saving documents as HTML, using HTML as a native file format, connecting Office apps to servers using internet protocols, even using the internet for help, assistance, and content like clip art and templates. Most importantly, we were shifting our resources and efforts to building a collaborative server capability using FrontPage. All of these relied on internet technologies to solve problems within Office, which was decidedly different than rewriting Office in internet technologies.

Second, I showed that I understood that the attraction of these new technologies was due to deficiencies in Office. I then demonstrated how we could dramatically improve the cost of ownership, ease of use, and management of Office on PCs by simply doing a better job in areas we had previously paid little to no attention to.

I also knew that no matter what happened, someone always said it would. Microsoft was at the scale where regardless of how something played out, someone always wrote the memo predicting it. NathanM was even famous for writing multiple memos with conflicting predictions.

I was not naïve, but I was optimistic. Our plan was strong, an internet-savvy plan, but we also knew that the zealots who were convinced the internet was the undoing of Office would not be pleased. As I learned from BillG, there was a benefit to balancing the opinions of the zealots with reality. Balancing the extremes while executing well was, for better or worse, my sweet spot.

With my memo presented as a deck at an offsite, and the goal of not hurting the morale of the team present, which would undermine plans and execution, for better or worse, the team appeared to feel the same way that I did. Looking back, it was more that the plans for Office were given reluctant acceptance by executives without much actionable feedback. In hindsight, there really was a high degree of uncertainty about what to do, really, and no one, especially executives from Platforms new to managing Office, wanted to hinder the Office business out of the gate.

At best if the project went well, then we could say we agreed, but if things did not go well it was obviously my/our fault. I was fine with that level of accountability. In fact, it served us all well.

The next step was to have an actual plan. The kind of plan that the Office team was skilled in delivering and executing.

On to 050. The Team's Plan in the Face of Disruption