Hardcore Software by Steven Sinofsky (Audio Edition)

A quick story about something that felt like a corporate or ecosystem tax, the “Designed for Windows 95” logo.

Back to 037. Capone and Email Without Typos

By early 1995, the most essential elements for the Windows launch were determined. Chicago had picked an early summer RTM date. For Office, what had been “no more than 30 days later” was simultaneously shipping, which was awesome for the retailers and for the business. Windows had chosen the name Windows 95 and the idea of using the Rolling Stones’ Start Me Up in future ads was floated. Things were really hopping, and everything went from uncertainty to terror in the sense that we truly needed to finish. We transitioned from a software team to a team gated by duplicated CD-ROM discs, assembling boxes, and distributing palettes around the world.

Office94 received the name Microsoft Office Professional Designed for Windows 95version 7.0 in a classic Microsoft naming bonanza, and to compound that there were other editions including Small Business or With Bookshelf on the box. Everyone on the planet called it Office 95, including all of Microsoft at launch events. But there were real forces at work, such as the fact that the Product Support systems relied heavily on the actual version number of the program to route and track support calls. It was also kind of a funny name since the apps were each on different versions (Word 6.0, Excel 5.0, PowerPoint 4.0). Version 7.0 came from bumping the highest number product, Word 6.0, to the next version. In what was a big deal, we versioned all the apps to 7.0 (Excel 7.0, PowerPoint 7.0, Access 7.0), which seemed like a weird (and often used) marketing gimmick. In fact, it was to be Office for the first time and to simplify all the downstream systems that we required real version numbers. And, because the company wanted only one product 95 and that was Windows. The chosen blue sky and cloud theme was visible on the Office box, but it was challenging to find a “95” without looking closely. Only today does the irony of using clouds on the box generate a chuckle once one considers the role of clouds today in software.

For the development team to fully feel the terror and pressure of the deadline, Robbie Bach, (RobbieB), the head of marketing for all of Desktop Apps, suggested I attend his weekly meeting where the planning for the launch was being coordinated. My first reaction was immature, and I thought between Office 95 [sic] and Office96 I had enough to do on the product and sitting in a long meeting going over launch minutiae seemed like a poor use of time. In addition, we had a team reporting to ChrisP specifically set up as the interface between marketing and development, known as Product Planning and led by Mark Kroese (MarkK), who had been working to make sure the product SKUs, naming, and branding were accurately reflected in the software coordinating with product design as needed.

Despite my resistance, it proved to be a critical learning experience as the scale and complexity of an Office launch was nothing at all like the nice little events we had in Languages, and this was truly going to be, to date, the biggest of all launches (and in hindsight the biggest one ever). Every week, I learned more small but important product issues—demo scripts that were not right, feature names that needed to be changed, concerns about localization, and good things to know like how much lead time one needed to rent out venues and the importance of mobilizing a global sales effort with the right sales tools and information. Everyone always says that PM and marketing need to work closely together, but until you experience the myriad of details marketing needs to get right for a worldwide consumer launch it is just an abstraction. . What no one could have prepared me for was just how many of these details came crashing together under crazy deadlines at the end of the project. There was a great deal of learning.

One recurring theme in the marketing meeting was a desire for “more” evidence that Windows 95 and Office 95 were designed to work together. This was particularly frustrating because by far the biggest features were 32-bits, long file names, and shipping the whole thing on time. Nevertheless, as soon as we had a ship date, we also had a lengthy list of Windows 95 integration feature requests. The list was not only long, but like a cake rising in the oven it seemed to be alternating between collapsing under its own weight and flowing over to make a total mess. Many of these details felt like a growing list of “must have” features from the Windows team about what makes for a great Windows 95 application. I had been asking for such a list for more than a year.

I was going back and forth every day between building 17 and the old buildings of the Chicago team—the shell team, networking, setup, and more—trying to figure out how important, how real, and what was the least amount of work needed to get things done. Seeing what was going on in our marketing team and knowing the realities of getting the code done, I felt I was mostly caught between these two incoming trains. Shipping big projects is as much a battle to say no and keep things in control as it is a schedule and crossing off work items. On the front lines, one always feels lonely—as though everyone else, every single other person from marketing to testing to PM to VPs, was coming to work every day to prevent the product from shipping on time. That’s how I felt in these discussions.

Much of this late work was coming about because the specifics of integrating with Windows 95 were, finally, coming together. For a Windows 95 app, the basics of installation and, more importantly, uninstalling or removing the product, was a defining area. Removing a product from a PC was a vendor-dependent hit or miss until Windows 95 when it was required an OS-defined operation. Today I realize the idea of installing and uninstalling software is archaic, but before Windows 95 putting software on a PC was a one-way adventure. It was close to impossible to remove a product, uninstall it, and return the PC to what it used to be like. This was a huge source of customer frustration and PC flakiness.

To make sure that third-party products were well designed for Windows 95, the Windows team created a program called Designed for Windows 95. This program allowed third parties to have their products certified by an independent test agency and, upon passing, the products could be branded and marketed with a Designed for Windows 95 flag logo on the box. Previous releases of Windows had a logo, but by and large it was a marketing effort with the defining characteristic being more logo-bearing software is better. Now there was an apparent product quality standard.

The logo test, as it turned out, was enough for marketing to feel like things worked together. Primarily this was because it seemed arduous and time-consuming enough that not everyone was going to have the logo in time for the launch and availability.

On the other handFor Office this was not optional, there really wasn’t much of an option. Office 95 had to pass these logo requirements. Windows was making a huge deal out of the logo. Historically, app developers looked to Office for ways to support Windows, but suddenly Windows was trying to tell Office what to do. App developers were looking to Office to be the first to support the logo and get the Designed for Windows 95 flag. We didn’t think it mattered much, but boy the Windows team and marketing thought it was really important.

Because of our scale, the boxes were being designed and printed assuming the product would pass the test. Looking at the final box it is kind of funny in that “Designed for Windows 95” appears five different times on the box plus it is in the detailed system requirements.

Logo requirements were somewhat of a moving target and many of them involved significant work. The logo program used an outside testing agency to verify products seeking logo approval, and companies had to pay for each test (and re-test). . .even Office. The outside testing agency was particularly literal and nitpicking with Office 95.

There were dozens of requirements tested throughout the project, and the details of what was acceptable were refined all the time. Each time we ran the test we had to pay something like $1,000 to the agency. It was driving HeikkiK (Heikki Kanerva, the former Olympic telemark skier and Finnish submariner on the team) crazy. The closer we got to the deadline the longer it took to get results back because the agency was overwhelmed. The Windows team had rallied many independent vendors to earn the logo as well.

In Office we always felt there was a conspiracy against us in that we were held to a higher standard than third parties. It certainly felt through the whole logo test like we were aiming for a moving target. We wondered if our competitors had such a challenging time.

The logo was one of many unplanned events that would mark the final six months of the project. Every day Heikki was convening the dev, test, and program manager leads for a status meeting. Heikki had no time for issues without resolutions and calmly kept moving the conversation forward. Every meeting people would mention issues regarding our ability to ship, starting with the beta release or OPP, Office Preview Program. Heikki would look at them and calmly ask in his Finnish baritone, “Is that an OPP-stopper?” The answer was invariably no, and thus the issue was resolved.

No whining was allowed.

Heikki, the ever calm, cool, and collected leader, by sheer force of will got us through this process, and we eventually received a passing mark for the logo. It was such a crazy experience that I had framed copies of the certification letter made for each of us. They remained on our walls for years.

It was July 14, 1995, just six weeks before launch we passed the logo requirement. This was literally just in time because the scale of Windows was absorbing all the manufacturing and logistics available. Combined we ended up using a lot of air freight and overnight shipping to get boxes of both Windows and Office to the thousands of retail endpoints and distribution centers around the world for August 24.

On to 039. Start Me Up

All we wanted to do was bring the rich formatting and lack of typos people experienced with Word to email. We saw how email was replacing many uses for Word and figured it seemed like a good idea to reuse all that code to make for better email. That put Office right in the mix with every other division—each of which had their own idea for how email should be done. While the WWW and browsers were killer applications for consuming all that was out there, email was the killer application for communicating with friends and family, and increasingly coworkers. So every team had to do something.

Some reading this today will point out Zawinski’s law, “Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.” That is precisely what was going on at the time, except a few years before this too-truthful observation. Email was the first time I experienced a classic Microsoft dynamic, which is when something is interesting every group finds a way to build their interpretation of it.

Back to 036. Fancy Wizard and Red Squiggles

Leading up to Windows 95 shipping was probably the most explosive era in product development in Microsoft history. Whole new divisions, lines of business, and products were springing up so fast it was often difficult to keep track. It wasn’t just the strategic clarity of focusing on Windows, but also expanding Windows into new areas from automobiles to televisions, from markets as far flung as hospitals to passenger aircraft, not to mention the global expansion of the ever-expanding enterprise sales force.

It wasn’t just that every one of these new efforts was capitalizing on the Windows strategy that was finally approaching market readiness. It was also, and perhaps more important, that each effort also lead the way in embracing the Internet.

While most everyone outside of Microsoft would aim their concerns at the “The Internet” icon on the Windows 95 desktop, the ownership and strategy behind that was all contained within one team in one division, Windows. The real battle, or more appropriately consternation and endless debate, would take place over a much less discussed desktop icon, “Inbox”—the email client application that could connect to Microsoft’s two email products, the legacy MS Mail and the not-quite-finished enterprise mail product, Exchange, as well as what was then called internet mail (email that used standard internet protocols such as POP3 or IMAP).

Unlike a WWW browser, building the company’s email strategy lacked a singular organizational focus. Rather, it was more of a classic strategy of permissiveness and letting many flowers bloom, an approach that Microsoft would employ repeatedly (photos, messaging, collaboration, and more). When something was cool or the next big thing, it always seemed as though every group would somehow manage to find the resources to squeeze it into their strategy. Eventually, in the 1990s every part of the company had an email strategy: Windows, Online/Consumer, Servers, and Applications. Those didn’t always align or even work well together.

Windows, like OS/2 and Unix and soon Macintosh, was like every operating system and assumed that connecting to standard internet protocols for email was important. Even though by email accounts, most consumers were reading email in America Online (AOL) or one of the other online services, these protocols were wildly popular with Internet Service Providers (those providing dial up access directly to the internet without the walled garden services of an online company) and small businesses. About a year after Windows 95 shipped, the team released “Microsoft Internet Mail and News” (codename Athena) which would go on to become one of several extremely popular email clients for customers using internet protocols.

The Online/Consumer division was building the Microsoft Network which of course had email. The email experience relied on a purpose-built mail server, custom protocol, and mail interface that would power the @msn.com email addresses. In a short time, the same group would acquire HotMail, which provided free email directly through any WWW browser with an internet connection. The team would spend quite some time reconciling the implementation of this strategy.

Servers, the division building the back office products powering the client/server strategy for business, was the home of the team building EMS as previously discussed. The team was primarily made up of hardcore server or backend developers focused on scale, reliability, and performance. EMS had many more email features than could be supported through internet protocols, such as calendaring, shared mail folders, and enterprise-level security. To support those EMS had its own proprietary protocol or API, which meant it needed to build its own email client. So they did.

Applications, specifically the Office team, ended up part of this effort by a re-organization in mid-1994. There was a second email client effort going on codenamed Ren & Stimpy (mail and scheduling) to be a full replacement for MS Mail and Schedule+. Since these were mostly distributed as part of the Office product, it seemed to make sense that the team should move to Applications. This was an early version 1.0 product and far from shipping. The EMS team grew increasingly frustrated with the product compared to their own Capone effort. Ren seemed to tax the EMS server significantly more than Capone.

From an industry perspective, Microsoft’s largest competitor in email appeared to be Lotus Notes, which was gaining traction and with the recent 4.0 release showed a revamped user experience and focus on email and strong connections to the internet. I attended the yearly conference in Orlando and left suitably concerned. Ultimately, IBM acquired Lotus just a few weeks before the Windows 95 launch, cementing Notes as the premier competitor to both Office and Windows. The New York Times front page covered the deal along with several adjacent stories about the magnitude of this acquisition, financially and strategically.

Notes created the workgroup or groupware category, something Microsoft could not seem to get right. A variant of Windows, Windows for Workgroups, added some networking features but offered little competitively. Office had several packages done as add-ons to Excel to enable workgroup activities such as budgeting, but those too missed the mark. Visual Basic was being used to create collaborative applications and was going to be a key part of the EMS strategy, but that was far off and not the focus of the Languages team. The addition of Inbox to Windows 95 would be yet another attempt at turning up the competitive heat against Lotus with something neither core to a product team nor complete in execution.

What Lotus had done with Notes was create a product that was not squarely aimed at any existing Microsoft product. In fact, it landed between all of the groups. That meant on some days any group could simply ignore Notes and on others it could claim it was aiming straight for it in a competitive sense. Ultimately no one was accountable, and everyone could point to someone else.

In many companies, people look to executive management to clarify overlapping or incoherent strategies, especially in technology companies where we love to have all the pieces fit together well. In times of rapid change and high uncertainty, however, most leaders seek to maintain optionality and prefer the costs of internal organizational scuffles to the potential cost of having the wrong solution. This was decidedly BillG’s approach, which for all the bravado of review meetings he avoided at all costs making a binary choice between two groups and preferred to leave the differences to some natural course. It was as if he had hoped a Notes competitor would magically appear from within a group already tasked with competing with an entirely different company or product.

This drove me (and many) crazy, but as I reflect on this in hindsight it is only hindsight or told-you-so recollections that allow people to say they knew we should have done something different. No one knew how email would turn out, we just knew we wanted to be a big player.

Office had yet another view on email. It wasn’t as much an interest in building an email client as it was that email seemed to be positioned to replace the core use of our product, which was creating documents, spreadsheets, and presentations. In 1994, email was in the early days of making its way through the corporate world. When email was in use, as it was at Microsoft, it was clear that the role of the traditional 10- to 20-page business memo was declining. Our instrumented version of Word confirmed a gradual decline in short documents once email was in use. What used to be done as short memos printed and circulated in interoffice mail was being replaced by email.

At first this was somewhat terrifying for the most used anchor of the suite, but additional research showed that Word was still used for the most important and valuable documents, and often longer documents, created by multiple authors. In the pre-internet era this was some comfort for the team. The question remained, though, what, if anything, should be done about short documents? How could Office participate in email without being yet another group developing an email client application? We were just getting our minds wrapped around Ren & Stimpy, but that did not yet have a schedule and seemed more like a far-off project.

The Capone client was basic and while it was primarily (some would say exclusively) about EMS, it was also being pushed to be a stellar example of a Chicago application. By stellar, it meant that the user interface for mail needed to look like the Chicago file explorer and reuse as much of that code as possible, something Lotus or other competitors would never bother with. While there was little top-down direction over reducing the proliferation of email clients and servers, there was an intense focus on Capone being a great Windows 95 application.

This design, appearing to users like the file explorer, had been a key goal of BillG’s for years and was at the heart of his mission for a universal shell as sought after in the Cairo project. I was never a fan of building shells—they aren’t that important and frankly people make too big a deal out of them, but I was in the minority and much of Microsoft embraced the idea of building a killer shell. The shell was “just a place people have to go to in order to launch Excel and Word,” something ChrisP always said. (I would later experience firsthand the high levels of emotion people attached to launching programs when introducing Windows 8.)

Capone was far behind the proposed Chicago ship dates of early 1995, primarily because the mail server product was as well, though Capone could theoretically connect to other mail servers, which would justify inclusion with Chicago. In Chicago, Capone was named Inbox and received an icon on the desktop (that was really difficult to delete) representing the importance of mail for Chicago. Capone had a relatively simple text editor for creating mail messages, supporting only the basics of typing and formatting.

The Word team, especially Peter Pathe (PPathe) and Ed Fries (EdF), were fascinated with the idea of replacing the email editor with Word. PPathe (or his nickname Blue, which was also an email alias) originally joined Microsoft to lead what became the efforts around typography and printing. A veteran of the Boston tech scene (and both Caltech and MIT), Blue was a rarity in that he had experienced all of the ups and downs of the PC industry outside of Microsoft while at the same time came to the company with deep domain expertise, having worked on innovative PC software before Microsoft.

EdF was carved out of the same mold as ChrisP and JonDe, and often the three of them were thought of in the same breath. EdF joined Microsoft in the mid-1980s from the New Mexico Institute of Mining and Technology and was already an Apps veteran who had famously created fish-themed software including co-authoring a famous screen saver. He was leading the Word development team, which was the largest Apps team, and had successfully led the team through the groundbreaking Word 6.0 release. Ed would later go on to become a pioneer in Xbox and a legend in the gaming industry.

EdF routinely described his goals for Word and mail as, “What could be more magical than, all of a sudden, my email didn’t have typos and it was easy to add bullets?” Routine today, back then it was magical—and costly.

