050. The Team's Plan in the Face of Disruption

With the looming threat of disruption, at least according to everyone at the company and the desire to get moving on adding new features to the apps, there was a need to have a strategy in place. Putting together a plan is never easy, and at Microsoft in the late 1990s you’d be challenged to find something that looks like a complete product plan combined with an execution plan. Starting from Basic for the Altair through DOS for the PC and even Windows itself, Microsoft asserted what a product was with little more than a meeting, some slides, or just an announcement or commitment. Execution often fared no better with even our best products, as we have seen, shipping a year or years later than expected. Even the Office apps individually, while having the best executed plans, had not yet combined that execution across the apps into a plan and execution for the suite.

What follows is the story behind my favorite process that we developed and honed over every product release that followed Office9 and ultimately Windows—affectionately called “the vision process”. It is also a real lesson in culture and how even with well-documented artifacts and tools, delivering and executing was really a product of the people.

Back to 049. Go Get This Rock

Leading the plans for Office9 placed me decidedly in the role of the incumbent in the context of “technology disruption,” as was being thrown around the hallways (or thrown at me). We were moving forward with a plan that was either going to work or prove to be one of the biggest cases of disruption ever, not to mention biggest mistakes ever made for an incredibly successful business on a huge upswing. Therein is the most counter-intuitive aspect of this plan—almost no one on the outside would think we needed to do anything to “save” Office, and everyone on the inside had wildly different theories on how we must save Office, all relying on nascent (at best) technologies.

I committed to create a document outlining the plans, a vision, for the whole Office9 product and my self-imposed deadline approached. The High Hopes offsite and memo turned out to be a draft, which was helpful. When I wrote the Priorities and Processes for Office9 that declared there would be a unified plan for the release I didn’t quite know what I had signed up to create. The offsite and accompanying memo were clarifying.

The bet the product team made was on transforming us from a machinery adept at making new productivity features for individuals—IntelliSense, formatting, document creation and editing—to a new execution machine aimed at creating tools for a whole business. The cost of entering that market as a leader was to significantly improve deployment and manageability, or said another way reduce the total cost of ownership. The features we would aim for were not personal productivity features that saved minutes, but business features that saved teams hours and saved IT headaches and dollars.

In other words, the plan for the product—the vision—would completely upend the historic priorities for the product. This was a big change years in the making but faced with a single moment, the distribution of the plan to the complete team, to most the change would happen suddenly. While we were busy easing a group of 50 or so senior managers, the other 1500 people were mostly hearing rumors while they were busy working on their own team’s features. There’s no easy way to make a big change in a big company.

I took what I wrote for High Hopes, removed the defensive tone, and made it much more forward looking, focused on what we planned to deliver to customers, detailing the state of the business, and how we would work. It was an exciting document, if not a bit overly poetic as I’d not yet found a style for these. I wrote it using Word’s Internet Assistant and would eventually post it in HTML to our new http://officeweb running FrontPage sitting on a machine in my office. In 1997, almost nothing was written for an intranet website. The text was in the new sans serif Verdana font, blue with a muted yellow background, as I tried to make it look cool like a web page. It was rather unreadable and mostly unprintable, and with Office 97 copy/paste from the browser really did not work yet. We learned quite a bit from forcing ourselves to use web technologies in this way.

It is important to the process to understand that the past few months were spent in offsites and meetings, and a host of cross-team efforts, arriving at features that would be done by each app and the shared OPU team. High Hopes itself was a summary of what we had iterated on up until that point. This is the heart of what is meant by the Office process of “the best of top-down, bottom-up, middle-out.” The vision is not a news event when individuals see their own work and their features, but a chance to see what the rest of the hundreds of people will be up to. It is also a tool for the all-important process of adds/cuts—when each team (or feature team, the smaller unit of a team within an App team or OPU) figured out what they could really do with the resources they have. Thus the document also served as a check on resource allocation—ensuring the people where the work is needed.

This ongoing iteration within a decision-making framework is sometimes depicted as a funnel in consulting diagrams—lots of ideas come in and a process narrows them down. I think of it as a refinement with increasing levels of specificity. This refinement is also what leads to accountability. By the time the vision document is in the hands of the team, not only is it a reflection of the best efforts of the teams but it is also an execution plan, and it is also the accountabilities for the team. There’s a development schedule, at least the first cut, and a target ship date. The vision document itself is not a refinement but a summary of the refinement that has been happening all along.

