Wrapping up the development of Office 2003 was an enormously challenging time for me personally, while the team continued to do well finishing a release with an unprecedented breadth and depth. At the executive level the company was under enormous strain, not because of a lack of business results (quite the opposite), but from what the NY Times called a "popularity problem". The core business was less dependent on Windows than ever before and in fact the percentage of Microsoft revenue or profits from Windows likely peaked. In addition, the Server business and Office were doing extremely well. Few companies have more than a single tier 1 business, let alone nearly a dozen billion-dollar products. Wall Street, however, was no more happy with Microsoft than it was with most every other company. In 2010, the "lost decade" was used to describe the lack of broad stock market returns over the past decade (2000-2010). Some began to apply that to Microsoft specifically with the rise of Google, then Facebook, and Apple’s resurgence in consumer devices. This post details the start of that period and I will leave it to readers to judge if this was truly such a start, or if indeed, we simply had a popularity problem, or something altogether different.

Back to 074. Outlook Pride, Finally

Over the course of building Office 2003, Microsoft began to see cultural transformations that in hindsight were the product of trying to mature as an organization while not taking on the risk of changing as an organization. It was as though we wanted to add all the benefits of a coordinated, multi-dimensional-thinking, well-executing, mature company while at the same time not taking away the hardcore, code-centric, engineering-driven culture that got us to where we were. The goal was laudable. How could it not be? The only surprise was how long it took us to get to this point.

Around the company we were not executing well, not even a little bit. To some, however, it felt like we were executing. That was only because we had so many activities going on. Everyone was very busy (just try scheduling a meeting with someone) with launches, pre-releases, community gatherings, partner events, PR outreach, ecosystems, big reorgs, offsites, slide decks, spreadsheets, reporting systems, and more. The airmiles were accumulating at a phenomenal rate. A big company has an ability to show a great deal of activity even with little progress. What wasn’t happening was new product innovation, except financially. That distinction is important. The money was coming in but that was for all the products we had already built, in some cases several years earlier.

Microsoft saw less than stellar success across most of our new initiatives. If the primary goal was to gain market share, then we were losing  (“share is air” SteveB often said). Whether it was phones, consoles, web sites, advertising, and so on, the first few years of the millennium looked like the dot com startups we had ridiculed. To clarify our new initiatives, Microsoft began to report earnings across seven operating segments: Client (Windows), Server and Tools (Windows Server, SQL Server, Exchange, Visual Studio), Information Worker (Office), Microsoft Business Solutions (Great Plains/Dynamics), MSN (all the “consumer online” properties), Mobile and Embedded Devices (Windows Mobile), and Home and Entertainment (Xbox, consumer hardware). Every earnings call and cover story about Microsoft asked when these new businesses would become “profitable”. The calls for “when will you win” were deafening.

Such a question was a naïve approach to how business worked, but that’s how bringing visibility to a product under development is talked about (anyone who has run a business knows that new products are not profitable at the outset and take years for a full P&L view to look profitable, but that’s not how people comment on earnings). At company meetings or routine team meetings, SteveB had a great series of slides where he emphasized the long-term nature of Microsoft’s approach and what it means to invest in the future—“investing” Steve would always emphasize. As a reminder, Windows took at least six years and three major versions for Windows to become a significant product. Had Windows been reported separately from MS-DOS it is not clear Wall Street would have been forgiving.

The new businesses were still much newer and were part of a vastly larger landscape than Windows or Office were years earlier. Combined, the four investment-mode new businesses (MSN, Mobile and Embedded, Home and Entertainment, Business Solutions) had a (FY 2003) negative operating income of $1.6 billion. Windows, Server and Tools, and Information Worker had an operating income of $17.9 billion, on total revenue of $32.2 billion. In other words, there was no material risk to the company due to these investments, nevertheless losing money or failing to pay off began to permeate the whole of the company’s operating model. Culturally, we weren’t used to negative numbers.

There was an additional problem that drove operational changes. The Windows team began to have the signs of a product spinning out of control (my words). The company was experiencing in real-time what SteveB and I discussed in his first series of one-on-one meetings when he became president a couple of years earlier. Big projects can seem to go from execution to out of control in a flash—there is a fragility in large-scale software projects that we had yet to fully grok. The time it took to complete Windows XP SP2, the resulting desire to produce separate releases for Tablet PC, Media Center, and Windows Server, and expanding strategic inputs from BillG shaping Windows development created a situation where the Windows XP follow-on release, Longhorn, was either “at risk” or “out of control” depending on who you asked. In practice, some still believed it was a typical Windows product cycle.