Mike Angiulo (MikeAng) was a new hire in OFFPM, assigned to design this feature and to make it work. That put him at the center of storm between Workgroup Applications (where EMS was managed, WGA), Chicago, Word, and the Office test team measuring performance. WordMail, as it was called, was the ability to use Microsoft Word as the editor for email messages. It ultimately became a grand slam of cross-group coordination, but also finger-pointing along the way.

Over several months, there were more complexities than one could count. The API to reuse Word’s editor was known as DocObject and was part of broad plans to enable Office apps to be used in WWW browsers (if a link opened a Word document, then Word could open up inside the browser like if it was an HTML page). This approach was countered by the Netscape plug-in API, announced after weeks of negotiations over whether Netscape would freely license our API for use in their Navigator WWW browser. This was my one experience with Netscape that would play a tiny (and mostly irrelevant though memorable) part of the future antitrust trial. (In 1998, the Department of Justice (DOJ) and twenty State Attorneys General would sue Microsoft, resulting in a long-running regulatory dispute discussed in a future section.) DocObject itself was based on the enormously complex OLE interfaces, which JonDe and team tried to make perform in 4MB of memory after the decision was made to stick with OLE when I was working for BillG.

The Capone client was not ready for primetime, and the interfaces and capability to extend it were no more ready than the rest of the product, including EMS. The challenge was identifying where the problem rested. The Capone team had been benchmarking performance with EMS, measuring both memory used on Chicago and a somewhat mysterious item known as an RPC. An RPC, remote procedure call, was a request to the Exchange server to do something—retrieve a message, sort an inbox, or lookup an address. Using Capone generated RPCs, and every RPC was one too many as the server was trying to scale to hundreds of users. In other words, the best way to scale the server was to avoid calling on it to do work, at least that is how it seemed.

During the project there was a puzzling discontinuity between the development team and the executives who expressed increasing frustration over the tension between Office and WGA. Executives, it turned out, were insulated from the product performance challenges because their mail was hosted (dogfooded) on a special dedicated server named OXYGEN, that had far more capacity per user than the typical employee experienced. Execs were also running some pretty beefy hardware and did not routinely experience the memory pressure that most would on 8MB PCs. This special executive treatment gave the false impression of progress when we were, in fact, struggling.

Capone had gotten the number of RPCs to an acceptable level, and it didn’t hurt that Capone was also on the same team as Exchange. When WordMail, coming from a different organization, was integrated into Capone the number of RPCs went up, mail messages got bigger (because they had nice formatting not plain text), and a lot more memory was used (because Word was running). The number of RPCs went up, and it was all WordMail and was unacceptable to EMS. MikeAng along with the dev and test teams spent months tracking down and removing what they could, and justifying what remained, to deliver Word as a mail editor.

The result was an insanely cool demo. Mail messages looked like fancy printed documents—so that one-page meeting agenda looked, once again, like what used to arrive by interoffice mail. The feature was too early for Exchange and too soon for 4MB or 8MB Chicago machines. The groundwork proved incredibly useful for Microsoft’s next email product in Office96, as Capone led a short life. There was great vindication of this strategy by the end of 1995 when widely read and highly respected analyst Bill Gurley wrote about the arrival of rich email with color, graphics, and even letterhead. We were just early with a crazy implementation.

Coming into the summer of Windows 95, we had little to show to compete with Lotus Notes. The Inbox, with WordMail, would have little to do with the competitive battle for the backend of a modern enterprise. The parallel releases of Office94 and Office96 gave us a second chance for Office to compete with Ren & Stimpy, as we will see. The pain this optionality foisted on the product, marketing, and sales teams and even customers might eventually pay off. That is why when I reflect on all the craziness of the strategy, it is difficult to say it would have been easier—yes it could have been easier. but if only we knew the future.

On to 038. Designed for Windows 95

Office94 (still the working name for what would become Office 95) was primarily about working with Windows 95 and shipping on the same day. That led to the constraint of having a relatively small team, less than 20 software engineers across the product compared to almost 60 on just Word 6.0. We knew that simply working with the new operating system would not be enough to get people to shell out a couple of hundred dollars (at the time, about 1 in 10 PC owners were also legal owners of our apps). The apps were also constrained by not changing the file format, which limited fancy features. There was a surgical approach to choosing features that we hoped would garner winning reviews of the suite and each app. Winning reviews remained the highest priority for the team.

As part of writing this book, I am making an effort to include stories about features that everyone uses but often exist without a sense of where they came from or why.

Back to 035. Windows 95, August or Bust [Chapter VI]

Using a PC mystified most people, even in the workplace. Features designed to assist or help customers were almost always viewed positively even necessary as part of product reviews in magazines. Answer Wizard was our first attempt at using natural language processing and early artificial intelligence techniques to provide assistance in using ever more complex products.

The early days of PCs were days filled with in-person courses to learn the products, and these had given way to 600-page books that filled the shelves at Barnes & Noble and Tower Books, regurgitating every feature, menu, and dialog box in alphabetical order. We had written thousands of pages, provided reference materials, created online “computer-based training,” and more, but still the first days of the PC era were marked with too much complexity and too high a hurdle to begin to use. Most people buying a new computer were also enrolling in courses that met for a couple of hours every week for a month (courses were the upsell much like today’s extended warranty).

One of the core problems was jargon. There are dozens of phrases in the user interface that look like words a normal person would know but used in a way only a techie might grok (grok is a common techie expression for “to understand” that comes from Stranger in a Strange Land.) For example, PowerPoint, a tool few were comfortable with or had any understanding of, defied any logical English word (or any native language). What is a “slide master” or a “meeting minder”? What’s a “snap to grid”? The worst were features that were not so obscure but used English words in ways that most people could not understand, such as Word’s “mail merge” or Excel’s “lists.” We used to joke that we could probably put the version of Office with German language menu commands in front of English speakers and they probably wouldn’t even notice the difference.

Answer Wizard was designed as a bridge between humans and computer jargon. If someone typed, “How do I send letters to a list?” Answer Wizard would find the Mail Merge feature (without literally going through all the menu items trying things at random). Sometimes commonly used symbols in Word such as the pilcrow, ¶, were totally unknown to regular people who would type questions into Answer Wizard such as, “How do I get rid of the elephant character?”

Answer Wizard was a collaboration with Microsoft Research and proved to be the foundation of future work in Office96 being developed in parallel. Answer Wizard was the underlying technology of the natural language interface to what would become the Office Assistant, or Clippy. The earliest research group at Microsoft was the natural language research group where they were working on big hard problems of translation and understanding. That technology was more than a decade away and ultimately delivered by Google. Instead, we collaborated with the MSR’s first group of AI researchers using Bayesian mathematics to probabilistically select from among a set of choices. Basically, we tried to add an element of probabilistic guessing to the solution rather than relying on a traditional full text search or index.

The guessing was based on a small database of words not already in the index or help database that we could map to the various articles in the help system. We called these metanyms because they were not precisely synonyms but somewhat close in meaning. We brought together those who wrote documentation, called User Education, or UserEd, and for the first time they were working on much more technology baked into the product. We renamed the team and the effort and called it User Assistance, or UA. It would be a few more years until we stopped referring to customers and humans as users, as we would often remark that only one other industry called customers users.

One of the seemingly minor changes we made was that hitting the universal help key, F1, would always bring up Answer Wizard. We designed the new experience with a flashy animated icon, the first use of animation in Office, and even broke our own style guide with the font in the interface. Answer Wizard arrived as a feature just as people started typing queries into web search engines looking for help. Surprisingly, we quickly learned how much easier it was becoming to find answers to usage questions on the internet than it was within our own assistance features. Nevertheless, Answer Wizard proved to be one of our first suite-wide features and reinforced the commitment we had to making Office, not just the apps, the easiest to use product.

While the marketing story of Office94 was told through the lens of the suite and consistency and the few significant changes to the product we made in order to emphasize the suite, the constraints of not changing the file format and a small team led to some of the most innovative and memorable app features, under the guise of IntelliSense. Some of these seemed so small and trivial, yet they had to be invented at some point in history, and when they were they were often the work of a small set of people with a clever idea and the runway to get things done.

IntelliSense had become the branding moniker describing the intelligent features in Office 4. The canonical IntelliSense example was the newly introduced AutoCorrect, first released in Word 6.0 but brought to all the products in Office94. The feature was such a big part of Word 6.0 that the print advertising campaign for Word 6.0 often featured a large “teh” changed to “the.” As with so many things that are incredibly helpful, it wasn’t much work. The genesis of the feature was a remarkable story as it set a tone for developing data-driven features for years to come while also learning a great deal about global scale and sensitivities to users of vastly different backgrounds and cultures.

DHach joined the Word team straight out of Harvard’s Math department as a program manager on the “basic use” team of Word, which was the part of the team tasked with making the product easier to use for core functionality (versus focused on long documents or on fancy magazine layout features). Word already had many fascinating unused features. One of those features was the “glossary,” which was a way to type a short phrase, hit a keystroke (the F3 key, thus explaining why no one used this feature), which would then replace the short phrase with the longer text. Dean’s insight was that in English the spacebar could replace the awkward F3, and then he realized that he could prepopulate the list of glossary entries with a library of common typos and misspellings. This was the origin of correcting “teh” to “the” and hundreds of other words. Other insights included replacing the accidental caps lock key (“dEAR sIR” turns into “Dear Sir” with caps lock turned off).

One of the more aggressive uses of AutoCorrect was turning off the “sticky” shift key, which caused typos at the start of sentences such as “THis is the start.” Because so many acronyms were used in business and often with plurals (such as PCs), this feature was held back from Word 6 until an elegant solution could be devised for Office94.

As the first do what I mean feature, AutoCorrect was revolutionary. The key lesson in building automatic features was their value . . . when they worked. And when they did not, the frustration level soared. This tension over doing more for people while also not introducing errors and mistakes, or breaking muscle memory, was a theme in the evolution of IntelliSense and also proved to be a wedge issue with other products. For example, Excel resisted the idea of AutoCorrect for common formula typos because of the potential to insert the wrong formula or wrong reference to a named cell. This was a real concern but at times seemed somewhat stubborn from the OPU perspective. It was a classic example of “Excel users are different,” to which the OPU refrain was “Why, because they don’t make typos?” These would be worked out, but navigating these cross-group opinions was always time-consuming.

Given the success of AutoCorrect, it became a star feature of Office, embraced by all the applications with some app-specific constraints. Importantly, this feature was one of the first features shared across all the apps—the same typos got fixed the same way no matter where they were typed.

AutoCorrect could not catch everything, though—a lesson from Word 6.0 was that being too aggressive and making mistakes was far worse than leaving extra work for the user. As a result, AutoCorrect didn’t replace traditional spellcheck, but the idea of helping automatically when possible informed us on ways to introduce a dramatic improvement to spelling correctly. In developing IntelliSense features, we learned that our corrections needed to be right 100 percent of the time—being wrong even a little bit felt to customers like we were wrong all the time. This is a lesson the industry continues to learn with today’s autocorrect on phones.

Spellcheck was the original feature that distinguished word processors from typewriters. At first, most companies that sold word processors sold companion spell checkers often costing as much as the word processor itself. These largely competed among products by the size of spelling dictionaries and the ability to add custom dictionaries, such as legal or medical terms. Using these (and Microsoft’s) spell checker was a modal experience, that is the user would invoke the spell checker and begin to identify and correct spelling errors one at a time unable to do anything else. This was time-consuming and frustrating—the process was stopped when a correction was needed and then restarted, and every falsely flagged word required the user to click on an “Ignore” button. A spelling error resulting in a substantial change often reset this process requiring a full scan of the document again.

Office94 took two major steps in spelling, AutoCorrect and background spelling, which became iconic Office features.

Originally, spellcheck was a feature of Word. There was never any thought given to using it in Excel, where there weren’t a lot of words—another case of Excel users are different. Excel users had been evolving in their desire to use Excel all the time. On Wall Street, Excel was such a hammer that it was being used to nail nearly everything. One of the biggest new scenarios was using Excel to create pitch books for financial products. By removing grid lines and making clever use of fonts, borders, table widths, and the sophisticated macro programming that was a hallmark of Excel, one could create a pitch book without ever leaving the comfort of a spreadsheet. In Excel 3.0 there was even a presentation template that made Excel look like PowerPoint complete with animated transitions between slides (which were really ranges of cells). It made sense, therefore, that adding spellcheck would finally become a useful feature.

Word, Excel, and PowerPoint adding robust spellcheck proved to be a nice addition and emphasized the suite. Word had created a breakthrough idea, which went on to be a universal feature anywhere people typed, background spellcheck or the ubiquitous little red squiggles under (mostly) misspelled words.

The origin of the feature was a product of multiple small ideas and thoughts that piled up over time, starting with an incredibly novel research approach the Word team had done using Word 6.0. Reed Koch (ReedK), a longtime program manager in DAD, was one of the early proponents of studying how people used the product in the real world. This was not as easy as it sounds before the internet and cloud computing. To study the product “in the wild,” the Word team created a special variant of the product, called the instrumented version, or IV, which was the same product in the marketplace except it recorded what Word commands were used (menus, toolbar buttons, keyboard shortcuts, dialog box choices, and more) and in what order and frequency. Data was gathered from a small set of selected informed volunteers who knew that their actions (but none of the content) was being collected once we installed this special version on their computer. After a few weeks we returned to the customer site and collected the data, using a stack of floppy disks, and replaced the IV version with the regular product. This use of real-world data was a pioneering effort and formed the foundation of how the applications would collect and use data on the internet in just a few short years.

Program managers pored over the data and analyzed it (using Excel of course as well as Access because the datasets were so large), trying to understand patterns and places where customers were getting stuck, using too many steps, or failing to use a feature that would have made things easier. The wealth of insight gathered from this approach could not be underestimated and building IV versions became a significant part of customer research that led to many of the internet and cloud innovations in future releases.

Aside from learning things, like the fact that Print was the most common command (more so than Save!), or that as many people used each of the menu command, keyboard shortcut, and toolbar button for cut/copy/paste, or that features for assembling long documents (table of contents, index) were not frequently used—all of which most might think obvious—some important things were annoying users. One of those was the message that would pop up: “The spelling check is complete” with an OK button. It was a pointless message that did nothing but interrupt workflow, thousands of times.

In addition, the IV helped to inform the team that with great consistency, if during a spellcheck a suggestion for a misspelling was chosen as a correction then it was one of the first suggestions listed or it was ignored. This insight would form the foundation of one of the biggest advances in IntelliSense, spellcheck while typing. Getting to that feature required connecting a few dots.

Invisible to users, Word did work behind the scenes to keep the document up to date for printing while typing or reading. For example, if a document had page numbers and added text in the middle of a document caused flow to the next page, then in the background, without slowing Word down, page numbers were adjusted to repaginate the document. In a world of operating systems with limited memory and CPU, this was a nifty engineering trick (essentially Word was its own mini operating system). Today we take for granted the ability of computers to do work in the background, but prior to Chicago this wasn’t supported and took incredible trickery to pull off.

This was called the idle loop, because it was where the program looped or did nothing while a person was taking those tiny little breaks when typing or thinking. Could this background processing capability also check the spelling of documents without taxing the system and slowing everything else down? Writing code to take advantage of this idle processing power was somewhat of an art and the developers often referred to it as a devil’s playground of sort—one wrong addition or ordering of background tasks and the whole thing would grind to a halt and be very difficult to debug.

PCs were getting more powerful, so much more powerful than when the original spellcheckers were programs purchased separately from word processors and run after typing simply because there was not enough memory on the computer. The first word processor I used was called WordStar and it came with a separate program called SpellStar to check spelling. It was cumbersome. Integrated spellchecking was a big improvement, but it was still modal—a separate step and manual operation. PCs were 100 times faster since SpellStar but word processing documents had not grown at the same pace. What could the team do with the power that was otherwise sitting there idle?

Running the spellcheck in the background while typing was simply taking the idea of background processing to the next level. It was so important that background processing was a key part of the patent application. The implementation frustrated our partners on the Chicago team and at Intel who were evangelizing the idea of using Win32 threads as the way to add background processing. It also happened to be a feature of these modern operating systems and chips, but the overhead and complexity of rearchitecting for threads (for background spelling, printing, pagination, etc.) was far too high for such a critical capability, especially when processors were already becoming far faster than required for editing.

The lesson from the IV was that showing the closest matching words from the dictionary using a convenient right-click menu would have a high likelihood of being correct. The red squiggles were simply reflective of a proofreader’s style of mark (also one of the early uses of color in the interface). Just in case, Word left the existing interface in the product for good measure. It also made use of the right click menu, which had been introduced across the products in Office 4 and had become a defining feature for power users.

The feature did need a way to communicate to users that “something was happening,” and so a small animation was placed in the status bar of Word at the bottom of the screen. Originally the team wanted to use a tiny buzzing bee, as in “spelling bee.” But as was quickly pointed out by the diverse team that made up Word, such an iconic representation did not translate to other languages and cultures. The result was a little notebook with a squiggling pencil. Whimsy was difficult at global scale.

