053. Strategy Tax: Outlook Storage, First Attempt

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

Back to 052. Alleviating Bloatware, First Attempt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On to 054. Steve and Steven Get New Jobs

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