Beyond the new businesses described by segments, Microsoft had a seemingly infinite breadth of new products under development. Few areas of software went unnoticed without a Microsoft group claiming to be in the space. Yet, we lacked clear strategic view or even line of sight view to all these projects, if or how they fit in, when they might deliver, or what progress they were making. A skeptic would say this was an additional level of potential negative ROI hidden underneath the success (or not) of each segment. Optimists would say this was entrepreneurial thinking at its best. The challenge was that as primarily an enterprise company, the customer demand for a strategy, unification, and clarity were ever-present.

Seeing these challenges drove a shift in how the company operated, at least I believed such was a root cause. A pendulum swung away from autonomy and lack of rigorous strategic and execution oversight at the top-level towards a more centralized approach to planning and execution. In any business environment I’ve seen, when things aren’t working the inevitable solution is to swing the other direction of some easily identified pendulum. In our case, that meant more corporate, standardized processes.

I found such a change challenging (for me in Office) in two ways. First, it felt to me that Office didn’t have these problems. We were executing well and had been for a long time. We had processes and delivered results—even when our projects were late, they were not unbounded, and we promised and delivered on plans without any gaming or redefining of deliverables. Second, the problems seen in these new businesses could look like execution problems, but as we’ll see over the chapters that follow, they were fundamentally strategy and manager (versus management) issues. It wasn’t enough to work to get the trains to run on time if there was no understanding of where the trains should run. Some of the projects were running well, but the destination was poorly understood.

That was my perspective. It was not shared by everyone for two reasons.

First, just as with any business if one wants to make a bear case then that would be possible for Office. What if customers rejected a new version? What if open source, OpenOffice, took share? What if web-browser Office became a thing suddenly? What if we were out of control and just didn’t know it? We just weren’t going to be blindsided by those in 2003, but there was no way to prove that. Any attempt just sounded defensive. I sounded defensive far too often and that was not good.

Second, the company model for all the new businesses was to be a platform. What do platforms need? They need Office to build on the platform to prove it out. Any lack of success in the new businesses was therefore strongly connected to something the Office team was not participating in. As such, their problems were indeed Office problems. They were my problems. I didn’t really believe they were my problems, and my rolling eyes or audible sighs were the tell.

I was busy finishing Office11. That’s what I knew needed to happen, deep down. Putting up with all that was going on around me was, I thought, adding a second job. The Office team had gotten so good at planning and execution that there were plenty of cycles remaining for me to focus on those goings-on, even if I did not find doing so pleasant.

Was this the moment when dreaded bureaucracy was settling in? If only Microsoft would have realized as much, might we have avoided a “lost decade” that followed? The expression “lost decade” became a popular way to describe overall stock market returns in 2010 since the dot com bust. The press started to refer to Microsoft’s own lost decade. In contrast to the broader market Microsoft had a “popularity problem” to quote the New York Times, which said “the company hasn’t received credit for its almost-half-full glass: the 40 percent of its business that is not Windows or Office. . . its enterprise software business, formally labeled Server and Tools, as ‘an incredible business’ accounting.  .  .for about 24 percent of the company’s revenue and with an operating margin of 40 percent.”1 We had the numbers but unlike Apple and Google we did not have a consumer business. That was by design. We were not putting in place an arbitrary bureaucracy or processes, but the logic behind the changes was to try to have it all: an enterprise business, a consumer business, competitive products, and an overall technology strategy. We were not lost as much as trying to do a lot. Maybe too much. We were Microsoft and we thought big. What’s wrong with that?

Dealing with these processes was challenging for me and it showed. Some aspects were always going to be my style. I did not have a staff (a business manager for example) who could spend full time in the preparation meetings for the larger meetings. I made slides I was responsible for by myself and got them done on time, but without endless iterations and sweating over every point that can come with a staff working full time on slides. In doing so I wasn’t always part of the month of pre-meetings leading up to meetings and did not always have the context for when something new became a hot topic amongst the staff (what is the Office answer for “healthcare” that came up in an earlier meeting or what are we doing about “small business” that was in that mail thread from UK). It was obvious to me that the processes were an effort to bring the rigor of the Mid-Year Review (MYR) process used by the subsidiaries and field to product development. It was never clear to me, however, that sort of process would work for the creative and uncertain aspects of product development. I was frustrated that no one ever asked for input over what we were being asked to do.