The feature was not without critics. There was an unintended side effect of opening a document which was as soon as the background processing kicked in the misspellings were identified. Maybe it was a company name, or a city, or a product name but these all looked like misspellings particularly in a world of sharing email attachments when the custom dictionary was different on the other end. Word introduced a number of subtle tricks to help with this, such as not marking words until an edit and providing for an easy ignore button that would unmark the incorrectly flagged text.

Still some people were so frustrated they wrote letters (actual letters) to BillG to complain and those would invariably end up in my inbox. Often these were just irate at proper names being flagged as misspellings, such as from members of the Phenis family who often exchanged letters and did not like to see their name underlined, and they especially did not like the suggestion. We quickly removed the offending suggestion in the next update. The letters back and forth continued for some time as the product update took a while to reach all customers.

Sometimes things got a bit over the top. A public radio broadcaster hosting a music show from Oregon was rather irate each week as the playlist was assembled. Every time they cued up their favorite Queen of Soul the red squiggles offended them. Again not just the squiggles but the alternate suggestion for Aretha Franklin was really what got them going. As you can sense from these two examples, the words referring to anatomy had to be reviewed even though Word was used by medical doctors and scientists all the time. The host threatened to “unleash the indignation” of their viewers if it was not fixed. The broadcaster was so annoyed they started sending the letters to their congressional representative claiming that Microsoft’s monopoly power was to blame. That got me in a long thread with what I assumed at the time was a zealous intern. Once again we removed the words and added names to the dictionary. I only had to endure one last broadcast where the host read the letters of campaign’s success on air.

While such letters were obviously not representative, they proved extremely important to Microsoft’s culture. Most every product hallway had a wall of letters from customers, usually at the extremes of loving the product or incredibly awful experiences. Other than the instrumented versions in Office and the samples of telephone support calls, anecdotes were the primary real-world inputs. While there was a special product support phone number that executives could use to escalate an incident, the company did not have a systematic approach to the onslaught of problems that came from millions of customers, whether a problem was Microsoft’s creation or not. Nevertheless, I enjoyed these letters and the dialog that came from replying, including the dozens of times I refunded the price of a product for whatever reason brought great frustration to a customer.

Background spelling with red squiggles ultimately became a showcase feature for the product and made the lofty phrase IntelliSense make sense to reviewers and customers. Groups all around the company asked for the IntelliSense code so they could add it to their products, not even realizing it was marketing. IntelliSense spawned endless jokes for wanting red squiggles under things in real life, as in “This idea should have red squiggles.” In brainstorming sessions at a whiteboard, someone would invariably put red squiggles under a misspelling or lame idea. Scott McNealy, the founder and CEO of Sun Microsystems, famously joked that Microsoft had a whole team of people deciding on red for squiggles and an option to change it—his attempt at making a joke (misguided and incorrect) about bloated features people don’t use. The feature became commonplace in every word processor and every browser and more.

On to 037. Capone and Email Without Typos

1994 to 1995: Sharing code and processes to build Office pays off and the concept of the suite takes hold in the market. The Windows schedule becomes a death march to finish what is hoped to be a revolutionary new operating system. Netscape IPOs in the summer of 1995, weeks before the public availability of Windows 95.

This is the first of five sections in this chapter on building Office 95.

Back to 034. Office 94, 96

Office94 had a plan in place, with a date and resources, as well as the major architectural bets of 32-bits and suite. There was so much focus on getting started and the resource constraints so extreme that, while this was the first release of an Office product, it would also be the last release for which the planning was fully distributed to each team with little centralized effort.

The organization was set with a feature team for each product and one in OPU. For the most part, the feature team leads were running this project, at least from the start, as the more senior leaders were supposed to focus more on Office96. Putting in place the plan for Office96 happened in parallel with a different set of people and a lot more attention from the BUMs. Unless there was something specifically troubling, for the most part Office94 was flying under the radar of DAD and had almost a skunkworks feel to it, at least at the start. That did not last long, for me.

As the new PM leader in Office, I was wearing two hats juggling both releases—in hindsight the first 12 months in Office were probably the time I put in the most hours working as I was learning how to manage managers for the first time, not to mention learning the DAD ways of working.

While I was juggling, among our team of about 15 program managers Mike Conte (MikeCon) was the primary program manager on OPU driving Office94. Mike joined the Excel team after experience running his own Macintosh startup. On Excel, he was a key to Excel gaining adoption at large customers, especially banks. A true New Yorker, Mike wore all black and had a no-nonsense attitude. He laid the groundwork for the release, but early on moved to a new role on the Windows team. He easily transitioned the release work to Heikki Kanerva (HeikkiK). Products had a formal management team that was ultimately accountable, but each release saw people step up and take on the informal leadership required for complex cross-group work. This was Heikki’s release to step up.

Heikki was a Finnish Olympic-caliber skier who found his way to Microsoft by studying business and computer science on a scholarship to the University of Alaska, after mandatory Finnish military service on a submarine. He joined DAD in the shared interoperability group and cut his teeth on shipping the enormously complex OLE technology. As it turned out, Heikki had absolutely the perfect demeanor to lead all of the teams through shipping the first synchronous release of Office. He was unflappable and possessed a military precision and the dedicated work ethic of an Olympian. And when needed, he could make light of a situation with a Finnish submariner expression that did not translate well at all into business English or, frankly, polite company.

Heikki led the newly formed Office-wide project meetings—the first time that key managers across all the apps assembled routinely to make progress on work. These meetings started off weekly and then as milestones approached, daily and then twice daily. While this was only a few people at the beginning, it was the organizational and cultural shift required to begin to operate as a suite, not as a bundle. These meetings became the operating heartbeat of the team, not a tax while the real work happened elsewhere.

I know it seems ridiculous to mention that we scheduled a weekly meeting for a new project, but up until this point creating Office essentially flew under the radar without an operational motion.

From an engineering perspective, the move to 32-bits was fairly smooth especially since much of the work had been done earlier in the side projects of making native apps for Windows NT as proofs of concept (and to make them available for sale). From a practical perspective, however, the transition to 32-bits hit Microsoft where it cared the most, performance. If there was one thing deep in the culture of the company, it was squeezing the most out of the scarce compute resources of CPU and memory. The move to 32-bits was inevitable, but the impact on performance was counter-intuitive.

In moving all the apps to 32-bits, no surprise but all the code got twice as big. And much of the data stored in memory got twice as big. Moving all that around made things slower. Crazy. For Office, 32-bits didn’t mean very much—Word already handled long documents, and spreadsheets could be pretty big. These products grew up in extremely limited memory.  In fact, many of our own tests were showing that the 16-bit versions of apps performed better on Windows 3.1 and were even a bit slower on Chicago. That’s because Chicago was also going through this widening experience with the operating system code. Everything was expanding. Except the system requirements, the amount of memory a PC required for Chicago and Office as printed on the box.

It didn’t take long for fingers to start pointing. That’s natural. The real issue was not necessarily the benchmarks which over time would tend to work themselves out (we hoped) but just how much memory was required to get reasonable performance. The key market promise for Chicago was that customers could upgrade their Windows 3 systems to Chicago and things would get better, but if those systems had only 4MB of memory or yikes 2MB then these systems would be horribly slow, and even more so if they also upgraded Office.

PCs were not only expensive in the 1990s, but they were also treated as capital expenses by companies. They had 5-year lifecycles, amortization schedules, and an expectation that the software could change over time without expensive and very difficult or impossible to implement hardware upgrades. Upgrading memory required a day or more of downtime, a “truck to roll” with a tech, and probably hundreds of dollars of hardware.

There was not much we could do about this but continue to work to reduce memory usage. There were some significant efforts in tools and analysis and some amazing work across Windows and Office to make things work on 4MB, but ultimately 8MB was “recommended” (versus “required”). This fell short of the 2MB Windows 3 required. As it would turn out, doubling the system requirements for each release of Windows became the norm as I would point out in about 12 years when we launched Windows 7. Office trended remarkably well and for many releases, the typical Office application (Word, Excel, PowerPoint) did not substantially increase requirements of about 2-4MB per application on top of the OS.

While reviewers and people in stores immediately noticed the system requirements as that was often the first aspect of a new release to check out, the main feature visible to people using Office would be long file names. In hindsight, it is hard to believe that for the first 15 years of MS-DOS computing, human beings tolerated naming their work with cryptic 8-character names. Still, Microsoft email names continued to be 8 characters.

Dealing with these 8.3-character names forced people to create all sorts of algorithms for naming files. While the convention was that the three characters after the period would determine which product created the file, there was nothing in MS-DOS (or subsequently Windows or Chicago) that required that (an area where Macintosh continues to be better, even to this day). As a result, companies created rules for how files should be named. For example, all the reports for the fourth quarter might be BUDGET.Q4, DETAILS.Q4, SUMMARY.Q4 for the spreadsheet, word file, and presentation instead of the default .XLS, .DOC, and .PPT. Chicago was moving to a model where the final characters of the name, the creating program, was hidden in the interface as had been done on the Macintosh from the start.

Even though such a change was long requested or desired, as with everything Microsoft did the pain of the installed base and embedded resistance to change always seemed to make a showing. A major bank once sent me a long feedback memo explaining how the pre-release test of Office for Chicago made their convention difficult to use and considered it a “showstopper” bug—long file names broke how they sorted all their quarterly documents in folders. A showstopper was a bug believed to be so bad that a product could not ship, and in our case meant it would not be purchased. Being able to use hundreds of characters to name a file was at first viewed as a negative by some, despite being so liberating. The feature of not needing to worry about the last three characters of the name was a feature, or so we thought, not a bug as the customer thought. Ultimately people adjusted, but this served as a reminder of how difficult transitions are even when the benefit is readily apparent.

Between 32-bits and long file names we believed we had landed most of the critical features to support Chicago. There was a long list of small changes as well, which we often tagged in our RAID database with the source “TT” for “tiny and trivial.” As Chicago made more progress the list seemed to grow in scope. And everything that came up was viewed as a “Pri 1” (priority 1 in RAID) work item by the Windows team for Office to do. There was a strong belief that if Office did not implement something then no other developers would—and within Microsoft there was no confusion over who was driving the agenda.

As the schedule marched through 1994, it became clear that the features we were implementing to be more of a Chicago application were helping us to become more of a consistent suite. Even though we were struggling across the Apps and OPU to become consistent the even bigger stick of Windows made it possible to drive some features that we otherwise would not have done.

While not central to the product experience but very visible the Microsoft Office Manager (MOM), a tiny little bar of buttons that floated in the upper corner of the screen that enabled one to switch between apps with a single mouse click, was a surprisingly popular feature of 16-bit Office. This feature came about when a college-hire program manager, Dean Hachamovitch (DHach), quickly prototyped this solution to a common problem on Windows 3.x before there was a Start Menu or taskbar, and it proved so interesting that it was completed using contract developers and shipped with Office 4.x, becoming something of an early symbol of Office and later copied by Lotus—by demonstrating that Office was more than a bundle but a seamlessly integrated set of tools. With Chicago, this feature had dubious value because of the enhancements to the OS, but removing it was certain to be a customer pain point—it was common for IT to build lessons and documentation around features to be used in training, and every major change involved reworking such in-house curriculum.

A new Office program manager, David Tuniman (DavidTu), spent most of the release trying to devise a useful and appropriately strategic evolution of MOM. He was constantly running back and forth from building 17 to the old single-X Windows buildings to find some way to integrate and show off Chicago. Ultimately, he arrived at the Office Shortcut Bar, OSB, which did the same thing as MOM but took advantage of the new Chicago feature called shortcuts—and once again turned out to be rather popular with IT, much to our surprise (we know this because when we removed it from a future release we received a lot of complaints).

We worked across Windows and Office to build on the new capabilities of Chicago. That was the win-win. OSB was a feature that just kept expanding and adding a ton of complexity (and exposing a ton of issues in Chicago). Reviewers and customers were enamored with OSB even though in the end it almost entirely overlapped in capability with the Windows Start menu.

After the “work on Chicago” features, there were two major themes for the product release, though to be fair none of this was determined before the products were being built—the constraints of time and not changing the file format dictated what work could be done and the themes arose by packaging those ex post. The themes were consistency by showing off the suite and IntelliSense, or a doubling down on doing things automatically introduced in Office 4.

Extending AutoCorrect from Word 6.0 to Excel and PowerPoint marked some of the first shared user-interface and functionality across the suite, and keeping with the idea of making the Suite paramount for everyone the Word team took the lead while working with OPU on making this feature happen. This did not come without battles. As expected, Word had ideas for expanding the feature beyond Word 6.0, given how wildly popular it was. PowerPoint was fine with the feature but could have easily done without shared code. Of course the Excel team put up a fight because not only did they resist the shared code, but the whole concept of AutoCorrect legitimately scared the team—the potential to introduce errors as text was automatically inserted that was different than the person typed (by accident perhaps!) Persevering, the result was a shared AutoCorrect feature that was a subset of the new implementation in Word, but importantly the list of customized entries was shared across the product. In hindsight this seems so very small today, but monumental at the time. When we did the first all team demonstration it registered with a round of applause.  

Consistency was something many had identified (including me with my memo on SmartSuite) and seemed relatively easy enough. But doing the work bumped up against how different the users of each product were, or so each product team liked to mention.

We did not embark on sharing a lot of new code to achieve user interface consistency and would save that for Office96. There were several initiatives that proved critical to market reception (and perception) as well as developing a suite muscle in program management. Importantly, the constraints pushed us to pick “high-value targets” for consistency.

The most visible user interface in the products were the two main toolbars—the one with all the basic commands (file open/save, print, and clipboard) and the one with all the common formatting commands (bold, italic, center, etc.) For the most part, what goes on these toolbars was the result of studying people using the product and what resulting documents looked like (reverse engineering the commands used). While everyone might be different, the top commands are consistent enough that we could design toolbars to be the same. Right out of the box we had a big step forward in consistency. For example, Excel had tools for drawing borders and using the new Maps feature, Word would have some buttons for new IntelliSense features, and PowerPoint emphasized the ability to include content from Word and Excel in slides. In many ways, the choice of these buttons were the earliest days of today’s “growth hacking” as we primarily populated the toolbars with common features, but every once in a while included something new or strategic in hopes of driving awareness.

I am skipping a lot of steps. Achieving consistency in toolbars was a historic battle that took years and several releases to get us to even some marketable level of consistency in this release. Originally, even the icons used were points of pride across different applications. For example, Word originally chose a piggy bank icon for the Save. It was only after realizing that such an icon did not share the same meaning around the world that Save was immortalized as a now obsolete floppy disc. There was a debate over little text bubbles appearing above buttons providing a long description of the graphical button, called tooltips, should they be yellow or white, and how big? Excel and Word each had different ideas on using color in icons—was color useful, necessary, or a distraction would occupy program manager battles for a full product cycle. The teams could not agree on how many pixels toolbars should use, should they be 15 or 16 pixels? While seemingly nitpicking, the premier demonstration of Office 4 routinely showed off this disagreement when switching between Word and Excel and a little 1 pixel shift would cause the demo to jitter, intentionally so to speak. The newly formed OPU led the charge towards a consistent and unified experience starting with toolbars, but it did not end there.

If the toolbar was the most visible then the file open dialog was the most used dialog and also was horribly inconsistent across products. In the MS-DOS era, the experience of opening a file was viewed as primary competitive advantage and major topic in product reviews. The Mac made this relatively obsolete because apps used a file dialog provided in the Mac operating system. Interestingly, Windows did not have a common interface for this available to developers until Windows 3.11 so the idea of competing on this interface still existed. Windows 95 had built-in interfaces to use, but by then there was a challenge in that competitors to our apps were not using them and all apps needed more advanced capabilities. For any other vendor, the idea would be to win and not worry about what Windows was doing. For Office, what Windows was doing mattered, and we had a mandate to consistently use the Windows dialog and to win in reviews. Having the Windows feature pushed on us in such a critical area was annoying, especially with so few on Windows committed to helping us win competitively.

We created a separate team to create a superset of the existing experiences across Word, Excel, PowerPoint and then use the ability to customize the new Chicago File Open to build a robust and consistent File Open user interface. In addition, they would inadvertently create a small feature that would become one of the all-time great areas of complexity for Microsoft across Office, Windows, and Server—an accomplishment few small teams could match. The feature came about because WordPerfect had done a fantastic job with search for MS-DOS and was certainly going to bring it to Windows—and Chicago.

The team created a mechanism that indexed the files on a hard drive and made it easy to quickly retrieve files based on searching for content. We called this personal Lycos after the earliest internet search engine. For Office94, it was a small button in the new File Open dialog and a small utility program called Find Fast. When the PC was not being used, the program started up and read through files and built the index—this was a great way to make use of all the unused processing power of a Chicago PC. But it also became one of the first features that stressed the performance of early battery-powered Chicago laptops, with slow hard drives and limited memory.

