058. Synergy

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

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