I believed that tired cliché about building products, which is you can’t know everything before you start but you can cause everything to grind to a halt by asking questions at every step or thinking success can be known before we start. I held that romantic view that building products is an art, and no quantity of meetings could turn it into a science. Perhaps the most frustrating (to others) belief I held, was that questioning too much after a product starts is a sure-fire way to bring chaos. That’s what I saw happening.

I agreed with the problems that preceded these process changes. I didn’t see processes as the solution. We were not going to fix things by having better slides or box diagrams. We weren’t executing because we lacked the planning infrastructure and organizational structure that was required to deliver. Such a point of view, however, was difficult to prove because the very nature of the processes we were going through (with names such as Business Plan Review or BPR) was to surface the planning and org structure issues so they could be fixed. We were caught in very tricky loops.

“Competing with Linux” was a long series of meetings that was top of mind for the Server and Tools business and also illustrates this point. I was running Linux at home. It was comfortable for me as it brought back muscle memory from college and graduate school (that was technically Unix, just to be completely accurate), but importantly it brought back a lot of technical reminders about the architecture of Linux. Office also experienced the rise of Linux through FrontPage, which achieved far more success connecting to Linux servers on the internet than anywhere (or anyone) else. This would serve me well in the product-led discussions, as would the feedback from internet service providers all running FrontPage on Unix and not Windows NT.

Strategy and execution meetings about Linux were overly focused on the immediate crises of head-to-head sales losses. What should be our pricing? Are we positioning correctly? Do we need a better partner? Many in product groups (the development teams) were familiar with the technology, many deeply so, but the product plans did not reflect Linux as a competitor when viewed through the lens of resource allocation and feature lists. It was as though there was broad acknowledgement of the competitive issues without responding with product plans. The basic idea was that we could win if we didn’t change any of the product plans, where the list of must-do features for enterprise customers continued to grow. The real problem was that the business results made this look like the right decision. The sales of Windows Server continued to rise, and Linux was still free as in free like a puppy. We were winning at least in appearance.

From any objective distance, it became difficult to see the difference between how Windows and Office responded to Linux or competitive risks in general. If I suggested Linux was a real product competitor requiring a significant change in product features over what we would do if Linux wasn’t on our radar, then I could just as easily be challenged over responding to OpenOffice. . .”you lost that sale to the German government didn’t you?” they would knowingly ask. A response claiming it was different just made me look like I too was dodging the issues around Office or something akin to whataboutism. As such, there was a need to see the Office response as well.

One Linux review meeting reached a surreal phase when the whole of the all-day meeting with hundreds of slides and many presenters boiled down to a request for headcount in order to effectively compete with Linux. As a matter of practice, that was not how meetings were supposed to go. Headcount requests were for another meeting and process. As though it was to emphasize the matter, the actual headcount ask was for two, yes just 2, heads. The entirety of the strategy to compete with Linux from a 10,000-person division required asking for two heads. It was as crazy as it sounds. To his credit, SteveB was not happy with the ask and the team was not happy with the response.

I hesitate to write the above because my experiences at this time could not possibly reflect experiences of the thousands of people during this same transition. It is not even clear to me today what were causes versus correlations of the challenges we faced. Frankly, some of what seemed so wrong then turned out to not matter at all to where Microsoft is today. Such are complex stories. Such is product-market fit, which is likely the most important lesson. We had the most amazing product-market fit, which (at least according to theory) meant it hardly mattered at all what we did.

Through these new processes I reluctantly learned to be pretty good at telling the Office story with respect to execution. I became well-versed in explaining how we worked, organized, planned, collaborated, and executed. I spent an enormous amount of energy detailing these topics to anyone that would listen. Even very small details such as knowing how many people worked on a given project, something we routinely did for years, would take on almost legendary status as SteveB would ask other groups for a report that looks like the one from Office. They would often ask to connect with the staff that created a chart only to find it was usually just me. There were no secrets. We just did the work, but it did have a cost.