The problem was twofold. First, people thought their PCs were possessed by demonic forces or, worse, a virus because the disk activity light popped on and the PC started making the grinding hard drive noise even when not being used. Second, laptops generally had about two hours of battery life at best and this reduced that even more. We were fast running into trouble with this feature, but at the same time we received tons of positive feedback from early users, especially reporters and writers where the feature worked best. Down the road this would cause more “trouble” because it was clearly something that Windows should have for all apps, not just Office, and Windows Server should do something to compete with Lycos. Things were newly getting started with this technology, and it would follow me all the way through to my time in Windows.

But we had a great and consistent File Open dialog with a new way to search for all the files gathering on ever-growing hard drives.

There was a lot more to the release. One thing we learned is that when you build a product out of a bundle, no matter how hard you sell the sum of the whole is greater than the parts, people want to see innovation in the parts. We also learned people like to see whole new parts of the bundle.  

On to 036. Fancy Wizard and Red Squiggles

With the Office Product Unit in place, and the outline of a plan to release with Chicago in about a year (whenever Chicago was finishing, which was unclear) and a second major release of Office a year after that, we still had to sell the team on the whole approach. This included allocating resources both to OPU as well as the app teams. From the Windows (and thus Microsoft) perspective, anything less than betting 100% on Chicago was seen as a hedge, yet that was exactly what DAD intended to do. This was decidedly about managing the applications business instead of viewing that business as simply supporting evidence for a new release of Windows. Many firmly believed in a wait and see approach to Chicago which was already, and customarily, very late and the existing Office products would run great anyway. This post wraps up the chapter on building the organization and plan for building two releases in parallel. Looking ahead, the chapters tell the story of building those products.

Back to 033. Creating the Office Product Unit (OPU)

The use of year-of-release code names was not arbitrary but reflected a broad consensus within leadership that Microsoft needed to move to product releases that reflected more of an annuity or subscription relationship with customers. The idea of using the year moniker was based on how car companies used model years. We had yet to prove software could be released in this fashion, reliably, and we still lacked a way to distribute products so quickly, but the idea became a cornerstone of planning what to build and how to articulate value. The early naming research for Chicago was heading down the path of using a year name, and similarly Office 4.x would be the last “version number” release.

Marketing had mixed feelings about the year names. The biggest issue was that for some period of time customers would hold off purchasing a product knowing the current version was old. It was also quite stressful for the development teams that had no idea how to ship so much software on real deadlines.

Taking the idea of one release in 12 months and a second one 12 months later, both starting from the same date in late 1993 led naturally to naming the releases 94/96, or Office94 and Office96 (no spaces since this was all for file names and source projects). The 94/96 plan was in place. Sync within 30 days of Chicago in the spring of 1995 or thereabouts. Then Office96 12 months later.

The team’s passion was around Office96, with Office94 being somewhat of a strategy tax while at the same time being viewed as an excellent opportunity to prove out Office as a product and OPU as a team. The plan covered what was necessary and sufficient, albeit with a huge risk—what if Office94 took too long as Windows slipped, bumping up against Office96? You can see the schedule chicken already being played with the assumption that Windows would slip their schedule but Office would not, though there was little history across Word, Excel, and PowerPoint to think Office schedules were that robust and zero experience shipping the entire Office suite at once. History would show that no matter how far off Apps might be, Windows was going to be further off.

To execute required employing a great deal of finesse and some game theory. A plan emerged prior to me joining the team but one I sold to BillG as his TA. The Office team’s 94/96 plan split the resources across releases substantially in favor of Office96. Each Product Unit (Word, Excel, PowerPoint, and OPU) devoted one “feature team” to Office94 and the remaining teams were on Office96. A feature team was the organizational unit of a dev team and it is made up of a software development lead and anywhere from three to seven software developers. There was an equal amount of testing and two to three program managers. This was phrased (marketed internally) as “15 percent of the resources dedicated to Chicago” or “85 percent of the resources on Office96.” See what was done there? Everyone got something. When talking to Windows we emphasized the dedicated Chicago team. When speaking across DAD and especially to marketing, we emphasized the 85% on Office96.

Depending on perspective, this was either a relief, albeit still a high cost to pay to get moving on Office96, or a total snub aimed at Chicago. “What, only 15 percent of the team!?” One view was that the unreliability of the Chicago schedule was such that to “sacrifice” any more resources would not be prudent. The worst case would be, ironically, if Chicago did hit the date then too many people trying to do too much in Office would never finish within 30 days.

A different view was that 15 percent was hardly sufficient. Chicago was aiming to be the most important release for consumers (Windows NT was for business) and since the Office business was still a consumer-driven phenomenon it didn’t make sense to be so frugal. In the 15 percent there was a lot for Systems to dislike. If the requirement was to ship simultaneously and reliably with Chicago, then a small team doing the minimal amount was the most prudent, though such thinking was never in line with how Systems worked, which was an “all in, or not in” mindset.

More importantly with DAD, the major challenge with the Office96 part of the plan was the general view that 15 percent of the resources, reductions on top of the shift to OPU, would significantly impact the ability to be competitive within categories, a further reminder about the teams being reduced to “fund” OPU.

If your head is spinning reading this, then you can see why the whole plan of 12/24 was causing heads to spin and adding in the animosity (or just complexity) of the new OPU and shift to suites only made things worse.

We still needed a way to structure the detailed schedule. Normally we would have three milestones of about 10 weeks each. Given the mandate to sync with Chicago the schedule worked out to a single development milestone, instead of the traditional three-milestone schedule. Not only was a small portion of the team on the project but they would be doing a lot less work. Aside from syncing up the final date, the other issue was being available for pre-release testing on the Chicago schedule as they were going to want reviewers to see proof of 32-bit applications. This requirement further justified the schedule and resource constraints. That did little to appease Systems that felt we were totally hedging.

Without a feature list or specification written, things seemed shaky. Picking dates with resource levels set is the first rule of shipping.

Up until this point, most Apps releases had been dictated by the improvements in ease of use while adding productivity features that were the most logical next steps—there was innovation in category features across Word and Excel, but there was also a decade of history in the category, whereas PowerPoint was still establishing the category and faced different challenges. While most of 94/96 was chosen on business and customer grounds of the apps, the prioritization of what to do was heading in a new direction with the emphasis of the suite. There was a great deal of momentum in both the organization and the processes. It was easy for apps, even with fewer people, to keep going down the same path, and it also seemed right from a business perspective. A new product category demanded new investments and new priorities.

Office94 was about Chicago, that was clear, but what did that mean for the category? It would also be the first release of Office to ship all the products on time, which was unique. Office94 would provide marketplace evidence of an integrated suite of products by shipping at the same time with some specific work aimed at demonstrating its suite nature. Reviews were still written by category, though that now included a new category called suites. By and large the yearly magazine issue devoted to word processors or spreadsheets was one of the top sellers of the year. It would seem we needed category features to fill those pages and indirectly meet demands of customers and win reviews.

Times were changing, though. The key insight for building a suite, versus selling a suite, was that customers were placing value on the integration and consistency across the component products. Given the origin of suites as product bundling plus discount and the penetration of business software at the time, it was no surprise that the early value propositions from all the vendors centered on ease of use just as the category products did. For suites, however, ease of use was evaluated by user-interface consistency, the idea being that consistency made products easier to learn and thus easier to use. Technologically the idea was that if the products shared code between them to accomplish consistency, then using more than one product would also consume fewer system resources, like memory. It was still all too common for Windows users to see “Out of Memory” error messages and those became more common as users were encouraged by suites to run multiple products at once. There was the architectural synergy, minimal memory footprint, and code-sharing that BillG championed.

Office94 had no time for any major architectural investments. In need of constraints, another constraint was added: Office94 would not change the file format (.DOC and .XLS) and would rely on the same format as just released for Office 4.x. This became the mother of all constraints, as both a positive and negative. I recognize today this seemingly obscure issue, the details of a .DOC or .XLS file seem far removed from anything that could matter, but in reality that was not the case at all.

Here’s why: Through the entirety of applications on PCs from the start, new releases of products nearly always meant new file formats. With that change came the pain of making sure old files could be read and displayed and the experience of saving new files as the old format (to a floppy, for example, to give to someone) and alerting users when something would not work on the old version. While many assumed this was a conspiracy and some sort of theory of obsolescence, in reality changing formats was directly related to the underlying implementation of files. For the most part the file formats of apps represented a direct mapping of the internals of the product and what was stored in memory—in fact, in Word the file format was literally a type of virtual memory. There was neither a level of abstraction nor a mechanism to interpret data that the app did not know about. This clever invention was from CharlesS and something he brought with him from Xerox PARC and was a huge favorite of BillG, who knew all the details of the architecture.

Decades later, the idea of a file format seems rather arcane or even crazy. For the first two decades of the PC era, files were everything—files on hard drives, files on floppies, files on network drives, files on the Windows desktop and in folders, files on USB memory sticks, files in email attachments, files burned on to CD-ROM discs. Files were synonymous with work and files required a program. Thus, file formats created a virtuous cycle for users (or network effect in modern jargon). The more people used an app and shared files, the more their coworkers benefitted from using the same updated version of the product. And yes, Microsoft benefitted too. To many in the regulatory world this looked and smelled like locking in customers. To us it seemed like a natural and beneficial feature. Over time there would be diverging views internally at Microsoft over how critical or even appropriate leveraging this feature would be, as we shall see.

Today many have probably tried to explain files to a student who has only used Google applications and found doing so about as awkward as explaining linear television or fax machines. Except for the occasional PDF or those companies still operating with attachments in email, files are seemingly extinct for non-engineers.

What this constraint implied to the members of the Office suite was that Office 95 would not have any features significant enough to justify a file format change. People could hardly imagine what features might be dreamed up without a way to save them to a file—every interesting feature was tied in some way to saving it in the file.

Fortunately, the needs for Chicago started to echo the needs of 32-bit native applications on Windows NT. The list of work was short and easy to articulate and measure. Everything seemed doable, though there were many concerns about the customer value beyond validating Chicago. I spent a lot of time shuffling across the street to the Chicago dev hallway sort of reverse engineering what would ultimately become the “Windows Logo Requirements” or the minimal set of features that an application needed to implement to pass a third-party certification and receive a “Designed for Windows” logo for the box. Bill was anxious about the specifics of a list of features that apps would implement to be purpose-built for Chicago. The next chapter goes into details.

Apps needed to move to 32-bits. Chicago was going to represent the transition, requiring 32-bits and a 386 processor (which could come from Intel or AMD). While this sounded easy enough, there was a big problem.

Requiring 32-bits and a ‘386 meant that Office94 could only run on Chicago and new Windows NT PCs. Much of the market (and marketing) for Office was to get existing customers to upgrade—that consumed most all of the outbound efforts. The cost of a new PC was significant and adding on the cost of Office at the same time seemed exorbitant. For example, upgrading a 2MB of memory machine to 4MB might cost $200 in chips (often specific to the computer) plus the time and effort to install and configure (PCs required screwdrivers to open and often memory was tricky to install). This added up to a release without many new features that required a new computer purchase, which felt like a loser, or at least risky. Fortunately, it was only 15 percent of the team. Office96 continued on this level of commitment as well, which created a good deal of angst. So 100% of our resources were committed to 32-bits.

In order to believe in this choice, one had to believe that the number of new PCs and the number of people new to computing with Chicago would be so great that the upgrade market opportunity would be much smaller. That was an enormous bet. In the world of business this was the kind of bet known as burn the bridge. Once placed, there was no turning back. It was also the kind of bet BillG loved to make for Apps, as he did with Excel on Windows and with the internet. What we (and everyone at Microsoft) did not know at the time, was that getting a first PC with Windows 95, specifically to “get online”, would be a generational force that would make all of these conversations and concerns look downright silly.

This was a huge choice. Importantly, it was not the same choice our primary competitors were making. They were collectively still seemingly reluctant to go all-in on 32-bit Windows the way we were in Office. Chicago to most established vendors represented yet one more operating system from Microsoft they needed to deal with.

From summer of 1994 through the release of Office94, the DAD leadership team, sometimes called the gang of 10, wore two hats, Office94 and Office96. Every day, every moment seemed to be a context switch between releases.

What we did not anticipate was how that 15 percent would consume so much of the team.

What I didn’t anticipate was that we somehow ended up being so successful at convincing people not to worry about 12/24 that soon people like NathanM were suggesting a far better strategy was something like 12/24/48/60—that we should be building four different products in parallel including one that was 5 years out. It was too soon to be intoxicated with our own success, but such fantastical discussion was just getting started.

Far more important was actually delivering Office 95 as one product for the very first time.

On to 035. Windows 95, August or Bust [Chapter VI]

The most difficult transition for most new companies is going from a single product to multiple products, something Microsoft managed to pull off fairly early. Inevitably, the next transition is one based on combining products into a suite or bundle in an effort to deliver a better deal to customers while also simplifying (making more efficient) sales and marketing. In 1993 it became clear that Office for Windows would be as successful as Office for Macintosh, and the numbers from 1994 were proving that. The problem was there was a mismatch between what Microsoft was selling (Office) and what Microsoft was building (Word, Excel, PowerPoint). While there were many ways to potentially fix this, a reorganization was chosen. Reorgs are a most dreaded part of corporate life, but they are necessary. The most difficult reorgs are those that reflect strategic changes yet to come, versus “doing things better” that typify most reorgs. The Desktop Applications Division, by all accounts was doing fantastic, accomplishing this with the streamlined Business Unit organization MikeMap put in place. Why change now?

Back to 032. Winning with the Suite

The year 1994 marked the first time a new organizational structure also signaled a new product strategy for DAD. This was disconcerting to the existing BU structure as it created an unsolvable problem up front: What comes first, the suite or category?

It was challenging.

Just prior to when I joined the team, OPU was formed at the end of 1993. The leadership of the team was put in place and designed to make a statement by choosing Chris Peters (ChrisP) to lead the team as the division’s first product leader vice president (in 1994 there were 29 vice presidents among the over 15,000 employees). This was a huge deal at the time—an actual Microsoft engineer hired directly from college made it to product group vice president for the first time. ChrisP’s no-brainer choice to lead development for OPU would be Jon DeVaan (JonDe), who just finished up Excel 5.0 (for Windows). Leading testing was a new hire and a rare industry hire for DAD, Grant George (GrantG) who started on the team just before me. He joined Microsoft from a major project—huge in scale and in failure—the legendary Taligent project at Apple, which was cancelled in favor of Apple acquiring NeXT and thus returning Steve Jobs to the company. It wasn’t immediately clear, but Grant’s leadership and the elevated role of testing would be one of the most major contributions to making Office a reality of a product.

Staffing the team was a non-trivial choice. Do you draft people by skills and need or do you take only volunteers in the hopes of keeping everyone happy? Drafting people would have the effect of sending a clear message about priorities but no one performs well in a job they don’t want. Taking only volunteers would make OPU a happy place while all but guaranteeing the individual apps teams would lobby for people to stay in their jobs and solidify the discord between the apps and OPU. There was some experience in these staffing choices that came from the gentle persuasion that was used by leaders to nudge people from Excel to Word for example. The code bases, development processes, and cultures were different enough that changing jobs was viewed as a bit of a reset. Plus, why would one want to go from Excel to Word when a word processor is nothing more than a spreadsheet with one cell, as ChrisP used to say (Chris moved from Excel to be GM of Word prior to leading OPU).

The undercurrent of the staffing choice was that resources were being reallocated from individual apps to OPU. The apps teams were getting smaller to fund OPU, at least in the immediate term. This was a huge issue. The apps teams had plenty of work to do and could not understand how they would get all that work done while reducing staff size. Plus this all seemed insane to do right on the cusp of potentially winning in the market. The market in this case meant the market for stand-alone word processors or spreadsheets, not the suite market. The apps were not only committed to winning only in their category, but they had ample evidence the industry was not quite there yet as well. The feeling was at any minute Lotus could release a killer Windows spreadsheet or WordPerfect could release a Windows product that would lure all those existing MS-DOS customers to Windows. This was a legitimate concern. It was also not the bet Microsoft was making—the bet was on the suite.

Meanwhile every team continued to hire as many graduating engineers as we could, so we would have plenty of people to do all the work. In software development, the number of engineers is literally everything (perhaps, except for schedule time). The WOBU (Word Business Unit, renamed from OBU when the Mail product was moved to the new Messaging Business Unit) team had grown to over 65 software engineers (plus an equivalent number of Test Engineers and about 25 program managers). The Excel team was not quite as large and finished Excel 5.0 with about 50 software engineers. The new strategy and organization called for creating an OPU with 60 more engineers but seeded with 30 or so engineers from Word and Excel.

The reduction in the individual Apps team headcount immediately and decidedly created a negative view of this process. Teams felt they were being told to do more with less—there was no indication that OPU would be contributing to the mission of winning in categories or even adding useful features. When engineering teams are put in this position, they resist everything. In the case of Word and Excel, their default answer for everything asked of them was along the lines of “go ask OPU as they have all the resources.” At the same time, the apps assumed that OPU would in reality contribute little and what it did contribute would need to be reworked to perform well inside Word and Excel. In other words, OPU was viewed as a net negative, while resources were being taken away. At least that was the emotional argument at the time. It fell to JonDe to deliver and change this debate among developers.

