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 Peter (ChrisP) to lead the team as the divisions 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, 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 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.

At the same time reducing the size of the Apps teams by an equivalent amount, all while every team continued to hire as many graduating engineers as we could, so we would have plenty of people to do the work. In software development, the number of engineers is literally everything (perhaps, except for schedule time). The WOBU (Word, 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.

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 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) and picking a schedule, and what to focus the new OPU on 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, 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 team 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 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 “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 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 application 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 change 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.1 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 two years [sic] 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