There was some personal history to my desire to do a good job explaining resource allocation within the context of this new business planning framework. Back when we organized for Office9 (Office 2000) one of the significant decisions we made was to allocate resources even more towards Office suite-wide development and also what would become SharePoint. In doing so, the number of developers on Excel, for example, reduced from an historic high of 50-55 to just under 20. There was controversy and disagreement within the Office team, but that was no match for how BillG viewed such a decision as nearly irresponsible. Yet in a short time it became clear that reallocation for products that had won was a much better approach than to continue to incrementally pile on resources. In real-time, both BillG and SteveB got to see the culture difference between Windows and Office when it came to embarking on new projects. Everything in Windows always seemed to be incrementally new headcount (like Linux compete) and everything in Office was a reallocation. I didn't realize it at the time but using today's terminology I relied on the product-market fit achieved by Word and Excel. We just weren't going to lose in the overall Office business because of incremental features we failed to add to those products.

Counting developers became an obsession with me. Starting in Office 2000 I even did a census where I asked each developer to add a row to a spreadsheet saying what they worked on in their own words so I could compare it to the schedule, the vision, and what team they were on. After that we even started using unused columns in the SAP employee database to record what part of the project a developer worked on—that way the information was always available live and could be kept up to date as employees moved around the team. Any time someone asked me how many people were working on some aspect, I just brought up http://headtrax (the internal front end to SAP data) did a few queries and there was an answer. For data across the whole team I’d just export to Excel and create a pivot table.

Such attention to resource allocation was seemingly encoded in my Apps Division DNA. It came from a reality that it didn’t matter what a team said they were working on, rather it only mattered what developers were actually assigned to. As the company grew and cookie-licking became more common—when teams declare they own or are driving a critical initiative but are doing so without the work or resources to support it—the need to bring clarity to those discussions became even more important. I only wished at the time that more teams had clarity of resource allocation reflected in SAP.

Managing personal time was just as important as clarity on developer allocation. Following a lesson I learned from SteveB for the past few years I tracked where I spent time during the day. How many 1:1s, product meetings, customer and partner meetings, skip-level 1:1s, team meetings, and so on. I did this in a very lightweight manner attaching a category to Outlook schedule items. Every quarter I exported my calendar and created an Excel pivot table of hours spent on these categories.  Over the course of developing Office11 I noticed that I was spending more time in what I labeled “process”, the corporate driven planning and coordinating meetings and that was taking away from ad hoc time just talking with people in the hallways or more structured time with the team. I found this disappointing, if not depressing. When I discussed this with my manager or Steve (in a skip-level with him), usually the feedback I received was that I was not spending enough time on corporate. Somewhere between too much and not enough was probably a better answer. I had reached that point where I felt caught in the middle and failing both of my constituencies. My algorithm for addressing this concern was that the team always won out, whenever it could. I just felt so much more useful in working with the team than in corporate. . .rituals. It was easy to feel good because we were making a ton of progress, especially comparatively.

The team was doing a fantastic job finishing Office11, which was formally named Office 2003. Well, not exactly. With new marketing leadership in place and a mission to be more aggressive along with license to spend more doing so, the product branding was brought more into an enterprise perspective.  Office suites sounded so small. We had so much more software. The entire collection of Information Worker software was branded “more than what it used to be” as “Microsoft Office System”, “now an integrated system of programs, servers, services, and solutions”. The suites of Office programs typically bought were called Editions. This meant Office11 was officially known as “Microsoft Office Professional Edition 2003” or as regular people called it, Office 2003.

JeffR approved a major advertising campaign to go with Office 2003, over $150 million, five times the $30 million spent on Office XP. It was one of those campaigns where even the campaign itself gets a PR push and stories about it—marketing of the marketing team. The campaign covered print, online, television, and more (such as airplane video). Called “Great Moments At Work”, the campaign was a playful take at workplace successes as though success was celebrated like sports complete with pile ups and high-fives. The ads were fun. The print ads used photos of the same scenes but emphasized the sheer breadth of Office System software.

Office 2003 Product Guide

5.67MB ∙ PDF File

Read now

Read now