Second, OPU was going to take the lead in orchestrating a planning and engineering process that would result in all the products shipping at the same time. Navigating the fine line between planning for a winning suite product and planning winning category products would be the main challenge. While resources had been set “from above,” what precisely to build and for how long were still open questions. This is what I needed to do.

Had the product plans been left to the business units, each would have chosen a release timeline of about 18 to 24 months with an error rate of perhaps three to six months. People always said, “plus minus” when talking about dates for projects, but in the history of software nothing finished early. Still, we continued to humor ourselves.

In some sense then, the suite could have come together if everyone hit the starting line at the same time and had planned on the same length of project, give or take six months. This sounded good enough, but Office was a retail business and that meant products needed to launch in time for retail purchasing waves like holidays, back to school, or new PCs in the spring. If one app missed the target then it would be back to the “air box,” which was costly and frankly embarrassing.

Alas, none of that mattered because the current products for the Office 4 release continued to hit the finish line at different times. Excel 5.0 was having a tricky time at the end, having integrated Visual Basic for Applications and finding challenges in getting the Mac version done. Word 6 had employed a different technology for the Mac version (a top-secret feature we created in AFX to enable Windows programs to run on the Mac, which later proved to be a big mistake) and was having even bigger challenges. PowerPoint, and not enough credit was given, had done a fantastic job at their Windows and Mac versions for PowerPoint 3 (shipping the second Windows versions based on their original Mac product), but was about to embark on a major C++ rewrite of the entire product for PowerPoint 4. The third release of the Microsoft Access database was shipping for the first time as part of Office 4. Turning from the final phases of shipping to starting again took time, thus getting to the starting line all at the same time would be difficult.

Rather than try to negotiate both a start and finish, the best plan was to develop some constraints and get moving. In any project, the most calendar time was burned by postponing difficult and somewhat arbitrary choices (choices that wouldn’t become more informed with time) such as picking a schedule. The focus of the new OPU were choices like that. There were objections to any approach and with the competing interests of four major category apps each with different engineering goals, there was no process to converge.

The biggest constraint was to ship at the same time—in the art of shipping software, the first thing is to pick a date and carve that in stone. But picking that date was not such a simple task. How much time for each engineering milestone? How much time for testing? How much time for localization? Not only were the process models different for each app, these were viewed as different for reasons that mattered. Looking back it was kind of amazing how hard everyone fought and how much debate we had over these schedule issues, all while not even coming close to finishing on time.

DAD had to simplify things—the endless long tail of releases, shipping coupons for promised but late updates, and the constant re-releasing of Office with updated bits were exhausting and expensive. Not counting the specific language/country releases, the year of Office released at least five times to keep things up to date and complete. The market, it seemed, appreciated seeing new versions of Windows and new versions of apps at the same time. Seeing apps from Microsoft on Microsoft Windows was especially validating, for both Systems and Apps. A number of data points reinforced this view, even going back to Excel on Windows, including the updates tuned for Windows 3 and soon 32-bit versions of Office supporting Windows NT.

There was a group of evangelists on the Windows team charged with doing everything they could to get the major vendors to work on the latest Windows release and ship the same time or at least commit to doing so. Many, many did. What was always so odd about this being in DAD was that we didn’t really get a choice but also didn’t benefit from the evangelism efforts. Whenever there was a chance, the reference products, keynote demos, and even advertising would show off other vendors more than DAD, at least that is what it felt like as were overly sensitive to each mention of our competitors. This was a perfectly valid strategy, but often counterintuitive to the outside world, if not scrutinized as the subject of conspiracy theorists who believed in some inherent advantages held by the Apps team within Microsoft. The only advantage we held was our Windows strategy was not up for debate, whereas our competitors continued to debate the priority of Windows.

The alignment of the next Windows release, Chicago, and a release of Office was the topic of many meetings while I was winding down my BillG role. I spent a great deal of time bouncing between the developers in Apps and those in Systems trying to understand the value of synergy and strategy as well as engineering challenges at the time. Aligning dates was one thing, but what about the implementation of apps and taking advantage of Chicago? What were the features of the platform that mattered to apps?

Suffice it to say, this was not a slam dunk for anyone. Chicago ran 16-bit applications perfectly well (that was a major selling point!) and the integration with Windows was still relatively nascent. Some things were known, such as that Chicago would support long file names (finally!) rather than FILENAME.DOC “8.3” names, but that was easy for Apps as the Mac had always supported those. In fact, as was often commented on from the outside, many of the important features for applications on Chicago were catching up to the Mac such as long file names, high-color displays, more extensive use of drag and drop, and so on. Much of the innovation in Chicago was about working with a wide array of hardware and peripherals, which didn’t exist on the Mac but for the most part would come for “free” to applications simply by being Windows applications.

There were, however, a great many deep technical challenges in the combination of apps, Chicago, and the recently announced Win32 API yet to be uncovered. Addressing these and reconciling them would come a bit later.

When would Chicago ship, though? In mid-1994 when all of this was being planned, Chicago was going to release to OEMs for spring 1995 PCs, which was not far off, but the schedule had already shown the standard levels of accuracy for the time. Remember this was originally Windows 4.0 shipping in 1993, according to my friends debating this while sitting at the hotel bar on a 1992 recruiting trip. Should the Office product aim for a release less than a year away? In boardroom discussions, I’d already seen Chicago slip several times.

When Office picked a ship date they meant a date, like June 24. When Systems picked a date they usually said something like “first quarter.” Earlier into projects, the dates were expressed as “first half,” which is approximately 180 potential dates as ChrisP used to say. Dates had a different meaning and “religion” across Systems and Apps.

The Windows team was not only shipping its own product but had a whole ecosystem of hardware and software they would line up to provide to PC manufacturers. The uncertainty in any one part was significant and chaotic, making MikeMap’s “gardening” analogy accurate. Aligning with this meant Office was one moving part in the equation. Given that Office was also viewed as easier or at least secondary to Windows, simply fixing the date of Office was enough. In other words, the idea would be at the company level to treat Office as an external dependency on Windows. Strategically this made sense. But given that Office also was a business and had at least some history of shipping, this seemed weird.

Regardless of the reliability of the end date of the schedule, the overall length of the schedule was going to be short by the standards of a “full” product release. While these product schedules of two years or longer might seem absurdly long by modern standards, in practice the amount of code and complexity of what was being changed and shipped was comparable to what was done in the same period of time decades later. Distribution was the challenge—there was no way to get code to customers, so the only choice was to make it as right and complete as it could be for the one opportunity to ship. The ability to provide updates and more incremental features to customers over the internet was still 10 years away.

At the same time, the need for a longer, more traditional schedule was clear. Importantly, the leaders in applications, Lotus and WordPerfect, were committed to Windows and had released products, but they were not yet ideally taking advantage of Windows. The market, however, seemed patient and that was the biggest concern among the BU leaders. On the one hand, each app continued to be locked in a competitive battle within the category and the BU leaders were clear about those needs—Word still had not won over lawyers, Excel was still winning over bankers, PowerPoint was still creating the category (meeting rooms were still not using projection from PCs!), and the Access database was just starting out. In addition, the email and calendar categories had yet to make a real dent and Lotus was challenging with the inclusion of Organizer in their Suite. Additionally, Microsoft had yet to make a bet on building and developing a “truly” integrated suite—what did that even mean? Ideally there would be a good 24-month schedule of three full milestones of development for a “real” entrant into the suite market, enabling full releases across Windows and Mac with deep architectural changes.

The evolution to the Office suite was a major cultural change. I remember the progression of discussions speaking with the GMs. My first meetings, while I was still working for BillG, were about how close the battles were with competitors in categories. Then as months passed and the competitors seemed to have lost their way, the discussion became more about execution and asking if we could really build a suite or it would still be more efficient to brute force the needed synergy. The reviews at the time seemed to support that. Then one day after I joined the OPU team, PPathe, GM of Word, told me what he had started saying to the Word team. Whenever people complained about OPU he reminded the team “[T]he best feature we have for competing with WordPerfect is Excel.” He finally had his messaging that appealed to the Word-first zealots—they would win by having Excel be a great feature of Word. Brilliant.

The new OPU leaders knew they needed to have a schedule to accommodate Chicago and to develop the depth product work for the Suite. The plan decided among DAD leadership seemed impossible on paper—Office started on two releases and worked on those in parallel—yes, two releases at one time beginning from a somewhat staggered start given the tail of Office 4.x. Everyone knew that parallel releases did not work and wasted resources and created false expectations. At least that was conventional wisdom. We set out to prove it could be done. We did not have any other choices that made sense. This was such a big decision that even as I was interviewing with the team, the debate still raged. While my interviews were mostly informal, the most difficult discussions were asking me to pick an approach—knowing that the choice had already been made and BillG had been informed (schedules and mechanics were never his focus, so long as there was a release with Chicago and a vision for the next release he was fine).

The first release of Office, Office94, would ship with Chicago, at least “within 30 days of Chicago’s release to manufacturing (RTM)”, which at the time this schedule was picked was November 1994. This date for Chicago was nine months away at this point and would soon slip to February, then April, then tail end of June 1995. The project started at the end of 1992 shortly after Windows 3.11 completed in August of that year with an original date of December 1993.

The cultural differences between Systems and Apps could be ascribed to many things, but at the core it was the difference in philosophy and operations over dates. In Apps, dates were the core tool of the entire organization and the high-order bit for decision-making, execution, and accountability. Systems had equally strong beliefs around the ecosystem and partners. One measure of this was that Chicago would have six external releases prior to RTM, which was five more than Office, and those releases would go to more than a million people, compared to thousands for an Office release.

The second release, Office96, would ship then two years from the shared start. During the planning this became known as 12/24 for shipping one release in 12 months and the second release 12 months later. Culturally, not every team used code names, and so began the era of innocuous code names for Office releases as the two releases would be known as Office94 and Office96, respectively, based on the year they were scheduled to ship, which is how these will be referred to here until the names become official in the story.

To anyone in the final stages of the last releases of Office 4.x this seemed not only impossible once, but impossible twice. First, the general view of developers was that “nothing” could be done in 12 months—literally, working backward there would be almost no time to write code and develop new features of any depth. Second, the fantasy of each app hitting this same schedule for Office96 remained.

It wasn’t just that the team had signed up for the next release, but it also signed up for the next next release. Crazy talk.

On to 034. Office 94, Office 96

Strategically, the bundling-unbundling arc or cycle is one of the most common dynamics in technology. Something that starts off as a single product or category inevitably becomes part of a bundle of features or products. Only later that bundled product faces intense competition from a stand-alone product introducing a different point of view. Choosing when to compete with a bundle and how to innovate within category occupied our collective mind in Applications in 1994. A big bet was made to market the Office Suite (or bundle) while the categories were still in play. Organizationally and culturally, we were still very much a set of categories. Had the market settled on Suites or not? This is a question faced by most every company with a single successful product and provides some interesting experiences and lessons.

Back to 031. Synchronizing Windows and Office (the First Time) [Chapter V]

There were two major shifts taking place in the early 1990s together altering the market landscape for business software. The most visible was the move by the business market to Windows, beginning with Windows 3.0 but picking up the pace dramatically with each subsequent release, Windows 3.1 and Windows 3.11. Bringing networking to the operating system, a seemingly simple ability for PCs in an office to share files and printers, was becoming a force.

By 1993, Windows/DOS PCs were outselling Macintosh ten to one and Windows was on 30 million of the 120 million PCs worldwide, with Windows dominating new PC sales.

That transition itself did not instantly shift the Applications market, though. The leaders of each category, particularly WordPerfect for word processing and Lotus with its 1-2-3 spreadsheet, as well as Borland with both Paradox and dBase databases, were not only entrenched but had passionate customer followings. Law schools were using WordPerfect and newly minted lawyers were proficient in the inner workings of the mysteries of formatting a brief with reveal codes (WordPerfect’s mysterious codes that showed formatting before WYSIWYG, or what you see is what you get in GUI). MBA students were masters of the 1-2-3 slash commands for navigating a financial model. That Windows 3.x ran these products extremely well, because compatibility with MS-DOS was a key design point, only solidified them. Windows 3.x made running MS-DOS products even better by supporting multiple programs running at the same time.

However, the graphical interface was beginning to put pressure on existing MS-DOS leaders. The improved support for printing (supporting more printers from various manufacturers), as well as the ease at moving information from one app to another with the clipboard were tangible benefits. With the rise of laser printers, the era of producing business and school reports that included charts, graphs, and tables in-line with the text—all prepared camera ready—was a new baseline expectation. This was vastly easier with GUI apps.

As a result, product reviews began to evaluate the MS-DOS and Windows products in the same category. The word processor category, for example, included Word for Windows and WordPerfect for MS-DOS. The reviews would compare features but also compare ease of use at complex scenarios, often including the ability for documents to incorporate information from other sources. Even though the Windows applications were behind on features and had different user-interfaces from MS-DOS, there was an uptick in perception based on ease of use of GUI.

To be fair, the tech elites of the time greatly resisted the GUI—often claiming the mouse and all those graphics were counter to productivity. I had witnessed this myself in 1984 at Cornell when people looked at the mouse and shook their heads, referring to it as a toy, and to the inefficiency of lifting their hands from the keyboard. Working within the disconnect between evolving technology and entrenched elites proved to be a theme throughout my career.

At the same time, existing software leaders resisted or at least paced themselves with the move to Windows. Many over the years tried to either explain or rationalize this and much has been written. Microsoft committed a ton of energy trying to get the likes of Lotus and WordPerfect to be launch partners with Windows versions or to just commit to Windows, even as Microsoft was building Windows versions of its own apps. There was no head fake on the part of Microsoft—it was believed that Windows would be best with Windows versions of leading apps and the Microsoft apps would, as they had been on MS-DOS, do everything they could to compete and win. Even with all the effort, leading vendors viewed Windows as yet another platform and most were also not wild about adopting the Mac (this was the opening that was created for Microsoft) and were still focused on character mode platforms. The reluctance of betting on a platform Microsoft controlled with its apps was real, but in hindsight proved . . . limiting.

Ironically, the success Apps achieved on the Mac provided a winning strategy roadmap for Windows—both the applications and the operating system—in creating the right ingredients to take advantage of the market change from individual products to suites, the second shift of the early 1990s in business software. Whereas the killer app on MS-DOS was Lotus 1-2-3, on Windows it was really Office that proved to be that. The Excel team might say that they created the defining app, and that is arguably correct.

On the Mac, both Excel and Word had proven successful products on their own. In modern terminology, these products had clearly demonstrated product-market fit. PMF was coined by Andy Rachleff, cofounder of the legendary venture firm Benchmark. Product-market fit means a product so clearly satisfies a market need that the market literally pulls the product from the company, no matter any incidental flaws or execution challenges. I wish I had the term PMF to work with as so much of what I experienced is rooted in an understanding of what it means to work on something before, during, and after PMF.

PMF for Office on the Mac was a statement about the role of GUI in business (then only on the Mac) and the feature set of each of these products. Professionals were as passionate and committed, perhaps more so, to Word and Excel (and PowerPoint) on the Mac as professionals were to 1-2-3 and WordPerfect on MS-DOS.

The interesting business challenge was that a majority of customers were not purchasing both Word and Excel, and fewer were purchasing PowerPoint. We weren’t sure why that was—market size or price. Did fewer people need a spreadsheet than needed a word processor? Probably not. More likely, the retail price of $495 per product was the problem. The computer cost about $3,000 at the time. The notion that the software would become a significant portion of the price of the computer was perplexing at the retail counter, no matter how much Microsoft was spending on Research & Development or how much that metric might not make sense. The industry was not quite ready for software to become a bigger business than hardware—it was the computer business.

Creating the Office Suite was a brilliant move by Apps marketing. It created a new category of product while building upon the strengths of the existing products, and at the same time was a fantastic value for customers. The fact that no other company had all the elements of the Suite was a competitive bonus that would mostly not matter on the Mac but prove to be a significant advantage on Windows. The pricing for Office was an incredible bargain at $949 suggested retail. I remember buying copies for a professor back at Cornell from the Microsoft Company store where software sold at a steep discount to employees, essentially for the cost of goods. I don’t remember the exact price, but it was less than $100 though shipping it was costly as the box weighed ten pounds and was huge. Still, it was a popular holiday gift in 1990.

Windows Office followed Mac Office but with a slightly bumpier journey. Externally, with Windows, the challenge was first winning critical acclaim and customer love over the category competition. The journey would take years for some customers—not only were the MS-DOS leaders loved, but those products were hard to learn and customers invested a lot in the keystrokes, macros, plugins, and in the existing files, which were difficult to import and export with Excel and Word. The MS-DOS PC era was characterized by investing in a PC and software to the tune of $3,000 ($7,000 in 2019 dollars) or more, and then literally taking classes and buying books to learn to use the computer. I spent two summers in the mid-80s at Martin Marietta teaching people how to use WordPerfect and 1-2-3 (but never both to any one person as “secretaries” learned WordPerfect and managers learned 1-2-3).