That’s the view on paper. In practice, this first attempt would be a bit rough and contentious. The lessons learned would be super valuable the next time we went through this when the team would understand collectively that we were serious about the process. It is fair to say I brute-forced this first vision document through.

I wrote the vision on my own, circulating it for feedback first to OPU program managers and then to senior leaders and forging ahead without really considering the immense implications of what we were up to. Unfortunately, people reading the draft were reading for how it changed or affirmed what they already thought they were doing, not to learn what we were doing together. This was the first attempt at building a shared plan. While we were making progress, the Apps teams hardly surrendered their autonomy. The good news was that I captured most of what everyone was working on and laid the groundwork to unify the expression of why we were doing all that we were doing—that was the goal. The vision was a leading, but also lagging, indicator. The later steps of resource allocation would help to make sure the plan was executed as intended and agreed. This step, resource allocation, is what was almost always omitted in transforming a plan to execution.

The multitude of offsites and planning discussions paid off. Collectively, we were close to being on the same page, at least as close as could be for a team of senior managers who previously were working autonomously with OPU trying its best to be the glue across teams. The rest of the organization was starting to worry, something I heard in hallway grumbling.

Our team administrative assistant CollJ booked the big conference room, Kodiak Room, for March 15, 1999, for an all-hands meeting for the team including satellite/tape for Asia and Ireland where we had large teams. The last time we did this was for developer demo day when each independent app showed off features of Office 97. The night before the presentation I had an idea to make a cheat sheet or one-pager highlights. I quickly excerpted the 12-page vision document, choosing the goldenrod paper stock from the building 17 first floor copy room and made 1000 copies. I was there late in the night and most copies ended up crooked. I had to finish in a second copy room because the machine kept jamming. It makes me smile now to look at the crooked paper that remained on my cork board (adding subsequent cheat sheets each product cycle).

The vision began by stating that Office 4 through Office 97 changed the way people worked, but that was the past. A paradigm shift was underway (Microsoft, especially BillG, loved the word paradigm, in the Thomas Kuhn sense). This shift was toward the internet. Office9 declared itself to be “the best execution of an integrated suite of Internet-centric communication and productivity tools for creating, editing, sharing, synthesizing, and analyzing business information.”

This was my way of pushing back on the idea that the internet, by definition, implied new productivity tools. My point: The internet could make existing tools better and more relevant. The team liked this, or at least reacted positively to it, even if implications were unclear. Office9 declared Office 97 the end of an era of individual productivity and the start of a new one.

Later, I realized it was the beginning of the middle of the PC era, an era defined by expansion into business combined with a shift to enterprise features and sales motions.

An interesting note relative to disruption is that one response incumbents have to new technologies is to attempt to absorb them into an existing product, failing to recognize the substantial changes the new technology might ultimately imply. This was something I did not consider but thought a good deal about a decade later in Windows.

In order to outline the strategy shift, the vision explicitly stated the six priorities:

* Migration, Administration, Deployment, and Management

* HTML Document Creation

* Outlook and Outlook + Application Integration

* Web Collaboration and Solutions

* Web-Based Corporate Reporting

* Personal Productivity

Of note were the first and last. In the vision I used a bulleted list (HTML tag

) and went back and forth myself over whether to number the items (HTML tag
) to further emphasize the priority. As it would turn out, everyone mentally numbered the list anyway and I got the benefit of the full effect. I explicitly rejected the traditional business notion of having one single priority, say the internet. Such an approach only looks good on paper. In reality a single priority leaves most everything to chance as it is necessarily too abstract. Eight or ten priorities seemed too many so this release and others would arrive at five or six.

Migration, Administration, Deployment, and Management declared the most important thing we were doing—making Office a LORG product. Suddenly, the thing that was always last, always assigned to interns, always fixed as blockers in later product updates, was moved to the very first priority. The problem was that by talking about migration, administration, deployment, and management, I made Office9 seem like the dullest product ever. These features were always the last to get completed. The thought of doing this work as a first-class effort became an eye-roller. The vision called this the TAO of Office, or totally adminsterable [sic] Office.

HTML document editing was the second major area. Much of this work was already underway in the form of Internet Assistants for Word and PowerPoint. There were two controversial elements to this. First, Excel had done little by way of HTML and pushing an investment there would ultimately drive a great deal of effort on performance, rendering, and capacity in Internet Explorer (who loved web pages they could display but would crush Netscape). Second, we had not put much effort into ingesting HTML (versus outputting HTML). By developing the ability to open HTML files, as difficult and not particularly useful as that was, we laid the groundwork for using future HTML as a native file format (instead of our crazy binary formats that had caused us so much trouble in Office 97) and importantly for a format to interchange data between applications and the browser using copy/paste. This was the start of a multi-year, multi-product investment that would pay off immensely over a long period of time. The controversy around this choice will be explored in the next section.