Breadth was an understatement. The sheer volume, or mass, of software being released as one product at one time was overwhelming for customers and the press. It wasn’t just that it was overwhelming in quantity, but the features individually were so deep, so complex, that few could really understand them well-enough to provide detailed reviews. The product guide we distributed to reviewers and the press was 170 pages, a book! The Microsoft Office System Evaluation 2003 Enterprise Edition kit consisted of 11 CDROM discs and two discs filled with various technical and overview documents, demonstration videos, and an entire disc-based website of Macromedia Flash content. It seems easy to make fun of this today, but then one look at the web site for Office 365 and I guess one could long for the finiteness of a bundle of CDROM discs.

Outlook was the hero of the release, with a little bit of OneNote from the press as expected. From junk mail to the new user interface and especially more reliable mail delivery, Outlook finally achieved status as a first tier Office application. It was a story that started in the mid-1990s and took Outlook 97, Outlook 98, Outlook 2000, and Outlook 2002 before we finally got it right in 2003. Through all the strategic twists and turns, organizational changes, and internal competition it had been quite a journey. With 2003, the product finally made it.

A huge amount of software, and Outlook. That is how I remember the release. We so over-achieved on building enterprise software that even marketing, which by and large picked out the end-user features to promote in previous releases, went all in on enterprise to market the release. In the above Evaluation Kit for example in the included “Top 10 Reasons to Upgrade” four of those top reasons had to do with XML, magical XML.

To that end, the release came across as one deeply committed to the new XML technology, our fifth of five priorities when we planned the release. The problem was that we used XML as an implementation detail, not as an end to itself—we had built a platform not a solution, and it was too soon to tout the uses of the platform that had yet to see adoption. The company was overall was so committed, so enamored with XML technology, that it took on a life of its own. It became the destination. The Office marketing team was drafting off the incredible amount of XML evangelism being done by the Server and Tools group, where XML was a key underpinning of the .NET platform. It was still a text file, but we were going to make it seem magical.

If previously Office 2000 focused too much on cost of ownership and deployment to the exclusion of end-user features, then Office 2003 focused too much on a technology enabler or platform technology to the exclusion of doing more with the technology that enterprise customers could use immediately. Looking back at the vision, clearly the big change at the start of the project removed the bulk of the end-user appeal—the vision of Office.NET as an end-user service. The corporate version, “Team and Corporate Productivity” in the vision from May 2001, delivered well but suffered from the complexity and slow deployment of SharePoint as previously discussed.

Large projects are indeed a portfolio and with something as large as the Office System it is essential to build a product such that each constituency has something significant to grab on to, almost selfishly. This is an intentional part of the planning process—we look at the features we are building through the lens of critical stakeholders and make sure everyone has something. I measured our success on delivering on value by constituency.

Enterprises, medium businesses, IT professionals, channel partners, developers, integrators, and more had the full weight of the Office System. It was what they wanted. End-users, typical reviewers, and the individual “power users” (Influential End-Users in our taxonomy) were left behind, though with Outlook and OneNote there was enough, just not an overwhelming amount. The reviews showed that.

Rob Pegoraro a seasoned reviewer for the Washington Post wrote, even with some stinging criticism of some specifics in Outlook, “If e-mail rules your world, Outlook 2003 offers tough competition for pretty much every other program around. . . But the rest of Office 2003 is a yawner. Most people at home can comfortably sleep right through this upgrade cycle.”2 That’s what most of the reviews were like. Individual reviewers representing typical Office users struggled to make sense of XML, SharePoint, collaboration, and the rest of the massive Office System. The thing is, those individuals just weren’t our business anymore. Enterprise was our business. Those reviews were incredibly strong.

While we were nine months late, we were never out of control or unclear on where we were in the project. We just had a ton of software to get built. Nine months might seem too long, but with the original schedule finishing in late September that really meant a late January launch anyway because launching over holidays isn’t something you can do with enterprise software. So really it was just 6 months, a cup of coffee. The unanticipated long tail at the end of the release gave us more time to plan. My thoughts were wandering to bringing real excitement back to the product while solving the problem of the heft of the Office System.

The launch was a huge worldwide event. I chose to go to China for their launch (shortly after the launch, I would use a sabbatical to live and work in China for the subsidiary full-time, on the heels of SARS no less). It was an amazing time in China as the markets were opening up, welcoming us, and anxious to expand business connections. The climate of optimism was incredibly unique.