For each customer, this would have to happen at least twice, but perhaps three or more times for Office to win. In other words, it wasn’t enough for Word or Excel alone to win, but both had to. In any given business organization, there were many lawyers using WordPerfect and finance people using 1-2-3 that made this challenge significant.

In evolving Apps to sell Office for Windows, the launch of Office 4 was a watershed moment. It wasn’t exactly a moment, rather a rolling series of releases that started October 1993 (while I was still Technical Assistant) and a massive wave of marketing and PR, including getting some major mainstream business press. The software was available as Office 4.0 for Windows. It contained the new Word 6.0 (the third release) and the existing releases of Excel 4.0, PowerPoint 3.0, Mail 3.1 (it was the fourth version of Office that began with Mac Office 1.0 in June 1989 containing Word 4.00, Excel 2.20, PowerPoint 2.01, and Mail 1.37). It took until the summer of 1994 and Office 4.3 for the full suite to be updated to include Word 6.0, Excel 5.0, PowerPoint 4.0, Mail 3.2, Access 2.0, and for it to also be available on the Mac. Including the time to translate the software into other languages, Office 4 released over the course of almost a year. I was still signing off on the releases at the tail end as GPM of OPU in late 1994 months after I joined the team. The version number chaos described above is intentionally included showing just how random it was for customers.

The idea of releasing all the updated products at the same time seemed to be a combination of impossible and undesirable from the perspective of each individual product following different schedules and with different category dynamics in the marketplace. The closest any product got to a ship date was Excel 3 by 11 days but imagine trying to get every product to hit the same date—it boggled the mind. More importantly, the GMs for each of the apps didn’t see any benefit to even trying such a feat.

The early days of the PC Revolution were characterized by two major product development forces. First, making things work at all was a huge accomplishment. Second, getting anything done on any sort of reliable schedule was not only difficult but almost an anomaly. Everything was riddled with bugs and late. What doesn’t get enough credit was how much DAD was beginning to figure out, and uniquely so, how to accomplish both quality and schedule. Excel, under ChrisP’s management, led the charge across the division.

Simply getting software out the door, releasing, was exhausting, and most of the burden for releasing Office fell to part of the new OPU program management team I had just started to manage. It was labor intensive and frustrating trying to create one product release from multiple product lines moving at different velocities with different engineering processes and levels of schedule precision, across both Windows and Mac. While the teams might have used the same words, the meanings differed, and the cultures built up attached a high value to those differences. Releasing Office meant combining all the floppy disk images across products on to a minimal set of disks (for cost reasons) and building a single installation program, while also maintaining efficiency in producing the standalone category products.

While Microsoft managed to create an Office release, we did so without a shared understanding of the basic steps each engineering team maintained. For all practical purposes, each of the product teams was almost like an independent tribe within DAD. Worse, OPU was viewed as just another tribe. Worse than that it was not even a major app on its own, just a bundle. Early adopters might have purchased Office, but they were clear they used Word and Excel, rarely mentioning Office by name.

All of this was happening under the constant scrutiny of product quality, the second major challenge facing DAD. Word, as solid as it was, continued to have perception issues (or a reality) regarding product quality. Like many products, Word 6.0 for example, was known to be one where customers were better off waiting until the first servicing update or point release, Word 6.0a, before it was deemed reliable. It was not uncommon for industry press to get caught up in anecdotes about bugs and quality. There was little a product team could do about that given that the only data that existed was what Microsoft recorded in private bug databases and haphazard customer reports or press anecdotes. Huge amounts of energy were spent by the marketing team to manage the perception of product quality. Often one reviewer would have a bad experience and for months not miss a chance to mention that in a weekly column. The fact that most writers in tech had started to use Word (along with Windows for the first time) and most had personally run across data-losing bugs, only increased the frequency and gravity of this challenge.

Across Microsoft and the industry, every product went through a similar release cycle including the market confusion over the quality of a new release. Every new product released later than some expected, certainly later than the original schedule. Bugs were reported and word spread that the new product still had bugs as though a product could ever have no bugs. NT was rumored to have thousands of bugs even when it shipped. Interviews and calls to reporters with the company followed, making clear the product was the highest quality ever. An announcement of an update always followed. Professionals concluded it was important to wait for the update. The press concluded the product was rushed to make a deadline that had passed. Marketing entailed a significant effort remind potential customers that there was no need to wait and the quality was high. Then a release or point release shipped, and the product was ready for market. In practice, it was quite typical for a product to become substantially better with these first updates. Such was the climate of these early days.

Creating the suite, as difficult as it was, had started to transform the business, and the bet being made in late 1993 with Office 4.0 for Windows and creating OPU was that the future of the business was the suite. Over two million copies of Office were sold in that fiscal year, and half of the overall DAD business (which was itself half of Microsoft’s revenue) came from suites compared to sales of single products. Office was itself a $1 billion business. An actual $1 billion dollars, not an accounting gimmick or allocated revenue. Each license of Office that was sold was essentially a retail sale counted on that day—it would be a few years before multiyear licenses would become the norm.

The creation of OPU, described in the next section, was a major effort in DAD and came a few years after MikeMap’s enormously successful and effective Business Unit structure. Still, any time something that people loved and was working changed, things became difficult. This was no different. Incredibly, what started as a marketing experiment transformed the business and the industry.

During this time, Lotus had finally and fully committed to Windows with a major update to 1-2-3 for Windows. Lotus had, through acquisitions, a full complement of products to create a suite known as Lotus Suite first releasing it in early 1992. Building Office was no longer a nice way to sell more stuff, but had, seemingly overnight, become a key entry in a major competitive battle.

Unfortunately, this meant BU leaders were in both a suite war and a category war. Or did it? The market was transforming, but how quickly? Would focus on competing come at the expense of competing in traditional categories? How could we tell if we were making a lot of money selling standalone products as all the competitors to DAD were doing? The answers were not readily apparent. Any time a business is in transition, decision makers can lose sight of the cause and effect of actions. Are today’s numbers secure? Are they relevant to the future? Did last year’s choices still matter? Is today’s revenue predicated on doing more of the same or a bet on the future?

There were some issues to consider. The industry had not yet bought into suites. While there was a wave of broad reach press about the transformation of the industry being fed by both Lotus and Microsoft, the product reviewers and industry analysts were rather undecided. Should customers get all their products from one vendor? Would customers be happy with a suite when one or more of the elements would not win reviews in a category? Why don’t the vendors focus on making their individual products interoperate? Would customers come to value consistency and integration across products more than specific innovations and experiences within a category? At the extreme, there was a view that suites were somewhere between marketing gimmicks and attempts at locking customers into inferior products that can’t stand on their own. The constant grumbling was “suite versus best of breed” and “most people don’t need so many products.”

Second, the category battles on Windows seemed to be just getting started (unlike on the Mac where it seemed Microsoft had little risk of losing on word processing, spreadsheets, and presentations). To those working on the categories, particularly BU leaders, the Windows competition and market situation felt decidedly different, and more precarious, than the Mac. Some believed betting on suite consistency and integration felt like a way to make a worse spreadsheet competitor just so it could do some stuff with the word processor—a feeling shared by many in the industry, not just the hallways of building 17.

Third, the notion that somehow magically all the products (and BUs) would agree to ship their products at the same time and meet these schedules with good quality seemed, well, laughable. The Office 4.3 nine-month lead up had been nothing but staggered releases of products so there was ample evidence to suggest such an alignment would be impossible. Nobody wanted to hold back the shipping of a single product because another product was out of control. We were there to ship not to stare at the finished work and admire it.

Strategically, one would have to make a leap to agree that suites were the future, especially on Windows and especially as a BU leader being held accountable for success against one category competitor. Operationally, the leap to designing these integrated scenarios and shipping them at once seemed nothing short of wacky. To each BU, it seemed like a case of taking on the most external dependencies possible and hoping for the best at a time when the culture was to reduce all external dependencies. The fact that this was teams at the same company in the same division in the same business did not make it feel any less external.

In the waning days of stand-alone apps versus the suite, a widely-distributed memo emerged from the Excel program management team by Lisa James (LisaJ) outlining a process to “manage” dependencies from the perspective of Excel. The approach was structured and hierarchical, with Excel sitting at the top of the hierarchy. Every other team was a dependency to Excel and Excel had the right (and obligation) to fully manage that process. It was the hallmark of shipping and hardcore. Ultimately the goal was to minimize dependencies whenever possible and if not then tightly managing a dependency using a rigorous process was required. This model worked for Excel and was critical for innovations such as Visual Basic but would prove challenging to scale. To any team on the receiving end of this process, it felt a bit intimidating, as in don’t mess with Excel intimidating. But it worked.

In building a suite, there were countless external dependencies as everyone involved was an external dependency to everyone else. The BU approach could not be operationalized for this to happen. Plus, it was suffocating. The rule of thumb was to basically have one dependency per project, which was impossible in building a Suite that was filled with dependencies. The idea of dependency management would ultimately grate on me so much we effectively banned the term and renamed all such relationships partnerships, while also changing the tone to be more congenial and less authoritative.

In our first Office-centric effort to shape the program management team, we actively evangelized the idea of partnership over dependencies with a new memo and training, along sweeping change in operations and even our vocabulary. In the process our team pioneered many of the approaches used to build products spanning divisions. We did away with dependencies and introduced the idea of partnering.

As it would evolve, the idea of betting on collaboration and partnering across the teams would prove to be a huge cultural shift within the Desktop Applications Division and the new Office Product Unit.

On to 033. Creating the Office Product Unit, OPU

Welcome to Chapter V. Subscribers, if this were a printed book then you’ve just read through a typical trade press book by word count. Since we’re only in 1994, now you know one good reason why Substack makes for a better approach.

1993 to 1994: The rise of the internet dramatically accelerates the growth of the PC, the Windows PC in particular, as it soon becomes a must-have home appliance and an essential business tool for most every profession around the world. Windows PC unit sales have doubled since 1989 to over 40 million units and the growth rate was increasing.

Microsoft and the industry were in a transition. The world was fired up about the Internet and World-Wide Web, while anxiously awaiting a PC that was really up to the task—that would be Windows 95, code name Chicago. Unfortunately, Chicago was running late. Still, the Internet offered a real break in computing separating the early days of 16-bit computing from what was to come with 32-bit computing.

Inside Microsoft’s hallways the mood was different. Most products were still late and buggy, and importantly the strategy remained confusing internally. “Windows, Windows, Windows” was the top line, but the differences and even rivalries between the two Windows teams, Chicago and Cairo/NT, made for complexity. Applications spent the better part of a year finishing the release of the much-hailed Office 4.2, which was the last 16-bit product. While Windows and Office were the main products, the company was spawning new shiny objects at a feverish pace. Online services was growing incredibly fast and the Consumer Division was becoming the favorite destination for the increasingly experienced workforce.

During this I needed to find a new job and would learn valuable lessons along the way.

Back to 030. My Performance Review (and An Expense Report)

During a visit to my family in Miami, I was bored with the July heat and endless trips to the mall to avoid the heat, so I went to the local CompUSA to buy the newly released Lotus SmartSuite version 2. Wanting to spend time with it firsthand, I loaded it floppy-by-floppy on to my Compaq LTE laptop running Windows 3.11 and used the better part of the vacation diving deep into the product.

The main messaging for SmartSuite was consistency and the way in which each of the programs worked together. At Spring COMDEX 1994, the booth had been a relentless chorus of a work together jingle. The promotional materials offered up SmartIcons® shared across applications as supporting evidence—basically toolbars with customization. As I began to use the 1-2-3 spreadsheet, Ami Pro word processor, Freelance graphics/slides, Lotus Organizer personal information manager, and Approach database (the latter four were acquisitions), I saw a fairly sophisticated suite of products, but I didn’t see a lot of user experience consistency.

It was weird. It felt like we were being marketed to. We were.

A normal person would have taken screenshots of the user experience and compared them. But I was a developer tools person, so I groveled around in the compiled code looking clues to see how shared SmartIcons were in reality. This was a big deal to my Apps friends because performance was everything and loading Word, Excel, and PowerPoint meant a good deal of duplicated code. Surprisingly, all those buttons took a lot of memory and used scarce graphics resources in Windows. Office was a bundle but not an architected product (yet).

Much to my surprise (but given the acquisition history of the product it should not have been), not only did each Lotus app have its own copy of icons, but each frequently varied across apps.

Busted. We were being marketed to.

I quickly put together a nearly 30-page memo, detailing inconsistencies and inefficiencies in the product. I made a giant table of copy/paste between apps to see how each was handled. In hindsight, decades later, nobody would think this was even a problem, but in the early days of cross-application scenarios, simply moving information between products was hit and miss. It had been an area Office 4.x had worked hard on, especially using the new object linking and embedding (OLE) technology. I also detailed the disk footprint, memory utilization, and even the number of help topics.

Consistency was all the rage in the world of applications. There were two historic drivers of this. First, there was a strong belief, in part encouraged by Microsoft and Apple, that a graphical interface was inherently consistent across applications. Apple relentlessly touted their extensive documentation, Human Interface Guidelines or HIG, as a sort of rules of the road for building graphical apps. The HIG provided specific, almost Talmudic, rules for how to display commands, dialog boxes, and menus. Windows was just beginning to recognize the importance of this kind of effort and with Chicago would release a major set of guidelines, the Windows Application Design Guide or WADG (wad-gee). Unlike MS-DOS where every application made up its own user-interface, graphical products should all be very similar as a result.

Second, consistency was supposed to make it easy to move from one application to another without learning an entirely new and equally arcane command system. Most people used only a single application and what easier way to get more out of a PC than if moving from one application to another did not require learning a bunch of new user interface, especially in suites of products that were coming to dominate sales. In reality, developers would be developers and most every application went in its own direction, all justifying that by saying customers had specific needs (a topic we will return to with respect to Office).  

To that end my competitive memo was a source of pride. Whether or not any of my findings were relevant to sales or competitive positioning was unclear. My own lens was not particularly broad at age 27. But, up until that point, reviewers of SmartSuite had been quite impressed with the integration and I was growing increasingly disappointed in the lengthy product reviews that failed to reveal all the details.

While I wielded a great technology buzzsaw, I was also applying Microsoft’s perspective, not necessarily what Lotus was looking to accomplish or what reviewers would see. For example, my focus on shared code came straight from BillG as that was his hot button. The Lotus products clearly hadn’t focused on that at all. I thought they were “wrong” not simply different. This mismatch was something I had seen in the evaluations of Borland C++ versus Microsoft VC++. For example, Borland had a compiler optimization switch “/O” that was, basically, “make this code as fast as possible by enabling all the best optimizations.” To us compiler-heads at Microsoft, we thought of this as technical nonsense because each of the myriad potential optimizations meant something unique to the programmer (literally the entire alphabet of command line switches), but it had captivated reviewers. I came to champion (and push) the addition of “/O” for our complier and it turned out that it worked with reviewers. When Ami Pro, the Lotus SmartSuite word processor, demonstrated its new ease-of-use features under the umbrella of working together, it similarly captured the attention of reviewers, even if deep down in technical details it didn’t make much sense.

This lesson really stuck with me.

In distributing the memo, which as Bill’s TA garnered attention, and talking with the Office team it became clear that we saw things the same way—Lotus was doing a great job marketing—but the Microsoft team needed to do better with Office architecture. It needed to do a version of “/O” but one that was consistent and marketable. My writeup on SmartSuite offered some fuel for that work. Pete Higgins (PeteH) even emailed me to ask about the memo.

PeteH was the leading protégé of MikeMap and the spiritual leader of the newly named Desktop Applications division (DAD). He rose through the ranks, eventually leading Excel and then all of Office. Pete represented the kind of leader, manager, and team member we all aspired to be, representing the very best of the MikeMap value system and intense focus on customers and the business. On my Lotus memo he casually asked me rhetorically, “Why didn’t our team write this up first?” I loved that but also felt badly about it. My intent had not been to make the DAD team look bad. I found myself sending around apologies each time someone asked for the memo. It made me think about the lessons JeffH had imparted, about managing across teams when people perceived me to be in the “power position,” which as TA they certainly did even though I felt like a junior assistant.

The DAD teams were busy finishing Office 4.0 which started in late 1993 with a launch event but lasted until the summer of 1994 when the last product would finally ship. It was crazy—it took almost 9 months to complete a launched product. In fact, the first boxes (the physical boxes with floppy disks) came with a new version of Excel, but the older releases of Word and PowerPoint. Buyers were given coupons for the updates to the other applications which would dribble out over the coming months. Internally, the team referred to this as an “air box” because customers got coupons instead of new software. Finally, the much-promised Office Professional with a new version of the Microsoft Access database shipped in the summer of 1994. Office was the team that shipped on time! It was just that organizationally each of the component applications was a different team operating at a different velocity. Lotus even capitalized on this by running advertisements in the trade press pointing out the IOUs.