In the past, the buyer and user of Office were the same person—the individual productivity user or the power-user/developer we called influential end-users. Apps previously segmented customers by end-users and influential end-users (power users, techies, were other names). Excel segmented bankers. Word segmented lawyers, and so on. Office needed to mature and build a product for segments the way we were selling software. The vision made a case for this level of importance by highlighting different customer segments and the value each would see from Office9.

For the first time, we declared that administrators and CIOs were users, not just buyers—they just wanted entirely different features. We also made a consistent appeal to developers, something we had done unevenly across the product.

The team understood this and making a case with the financials and sales of the company reinforced the new reality for the business. This information also reinforced the dominance of the suite in defining the product.

What turned out to be unacceptable was the last priority, personal productivity. Historically, personal productivity meant features customers liked and made the product easier to use and demonstrate. Anything and everything could be personal productivity since we made personal productivity tools. The personal productivity bucket consumed all development schedule hours and made the product appear as a long list of features to marketing, rather than any theme. That was old-school personal productivity, priority 1 (and beyond).

The plan constrained the definition of personal productivity to features that were unique to each app—features unique to spreadsheets or word processors, not general user experience or ease-of-use features. By allocating development resources to productivity features shared across Office and reducing app resources to focus on each app, the plan was to have a more coherent product to communicate to the market, and one that emphasized the suite nature. Most of the personal productivity features in Word and Excel in the past were similar ideas done differently, inconsistently. Office9 moved that work to OPU and away from Apps teams.

Immediately, program manager leaders across Apps threatened to quit, even raising the issue to BillG. It was not the reaction I expected. They felt disempowered and felt that I had kneecapped the apps. The need to build a suite for LORGs seemed like the obvious plan—to me. Also obvious to me was that Office 97 won. I was experiencing a reality of management: Everyone went along until something changed—they were in favor of change, and even change advocates, until the actual change.

I was disrupting Office not with a new technology but a high-priority focus on a new customer segment and target. Disruption does not always have to be about a new and unproven technology.

It was one thing to declare the need to build a better LORG suite. It was quite another thing to choose to build one at the expense of other features.

Word, Excel, Outlook, Access, and PowerPoint believed that the battle to win in the categories still raged. Outlook had been poorly received (and was now busy on their own interim release that would stretch out much longer than planned). PowerPoint was consistently viewed as the weak link. The general utility of the Access product, and our move to upsell Office Professional, which counted on demand for a database, was still too early to declare a success. Lotus and WordPerfect were rumored to be releasing Windows versions that transitioned their MS-DOS product leadership to Windows. From an app perspective, there were plenty of reasons to worry about losing category reviews, should there be any.

Winning in each of these categories, the PM leaders told me, required freedom to innovate in the base experience. There was no way for Excel to beat Lotus 1-2-3 unless they could build an experience tailored to the unique needs of spreadsheet users.

Repeat for each app.

We were right back to “Excel users are different.”

Independently, Excel was planning a unique user interface re-architecture that was “weblike.” This sounded crazy to me and was the exact opposite of an integrated suite. It was also something that had not been broadly shared or considered across the teams. I could not imagine how we could be a productivity suite if the flagship product, alone, had a new user interface just as we finished launching on the merits of consistency across the suite.

The two weeks from presenting the vision at the all-team meeting we were consumed almost entirely with defending Personal Productivity Is Priority 6, as it became known. My inbox was filled with subject lines like “#6,” “Priority 6,” or “Why such a low priority?”

What seemed easy, took a turn toward the impossible.

To make the most difficult even more difficult, BillG appeared in my inbox. He asked me why Office was going to have a plan that did not advance productivity and was not going to innovate in user interface. It was a direct shot at the plan even though he only knew a small piece of the story. Clearly, he had heard from a leader on the Excel PM team.

Here I was again on the defense, though, logically, I was certain he was going to be okay with it. He knew the importance of the suite and LORGs, intellectually but not emotionally. Bill had not really faced a product team intentionally constraining a release up front. Of course, that is why so many things were late.

Once he read the vision, BillG switched from being concerned about the product to being concerned that all the smart people would leave the team if they weren’t allowed to innovate. I went from preventing productivity features from making it into the product to the manager who smart people did not want to work for. This felt personal and more of a character trait assault than a list of adjustable features.