The launch was difficult, however. For all we had done to execute well, the last-minute change in the product plans away from a consumer service made the release difficult for me. Most people didn’t obsess over the change, but it lingered for me. Perhaps because I took it as a personal failure in how I managed the planning effort or perhaps, and more likely, that I felt it would have been incredibly cool to deliver on the vision of an “online Office”.

I began to think about what would come next for Office and was clear that the product needed an end-user focus. The enterprise momentum had run its course. We were not going to lose for not being enterprise enough. We needed to regain the end-user. I thought to myself about the commitment to do that after Office 2000 and the moderate success we had in development but that did not translate into the way we sold the product. Office 2003 was to remedy that but the start of the project solidified the all enterprise approach. We faced real competition now and the reviews showed we had real problems for the humans that used Office, not just the organizations.

More than anything, the launch was bittersweet not just for me but for many on the team. Just as the product was going to beta test (summer 2002) the team received some devastating news.

Reader note: The following contains an emotional description of the loss of a Microsoft employee.

On Thursday August 22, 2002 (almost exactly one year before we released the product to manufacturing), I received a call on my landline at home from Steve Shaffer (SteveSh), the HR generalist for Office. A call from HR to my home never happened so I knew something was up before I was able to discern the shakiness in his voice.

“I have some terrible news,” he said. “It is Heikki. He’s gone.”

I was not able to process what he was saying and was silent for what I am sure seemed like an eternity. I managed to ask what happened. Details were thin, but there was a fatal car accident in Monroe, Washington, about 20 miles north of the Microsoft campus in a relatively rural area. While trying to pass a car, Heikki’s car collided head-on with a large vehicle. The roads were clear and dry and there were no visibility problems. It took a few weeks, but we learned that there were no drugs or alcohol involved. A young mother of two was also killed in the crash. The children and their father and grandmother survived.

The sudden death of a coworker, a direct report, long-time colleague, and friend was both a personal event and a team event, and a Microsoft event. Heikki was a towering and immense presence on the team, and many people were deeply affected. Microsoft was still a young company and, while we experienced some tragedies, this was the most sudden loss of a senior leader.

Heikki’s family lived in Finland and made their way to the United States as quickly as they could.

We were all in shock. Yet we got through, in part, by thinking about how Heikki would have guided the team. Heikki in his most Finnish stoicism would have insisted we pick ourselves up and stick to the mission at hand. That was Heikki, Olympic-caliber athlete, submariner, sailor, and friend.

We were not ready for the loss. There was little about a technology workplace that prepared anyone for tragedy.

The memorial service was held at the Finnish Lutheran Church in Seattle. With Seattle’s strong ties to the Nordic region, it was fortunate that he had found this community. There was an enlarged photo on display of Heikki enjoying his beloved boat. The church was filled beyond capacity, and we arranged a satellite broadcast for campus and a memorial gathering after the service. Speaking at church, out of admiration for his work family, I shared an expression that meant so much to him and one we often spoke of as a description of the kind of leader he was. “The sign of a great leader is that when the goals are achieved, everyone says things just happened naturally.”

Heikki always said that he took on the mission and “did what needed to get done.”

Back at work, everyone slowly began to move forward. Asking ourselves “What Would Heikki Do?” helped keep status mail going out and project communication across the team.

But there was a void to be filled. Heikki held the most critical communication and coordination role on the entire Office team, and we were at the most critical point for the project to come together. Big teams have succession plans, but they almost always assume some period of adjustment.

No one was expecting to do anything other than finish Office11 on plan. Antoine Leblond (Antoine) agreed to take on program management. In the same announcement, Don Gagne (DonGa), from Outlook and NetDocs, moved to lead Office development. It was what needed to be done and we were so fortunate to have a leadership that could adjust. The team continued the work while mourning the loss of a friend. It was most certainly what Heikki would have wanted.

The RTM milestone, a muted one for many, almost exactly a year later was a reminder of Heikki and all he had contributed in his time with us that was cut so short. Everyone thought of Heikki often, but especially on that RTM day knowing how proud he was of the team every time we shipped.

In remembering Heikki’s spirit as I write this personal journey, I chose to add a page remembering Microsofties that I personally worked with on Tools, with BillG, Office, and Windows who contributed so much and whose memories are indeed blessings.

On to 076. Up Against Bloat and Commoditization