Over in Systems, products were also late but the strategy was confusing as well. The industry seemed to be questioning whether the future (there was always just one future, the future) was going to be Windows NT or Chicago.

The organizational split underlying the technology differences was front and center for me as I was looking for a job. I would talk to the Chicago team and hear about how they were the natural evolution of Windows and how Windows NT took way too much memory and was not compatible with all the software and devices that customers used, especially all the new games and multimedia on the Internet. The NT team mostly thought the Chicago product was fragile and toy-like and lacked the architecture to ever achieve the required security and robustness the PC needed. There was also the Cairo team that felt everything was rather pedestrian until they would ship. Meanwhile the industry was just waiting and waiting for Chicago. In many ways, Windows 3.11 was old news. Microsoft had been touting 32-bit computing long enough and now the market wanted a product. In particular, all the new Internet tools really needed the connectivity and multi-tasking capabilities in 32-bit Chicago.

The number of new products under development across Microsoft was stunning. I’d seen them spring up in meetings with BillG. These new teams were attracting seasoned developers and program managers and provided new opportunities for career growth. Though at the same time there was a growing tension between the major teams like Applications and Platforms (or Systems in old terminology) and these new teams, be it Online Services, Consumer, or the new Advanced Consumer Technology groups. The prevailing view was that people were drawn to these new shiny objects teams to “rest and vest” because somehow the work was perceived to be easier than slogging through compatibility bugs and increasingly difficult memory and disk constraints. Such a characterization was decidedly rude, but it was in the air. Microsoft was developing a bit of a cultural pecking order. Increasingly groups began to talk about metrics like revenue per employee as a way of distinguishing the ever-growing list of teams that were in investment mode.

I needed to find a “real job.” There was not much precedent to this transition, but my self-imposed 18 months was almost up. Months after writing the Lotus memo, as Office 4.x was near complete, I started looking. The memo served to discuss the potential of working in DAD. It was not my first choice given my roots in Tools and focus on databases and programming languages in grad school. Plus, Bill had clearly demonstrated that from his perspective Windows was central and where the “hard problems” that required “IQ” existed. Still, my mentor and previous boss, Jeff Harbers, was an original in Apps and built our AFX team around that culture and he insisted and brokered a discussion.

That first stop was with Chris Peters (ChrisP.) At the end of 1993 with the launch of Office 4.0, ChrisP was promoted to vice president of the newly formed Office Product Unit (OPU) reporting to PeteH in DAD, who reported into MikeMap’s expansive WWPG. OPU sounded redundant—why did Applications need an Office Product Unit to make Office? I was confused and intrigued.

When ChrisP introduced himself he always said something like, “I grew up on Bainbridge Island, went to the University of Washington, didn’t have a car when I started at Microsoft in 1981 then worked on DOS 2.0, Windows 1.0, Mouse 1.0, DOS Word 1.0, and then Excel development manager (DM) and Word BUM [Business Unit Manager].”

His Microsoft pedigree was legendary. He was one of the few people to have worked on most of the major products, including hardware and in Apps, holding senior roles on both Word and Excel in development. That was a big deal. In reality, it was only part of ChrisP’s contribution—he was also among the most creative leaders at the company with a true fondness for art (he championed the acquisition of an M.C. Escher work as an original member of the Microsoft Art Committee and went on to become a professional artist) and at any given time he would concurrently and deeply be immersed in a new hobby like rockets, robots, architecture, bowling, or film photography. ChrisP was most well-known for instilling the culture of shipping—the idea that shipping software trumps everything—memorialized with the ever-present quote “shipping is a feature.” This shipping focus was elevated to historic levels with Excel 3.0 shipping a mere 11 days late from its original planned ship date.

For this newly formed group, ChrisP was thinking about picking a key direct report as group program manager (the talented leader the group inherited did not want to manage a large team). I had not managed a big group before, but then again most people had not. He was not as interested in whether I had all the answers myself as he was interested in if I could manage and lead the team. I was, in a sense, interviewing to join the DAD family, as much as to work on Office. Sitting in the courtyard between buildings 16 and 17, a patio with commemorative Ship-It tiles celebrating the release of each Microsoft product, we both started to realize DAD was the right fit.

DAD was organized by business units as a result of MikeMap’s transformative organization in 1988. Each of Word, Excel, and PowerPoint (and also Microsoft Project) were headed by seasoned general managers and had all the resources to plan and develop products. There was a single marketing organization which divided resources across the products, with dedicated leaders for each application. This organization worked spectacularly well and resulted in the leadership of Word and Excel on Macintosh and the increasing success of the new Office bundle.

My first work would be figuring out what “Office” meant—both the product and the newly formed team. Why was there a new organization to build the product people knew about? Or did they? The Office product was not close to as widely known as Excel on Windows or both Word and Excel on Macintosh. PowerPoint was light years behind. The Lotus compete memo gave some clues. All the meetings the Office team had held with BillG were about code sharing and consistency, something that customers wanted to buy but Microsoft was yet to sell.

ChrisP later offered me the role of group program manager (GPM) in the newly formed Office Product Unit. I reported to him. The initial Office PM team, called OFFPM, was 14 people mostly made up of the team that managed the setup and installation program. We would be growing quickly, but deliberately.

Two lessons really stuck with me in what would essentially be my last job search. First, I decided to run towards the fire and joined the relatively large and mature organization rather than join one of the exciting new businesses. Applications in 1994 was $2.9 billion in revenue compared to Platforms revenue of $1.5 billion. The success of Windows 3.x had driven sales of Microsoft’s own Windows applications to account for 85% of revenue by 1994, after years of dominance by Macintosh platform revenue. Joining Desktop Applications meant I was joining a team with a great deal of responsibility to Microsoft on the business side, and at the same time the team was established and had a very strong culture. It was exactly the kind of job many people at Microsoft were not gravitating towards at the time.

Second, the conversations with ChrisP about management were very difficult and had the direct effect of shaking my own confidence. It was entirely true that I had hardly managed anyone prior to this job and stepping up to manage a team of 14 with two levels of management was unheard of in DAD, where people worked their way up (as ChrisP had). The company was being forced to make these leaps because of the explosive growth in headcount, but DAD generally resisted that. In discussing this with Chris he explained what a leap this was for me and how in taking this job I was not signing up for a passive role in learning how to manage. I would need to rely on the strength of the team around me and also recognize the level of trust the organization was placing in me. While it was humbling, it was far more terrifying. Years later I would learn just how much of this was based on the newness of the Office Product Unit and DAD in a sense trying to create a new culture as well. There was no doubt a bet on me.

A note about today as I write this. I rarely ever gave direct career advice even for relatively routine internal moves at Microsoft. This transition for me cemented two things that I always do offer. First, run towards the fire in a big company, especially early in career. This is so much harder than it looks—the seductive roles are always the new technologies and new teams. It always seems like there is more opportunity there but there is also more opportunity to get little done because of the very forces of a big company that tend to draw all things towards the existing and critical businesses. Second, always make sure the team is making the same level of bet on you that you are capable of making on them.

The reason I was offered a such a stretch job was because the team (ChrisP and my peers) were going to support me and essentially train me for the role. It wasn’t that I was unqualified, but that the strategic view and the technology perspectives I brought were only part of the job. Managing people and leading a team at that scale were new to me. ChrisP reminded me with his final words, being a manager of a team this big is always new the first time. One day you’re a lead or not a manager and then the next day people are lined up outside your door asking you what to do. He assured me that he had the confidence I could do the job, but also that he and others were there to support me.

I was very excited to have a real job. In just about every way this would be the last job change I would make where I was worried about fitting in or if the job was right for me. I found a home and a family in DAD as I would quickly learn. For the next ten years and six releases of Office and innumerable service packs and bug fixes I would feel as though I was on a mission and part of something much larger and more important than myself. I felt as though any efforts I made would return so much more because of the strength of the team I was fortunate enough to be part of.

On to 032. Winning With the Suite

Summertime at Microsoft was also performance review time. I was also busy trying to figure out what job to do next and was quite stressed. While this is a brief look at my own performance review, there was a great lesson for being or managing staff that I carried with me for my career. This goes beyond the Rumsfeld-like Rules I crafted and to the relationship between the support staff and leader.

Back to 029. Telling the Untold Story

In July 1994, after almost 18 months as TA, NatalieY, head of recruiting but also in many ways the emotional leader of Microsoft, sent me an email reminding me that BillG needed to fill out the spreadsheet with my review score, which was Microsoft’s performance review system, and, more importantly, my salary and bonus. Yes, the review system in place was a spreadsheet managers filled out with a rating, raise, and bonus. Because of all the work and excitement of the job, I had totally spaced and not even thought about that. Natalie reminded me because she also knew I would be changing jobs soon and any new manager would want to know what Bill had thought of my work. I later referred to my time with BillG as “the two most expensive years of my life” because I missed out on the material compensation that I might have earned had I filled out the performance review form and received typical salary and stock awards. The non-material compensation was priceless, so, obviously, no complaints.

Most everything I did was well-documented because mostly all I did was send email about meetings I had with different groups or write memos about the lessons learned from conferences, using software, or other trips. I really took to heart the early advice I received, which was not to take up or waste too much of Bill’s time. In fact, we never met about what I was doing or should do. Except for ThinkWeek, I don’t recall meeting with him one on one except for when he would occasionally dart into my office to follow up on something or fix some beta product that stopped working. Even when we flew to the same place, I would take a different flight knowing that someone else would find more value in bugging him on the trip. Though I should note, Bill’s routine for flying was to sit in a window seat with a blanket over his head and not talk to anyone, often disappointing those hoping for a discussion.

For my review I wrote a memo, rather than use the performance review form, which wasn’t something BillG was familiar with. Rather than waste his time, the memo detailed all the projects I worked on and the memos I had written. I noted all reports I’d written for learning trips I had taken as Bill’s eyes and ears.

Except for one.

PaulMa, leader of all Platforms under MikeMap, asked me to go with him to London on short notice to help document what was going on with a sizable enterprise customer. PaulMa was the most enterprise-focused of executives and with Windows NT beginning to gain traction this type of customer learning was important. Having never taken overseas travel for Microsoft, I emailed Paul’s executive assistant, Kay Barber-Eck (KayB) for help and she obliged, booking a plane ticket and a hotel. I packed my blue suit and off we went to visit with several UK banks.

When I got back, I took the plane ticket (the red-backed carbon paper kind) and the hotel receipt (one night) and filled out the standard expense report in triplicate and gave it to JulieG like I always did. The following Monday morning when Bill signed things for the week he refused to sign off on the expense because “he flew business class” as per the note on the form. I panicked. The ticket was thousands of dollars, and I could not afford that on my own. I emailed KayB and she said to submit it again and tell him it was the policy, and it was okay. She let me know the employee handbook included the travel policy, which said flights of eight hours or more could be optionally business class. I copied that policy page from the employee handbook and printed out a note explaining myself. A week went by. The report came back unsigned, noting that the flight was seven hours 45 minutes. At that point, I was about to be overdue on my credit card bill. I panic-telephoned KayB. She said to bring the expense report over and PaulMa would sign it. Phew.

Microsoft was still a start-up in Bill’s mind. How could one not respect that, I asked myself.

Out of protest, I never sent Bill my trip report on the future of ATMs and banking from home in the United Kingdom.

Natalie insisted that I schedule a meeting with Bill to go over the review even though we both disliked scheduling time to talk. Bill read the memo and agreed with my self-assessment but zeroed in on one line, which to this day we still joke about.

In my performance review memo, I said that in an effort to be efficient and not waste his time I never asked for feedback about how I was doing or even what to do. Instead, I wrote stuff and sent it to him, such as the pre-meeting notes or trip reports, and then watched to see what he repeated to teams or forwarded to others. It was like training myself as a neural network. He got a real kick out of that. So much so that for the next few weeks in a meeting if he knew he was repeating something I had said to him, he would look at me and sort of grin a bit.

Everything in my career that followed can be traced to my time working for BillG as his technical assistant. The ability to think broadly while applying that to building products, balancing innovation and execution, treating innovation as a portfolio of work, and always keeping a focus on competition are a few of the skills and approaches I modeled and developed based on working in this role.

I got a small raise and no promotion.

But at least the expenses for my trip to London were approved.

One thing I mentioned in the review was how difficult it has been to figure out what to do next. Bill wanted to direct me to a specific job, but these did not feel like jobs. They felt more like problems (I would later learn in talking to many people that served similar roles at other companies, this is almost always how product/technology leaders think of staffing for valued contributors, which is the exact opposite of how people think of their own careers). This notion of putting a person on a problem reflected the Systems way of working, which was that the execs maintained a list of people and a list of problems and there was a constant juggling of assignments between those lists. As I came to learn, the Apps way of working was much more about assigning people to products and thinking first about what products needed to be built and who would be best. As always, this reflected Microsoft’s two gardens.

It also did not help that as AaronG, the previous technical assistant, told me the day I moved into the office, “every group is screwed up”. From this vantage point, all you see are the problems and there’s no shortage of those.

A vacation spent deeply immersed in some competitive software would change my trajectory and outlook.

On to 031. Synchronizing Windows and Office (The First Time) [Chapter V]

A more interesting aspect of being in a staff role is how your perspective changes from day-to-day execution to strategic milestones. From this perspective, one doesn’t see the daily progress as much as the experience of what the starting point was and then results. There are meetings and demos, and (tons of) daily builds in the middle (my favorite), but the experience lacks the context of daily trade-offs or even the realities of product development. It is very easy from a staff role to assume people don’t get it or they are messing up, but it just isn’t the role or even a valid perspective. This would be a valuable lesson I would learn in this job that I was not expecting.

Back to 028. Pivotal Offsite

The clock was ticking, and to get things done for Chicago meant starting immediately. Chicago, originally planned for early 1994 or maybe 1993 depending on who you ask, was not yet in beta and so practically speaking was not going to finish in 1994 given the time required for broad beta testing (recalling my previous Cornell recruiting trip and the debate over whether Cairo would ship before “Windows 4” aka Chicago later in 1993).

Evangelizing tactical work items for the internet strategy and making sure they landed with owners was my job as TA. With regards to the “Internet mania”, our mantra as per BillG was two-tiered: embrace and extend.

Much like killer app, the phrase embrace and extend proved to be far more loaded an expression than intended. Computing evolved by companies constantly finding ways to uniquely extend existing software and hardware, elements viewed as commodities, while at the same time always bowing to the existing investments of customers by claiming an embrace of any standards or winners. That was the view of how value was created—everyone built on all that came before. That was how everything worked. In a sense, each new product somehow related to the product it would supersede while extending it in uniquely valuable ways.

What had changed was the open-source movement that viewed everything as embrace with no advantage bestowed to any party, with any extensions going back to the community. As it would turn out, embrace and extend is precisely how nearly every open-source innovation was commercialized, particularly as software moved to the data center. Not everyone believes that is good, but it is what happened. In 1994, embrace and extend was synonymous with evil. Admittedly, it didn’t help that the phrase was sometimes attributed to Microsoft as “embrace, extend, and extinguish.”

With specific action items outlined, for the next couple of months I made sure the company was embracing the key protocols I had seen at Cornell (and that our brave corporate customers were beginning to demand): TCP/IP, email over SMTP, HTML for online documents, NNTP for discussions and bulletin boards, HTTP and Gopher on the server, and IRC for chat.

In doing so, I found myself in the role of shuttle diplomat or “glue” as we said looping around the cluster of single-X buildings, the location of the Chicago team, and the next version of Windows NT under development, Daytona, and over in building 16 where Peter Pathe (PPathe), the general manager of the Word team, sat. Many days I found myself almost in a constant swirl running between buildings in the misty drizzle of Redmond.

My agenda was to help identify issues and bring teams together to arrive at the common goals outlined at the offsite. I was to help, not do. It is a confusing a difficult spot to be in, especially as a self-described zealot, and particularly as someone with no responsibility for a product schedule.

Chicago was on a mission, a new mission to embrace the WWW. The team quickly came to its own point of view and strategy, which included the get on the internet capabilities, as well as coming up with a viewer and browser strategy. During the offsite the Chicago team affirmed this point of view, but the commitment was for after the initial Chicago release. The realities of the Chicago schedule meant that work that did not impact the product directly had a chance of being delivered simultaneously to customers because of the way OEMs ship new PCs, known as a service release in the OEM process—taking advantage of the ability to add features to Windows on new PCs even after the retail boxes of Windows were manufactured for upgrade customers who would later download those same changes or purchase the same-day add-on for Windows 95 called “Plus!” which in addition to those same internet capabilities including Internet Explorer 1.0, included games, screen savers, and other extras. While much would be made by regulators of these small changes in dates and what the “final product” was, this is what agility looked like in the age of massive software projects, a multi-month manufacturing channel required by ecosystem partners, and a schedule that was always a bit fluid until it wasn’t.