This wasn’t the first time in my tenure as a manager and later an executive that I would defend the team that was in place over a single person leaving. One of Bill’s most enduring and appreciated traits was the loyalty he felt to those committed to Microsoft. This trait surfaced when someone telegraphed that they might potentially leave. In this case, Bill’s first reaction was to go to the manager assuming something was wrong in the environment that was causing this. Almost always, this was difficult to handle because the information was one-sided (regardless of how BillG found out) and the only thing a manager (me) could do was then talk about all the ways that the team was trying to move forward and how the disaffected person wasn’t on board.

I had been defensive in this case. It was early in my career (I was still leading OFFPM, which had grown to about 65 people). And BillG was concerned about any thought leaders (a great 1990s word) leaving. After some back and forth, however, he was supportive of the bigger picture. Despite all the changes in the vision and the demotion of personal productivity, the team was overwhelmingly in place as we planned and only one PM leader of about 15 bailed, and that had worked out best for everyone.

The rollout of the vision kept moving.

By spring of 1997 we still had two or more years of tight collaboration ahead of us, much tighter than with Office 97. We could not afford a misstep. We rephrased a section in the vision, tenets, that defined the cultural priorities for the release. We made them explicit in the vision document so we could refer to them later in the project:

All members of the Office9 team, regardless of the reporting structure, are responsible for the innovations in the Office9 product. By corollary, the shared feature teams are responsible for the integration of their work in each application.

Development and process efficiency is critical to the success of the Office9 schedule, and therefore it is better to do things the same way once rather than doing things in multiple places. This refers both to features and process. In other words, it is better to be the same rather than different.

We took this as a chance to create a new employee orientation for the Desktop Apps division. By instituting a small amount of informal training during new employee onboarding, we were able to show employees the vision document and detail the organization and priorities. Almost immediately, the vision document took on an even broader role than originally intended.

The vision even included specific tenets when it came to the product, schedule, and how we would manage the team. The goal was to have a set of non-negotiables across the App teams and OPU to effectively centralize what mattered. Even something simple like which non-English languages we would focus on (German and Japanese) was previously a big headache that we just decided up front. Similarly, we committed to the platform requirements for the release which included working on the new 3-year-old Windows 95 and also that we would make sure our HTML worked on Netscape Navigator, which was almost heretical (more on that in the next chapter).

Rolling out the vision for the first time to the entire team was stressful. There was the ever-present fear of leaks, leaving someone out by accident, typos, and oversights. Most importantly, the people who didn’t agree wouldn’t tell the sender (me) but would create a negative vibe across the group. We saw some of this in the original 12/24 plan. People who didn’t agree stayed on the lookout for what wasn’t working and were right there to call this out. For Office9, we knew those who wished to prioritize apps would do the same. All of these were signs of an organization still finding its way from storming to norming.

Given how late Office 97 was, a significant concern was any doubt about the overall schedule. Those manifested as schedule chicken between apps, with each app betting they would just finish ahead of another, rather than working to be first.

The key to a robust schedule was buy-in from the test and dev managers. GrantG already harmonized the schedule across the test discipline, when he wasn’t personally testing the latest build or filing bugs. While there were differences in style, they really snapped to the same page under his leadership.

DuaneC rallied the dev managers behind the schedule. Duane’s style, much like JonDe’s, was quiet, understated, factual, and exceedingly straightforward. While directly managing nearly 100 engineers and having responsibility over the full team of over 350 engineers, he still managed to own code, fix bugs, and add features.

It all worked. Following the team meeting, the dev schedule was in motion. Code was being written. We officially started coding in May of 1997 (about 8 weeks after the vision meeting), with a beta scheduled for a year later after three milestones. We planned an RTM of July 1, 1998. There was a big risk to a summer RTM—another DAD rule of thumb along with not releasing on a Friday or before a holiday was avoiding an August RTM. If we missed it, there was a cascade (summer and global holidays that broke up the work calendar, followed by end-of-year) that almost automatically pushed us into the following year.

We were off.

One final note, the group program manager for PowerPoint, BrendanB, was so amused with the vision process and especially the cheat sheet that he went one step further and made a version I could hang from the rear-view mirror of my car along the lines of Repo Man (“there’s one in every car”). This became his tradition and I have a whole collection of these that I maintained on my cork board.

On to 051. HTML: Opportunity, Disruption, or Wedge



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