This became the plan of record led by a longtime engineer, Ben Slivka (BenS). In the short term, the strategy was to make sure developers around the world understood the underlying technologies provided by Chicago that made it easier to build viewers and browsers and to evangelize those—if Chicago could not have its own then at least it should have the widest range of choices from third parties. This was a tried-and-true strategy Microsoft had always followed—the best of first and most of third parties. The same type of work, meaning a combination of built-in capabilities as well as evangelizing third party capabilities, was going on with all sorts of extensions to the operating system from networking to USB support to Wi-Fi, but none of those would be contentious down the road.

Originally BenS was planning the features of the follow-on release, but seeing the situation of enormous growth in the internet, the already strong base infrastructure in Chicago, and the Chicago schedule, he devised a plan that involved licensing browser code as a way to kickstart the efforts for higher level viewers, especially WWW. In a series of negotiations (and after looking at some alternatives), the Chicago team ended up licensing the code to build Internet Explorer from Spyglass. In parallel, others looked at whether to expand on offerings for FTP, Gopher, or any number of other viewers/protocols.

With every passing day, it became abundantly clear that the WWW was the only viewer or internet technology that really mattered. The pace of adoption and growth of WWW servers compared to Gopher servers made this obvious.

Coincidently, and unknown to Windows, the Word team had established a contractual relationship with a company called BookLink, which also made a browser. I had seen BookLink at the Spring COMDEX show and it seemed like a reasonable commercial implementation of the current WWW (HTML viewing and HTTP protocol), and I noted such in my trip report. I pointed the Chicago and Word teams toward it. I knew Word needed HTTP protocol work, as Word was busy building HTML authoring (described at the offsite). Part of that required the ability to traverse URLs and fetch the WWW page. To do that, Word licensed the BookLink code, which bugged the Chicago team that thought Word was trying to build a browser (versus just read in an HTML file to edit). There was some combination of cookie licking and “stay in your lane” going in both directions, but also the technical reality that to edit WWW pages (HTML) required the ability to use those protocols, and the Word team had no intention or desire to start from scratch.

Roughly in parallel, the Chicago team was in negotiations with BookLink for their entire browser, but those talks ended when BookLink was acquired by AOL, among other reasons. At least in part my fault, there was a bit of the right hand not knowing what the left hand was doing across the Windows–Apps boundary, which was not uncommon (much to the chagrin of people who believed the relationship was much more orchestrated and sinister). The fact that both teams were moving aggressively was good, though I have to think the BookLink people got a kick out of our org chart.

The tension between Apps and Platforms was not rooted in people or organization like far too many believed. It was rooted in the approach to building products—there was a reason MikeMap’s two gardens description reflected an operational reality. Building a platform meant focusing efforts on creating opportunities for developers by offering abstractions in the form of APIs, application programming interfaces. APIs provide services that programmers use to the build applications. For example, the Windows browsers that were being built did not write their TCP/IP code from scratch. Rather, they used the Windows APIs called WinSock that provided a higher level of abstraction, so it was easier to build the browser. Windows did not, however, have any reusable code for rendering HTML as an example. That was something for later. Success for Windows might look like having many FTP and Gopher applications built using the Windows platform, something JAllard, along with the Chicago team,  and I spoke about quite a bit.

If the Platforms approach could be thought of as bottom-up technology problem solving, then the Apps approach was top-down starting with the user problem. Apps looked at a problem and wrote the code to solve the problem for the end-user, rather than a developer. There was less flexibility in how much to accomplish since, to an end-user, an app either solved the problem or it didn’t. Developers on a platform always had the option of building more code themselves or finding other code to use that helps. On the other hand, app writers did not have to worry about what other programmers thought about how their app is built or structured since that remained relatively opaque. Success for an app was having the most users, and that’s it. A platform saw success as having the most apps in a given category, even if some were not so great or all the apps did the same thing, so long as there were unique apps for the platform. I’m writing this as an either-or, when in practice it is a spectrum. At least it was viewed that way at times, which made any cross-group efforts that much more challenging. Knowing exactly when an app was an application and when a platform was a platform, and not the other, was often only determined in the context of a specific feature at a moment in time. That indeed is the true tension.

It would have been nice if Platforms and Apps teams were as cleanly separate as their description. In practice each took on characteristics of the other. Platforms built apps all the time, such as the Windows Explorer, Reversi, or Write—parts of Windows that to end-users felt like whole solutions and tools, even if under the hood these had APIs for developers. Apps routinely provided platform APIs for developers as well. Many developers used Excel as a platform to build custom financial or data access software, for example.

App creators were developers and they made choices all the time about using APIs from the platform or building their own simpler or faster solutions because they only solved specific problems. Platform developers routinely provide more than APIs, building out the first steps of an experience. When a new, exciting area comes along, the natural tendency for everyone is to adopt the technology, from their perspective. It was at these times of newness that the more standard traits of Apps and Platforms got tossed aside in the zeal to be first adopters.

The introduction of the WWW browser was such a time.

From all outward appearances, WWW browsers were apps. They were installed on Windows. They came from third parties. There were a bunch of end-user features. Even something simple, like printing a web page, seemed like a feature better done on the Apps team, since almost nothing in the platform supported printing. They were even a “category” in that there were several competing apps one could choose from, like word processors or spreadsheets. Most of all, if you wanted one you just went to an FTP site and downloaded that thing. A browser was clearly a thing, an app even.

That’s why many in the Apps group thought it was a good idea for an Apps team to build a browser. Apps were great at working from the end-user down, even if there were some APIs for developers.

The Systems team saw things as a platform. They saw the browser as a platform that Apps would target. The address bar in the browser could be thought of as almost a Start menu. The URLs were like the names of apps. The fact that browsers ran across many platforms and were the same was the kind of thing that platform creators don’t like to see—they want apps to be unique on their platform. The real problem was that the platform was woefully incomplete compared to Windows. They saw parts of the browser from navigating a URL to rendering HTML as reusable components that could potentially be used by others to build other browsers (the way developers built more games using graphics APIs in Windows) or even entirely different apps with browsers built into the app. The browser just needed more APIs.

That’s why many in the Systems group thought it best for a Systems team to build the browser. Systems were great at working from the APIs up, even if there was some user interface for end-users.

While those, like me, who favored the Apps approach thought this was a good discussion, it wasn’t much of one at all. There was little doubt that Microsoft’s browser was going to be a Windows offering, a platform and an app. Microsoft was a Windows company, and Windows was still in the earliest days of trying to win, as strange as that sounds. The superiority of Macintosh for the internet was not lost on anyone, and competing servers from Sun and Oracle were dominating a Windows Server that had not yet made a market impact.

The responsibility of authoring HTML falling to Apps with viewing owned by a new browser in Windows might have made sense to some. It definitely made sense early on when there was little hint that browsers would have editing. Things could not be so clean, however, because of a very strategic rich-content creation tool being developed. Blackbird for the new online service Marvel was being talked about broadly and externally with partners, especially print newspaper and magazine publishers. Blackbird enabled such partners to maintain the fidelity of their physical products online and even enhance the experience. At least that was the strategy. Blackbird cast a long shadow because of the early concerns from some of the country’s largest and most established media companies. Concerns were everywhere. Would Microsoft become a dominant media company? Would Blackbird prove to be a monopoly printing press? How would publishers make money on the WWW and was Microsoft going to be a gatekeeper? This might sound like crazy talk, but this is exactly what I heard at a time when no one questioned Microsoft’s dominance or ability to execute. For many industry insiders, Blackbird was some kind of shorthand for Microsoft’s future expansion into owning all content creation. It was more than crazy talk, it was just crazy.

It is entirely possible for a company to have exactly the right vision for a technology future but, by virtue of market position in a totally different market, be exactly the wrong company at the wrong time to try to realize that vision. This burden or curse of market leaders is a history that repeats. We were experiencing this for the first time.

Apps focused on being viewers at the “edge” of the WWW. For example, a professor with a course web page might post the lecture slides as a PowerPoint file on the page, which you might get to by clicking from the university home page to a department to current courses to a specific course page. This was all incredibly novel at the time when you consider the alternative was to pay cash to a student notetaking service for the notes for a lecture you missed.

Such a strategy left little room for Apps to participate in the WWW. This might have been perfectly fine if the WWW ended up being primarily about navigating to “files” the way Gopher had. The attraction of the WWW experience was being in a browser (an app!) and never leaving. Thus, Apps saw HTML as potentially the way for productivity documents to be rendered simply so they could be seen in the browser with the least amount of friction, almost like a new way to print. The idea that anyone could create web pages by simply using the tools they were already using seemed cool enough—for the time being creating web pages was akin to programming so this seemed like progress.

The Apps team was almost in the exact opposite position as Windows. Rather than a project that was late and getting later, Apps was on a much more constrained path. Apps was in the final stages of wrapping up the Office 4.x product, the last release of 16-bit Word, Excel, PowerPoint, and Access. The product began shipping many months earlier, but not everything was complete, and the first version of Office 4.0 shipped with older versions of some of the products. Shipping “Office” as one product was a challenge for the next release.

During the relative downtime of the Office products finishing, Word continued to polish the HTML authoring features. Surprisingly, PowerPoint was also at work on HTML. In a visit I made to the PowerPoint team in Cupertino to hear their views on the WWW, I received my first dose of Silicon Valley outside of attending conferences in Santa Clara.

At lunch at a Pizza Hut on Stevens Creek Boulevard in early 1994, surrounded by badge-wearers from Apple, Sun, and other companies, Lucy Peterson (LucyP), the program management leader, shared with me how customers were doing all sorts of crazy things to take slide decks and post them to the WWW. They were taking screenshots of each slide in slideshow view and then adding buttons for next/previous slide to use the minimal capabilities of a browser to show slides. It was crazy. I was caught off guard by how “informed” the distant PowerPoint team was about the internet. I hadn’t thought for a minute that this recent phenomenon originated there. Duh!

To save slides to the WWW, they planned to automate the manual process and make it much better and faster. This came later than the Word feature but proved incredibly popular in the early days of the WWW. If you spend time on the internet wayback machine, you’ll see old presentations with bubbly forward and backward buttons under a slide saved as a single image file, which were output with the PowerPoint Internet Assistant.

As Microsoft was making the transition to an enterprise-focused software company, top of mind was building out the global account management process. Account teams have an insatiable demand for information (translated into 30 or more languages) from Redmond including information sheets, demonstration scripts and tools, technical details, reference documentation, and more. In the early 1990s, a great deal was prepared for print production as well. To distribute this information around the world, a group in the Enterprise Customer Unit (SteveB’s newly formed worldwide HQ team that supported the account teams) collected information on CD-ROMs, which were airlifted by DHL to all the field offices around the world once a month. Using CD-ROM seemed leading edge and consistent with the direction of multimedia computing . . . at least until the WWW.

SteveB wanted me to meet with the team that did all the production and talk to them about using WWW. I did my standard demo but emphasized the distribution of information from tech companies like Novell and Sun. The team remained unconvinced. They raised a series of, in their view, insurmountable challenges, from power of formats to the effort it took to copy all the information to a local server, the lack of bandwidth to even download the materials in a timely manner in most offices. This was my first encounter with WWW meeting someone’s job reality. They didn’t see a path “right now.” Over time, the organization came to embrace the WWW and became some of the largest contributors to Microsoft content. It took time.

My experiences in meeting with Microsoft’s Product Support Service (PSS) faced the same challenges. PSS was tasked with dealing with tens of thousands of customer contacts every day. Most were from individuals calling up Microsoft, wading through a phone tree, and getting help with how to get something done with a product. People called asking how to format documents, install a printer, or, the most dreaded calls, of computers that were slow, crashing, or wouldn’t start. Operating PSS was extremely costly—all of us in product groups tracked call volumes, called generators, and had explicit goals to fix the top issues of the product. It was common knowledge that a call cost Microsoft something like $100, quickly eroding the margins on a sale.

For that reason, meeting with PSS came with the hope of making it cheaper and easier to solve customer problems. PSS loved the idea of distributing software updates over the internet. Taking names and addresses and fulfilling floppy disks was expensive and time consuming. This was already happening with ftp.microsoft.com and CompuServe.

PSS maintained an enormous online system called the knowledge base (KB). PSS engineers were goaled on writing articles that populated the system. These KB articles were the recipes for solving problems. While it seemed natural to just post these on the WWW, the early feedback and challenges showed how difficult it was to search. Beyond that, knowing if an article applied or not was the job of the human agents. Much of the dynamics of a call involved matching what a customer was saying to whether the KB article applied. KB articles are often nice steps preceded by a “do not try this at home” warning or caveat. Throwing these out to the WWW made PSS feel that the presence of the articles was to be call generators not cost reducers. They might have been right.

The use of newsgroups and USENET seemed like another opportunity. PSS was loath to engage with online chat with customers as it was extremely time consuming. On the phone incidents could be resolved in a few minutes. With online messaging or email-based support (already a top customer request) the back and forth could span days. Agents could go off shift or even on vacation and new processes would need to get established. Worse, providing these online contacts probably meant that after an issue was resolved, people returned to the “thread” and used it for other purposes months later.

They were probably right, even though in the moment I thought they were resisting the march of technology. Having been an avid USENET poster for Visual C++, and finding myself caught in many email threads, the concerns were in line with my experience.

When did Microsoft figure out the internet and when did it pivot to be an internet-centric company was the source of much industry chatter. From a Wall Street perspective, Microsoft adapting to, or adopting, internet technologies was generally viewed as one of the most significant corporate strategy changes in recent history. From a regulatory perspective, it is fair to say it was not only viewed with some skepticism, but a more sinister eye. Regardless, it made for an exciting narrative and in a sense a perfect place for a BusinessWeek cover story.

We received word from the most senior public relations people at Waggener Edstrom that a story was in the works, utilizing senior reporter Kathy Rebello. JAllard, BenS, Chris Jones (ChrisJo), and I kicked off a quick email thread and agreed on a timeline—we knew the press loves these kind of timelines. ChrisJo, a new recruit to Windows after working on Microsoft Publisher, was leading program management on the browser. The three of us had become sort of joined at the hip in our efforts and hit it off well. What did we know and when. I was using a predecessor to the Palm Pilot I had purchased in Japan to take notes and had a text file with the timeline that served as our script.

After a series of calls with many executives and participants across Microsoft and a lot of PR handholding, the cover story ran. The story covered exactly what we had experienced in many ways, at least from my perspective. The article had a photo of JAllard, BenS, and I. Ben was in his characteristic Hawaiian shirt. I was clearly in my grunge phase with perhaps the only plaid flannel shirt I ever owned. The story, in the July 15, 1996 issue, and the timeline amounted to an official record of a major corporate turnaround. The BillG memo, Internet Tidal Wave, a year earlier was viewed by many as the start of the turnaround. As we’ve seen here the work began much earlier. It takes time for the work to surface and for a story to come together so a broader community understands it. It also takes time for us to figure out how to tell the story.

The story started with a letter to the editor from the weekly MicroNews newsletter that was still printed and distributed every week:

Oh, our eyes have seen the glory of the coming of the Net,

We are ramping up our market share, objectives will be met.

Soon our browser will be everywhere, you ain’t seen nothin’ yet,

We embrace, and we extend!

Battle Hymn of the Reorg

Anonymous Microsoft Employee in MicroNews

The story went on to say “Microsoft, already the ultimate hardcore company, is entering a new dimension. It’s called Internet time: a pace so frenetic it’s like living dog years—each jammed with the events of seven normal ones.” It also featured thoughts from ever present analysts such as “Until six months ago Gates & Co. appeared lost in cyberspace. It was so far behind…might be sidelined in the new age of Internet computing.” It was all very dramatic and compressed two years into a few pages and some great photos. It was difficult not to feel a sense of accomplishment from my perch, even knowing all I contributed was email and meetings. No matter what all the books and trials might come to say, the company really did a whole bunch of work in a very short time and a lot of it was really good.

Still, it is interesting in hindsight to consider that frequently when facing disruption (still a few years away from existing in business context) incumbents view disruptive forces (products or business models) as additive to what is already being done rather than either orthogonal or full replacements.

On the one hand, we did not abandon any products and start from some notion of “pure internet,” and on the other, most every product that needed to change was a 1.0 product under development or at least early in the classic adoption curve. In fact, the 1.0 internet products such as MSN and Blackbird would come to represent the parts of the strategy that were not at all successful.

Whether or not much of what we ended up doing was too much about adding some internet to things we were already doing was years, maybe decades from revealing itself. Regardless of any product or market realities, the sales force and broader ecosystem around Microsoft fully bought into the dramatic change.

Across the company product, sales, marketing, and more embraced the newness of the internet and WWW. The company went from a small locus of activity to a cross-company buzz of efforts of all kinds. My job as TA was to take Bill’s guidance and evangelize new technology. The internet was an obvious high point for me, though I still believe I received far more from this role than I provided. In that respect, my job was winding down, and it was time for me to go build something.

On to 030. My Performance Review (and An Expense Report)