047. Don’t Ship the Org Chart

The Microsoft sales force had a ritual of reorganizing every fiscal year, like clockwork. The Platforms teams always seemed to be in some state of organization change, at least to me. Office, on the other hand, had been relatively stable except for two deliberate changes. As successful as Office 97 would prove to be, the product still reflected the development organization more than the value proposition. We needed to change that. To change that required us to develop a more robust planning process that was relevant to everyone that mattered.

Back to 046. Prioritizing a New Type of Customer [Chapter VIII]

With the start of our company-wide transition to becoming enterprise-focused, the product group organization seemed to be in a state of flux as we began a new release to follow Office 97. Churn across the senior leadership was a defining element of middle age for Microsoft.

Over the next decade or more, at least for me, it seemed as though we were always fluid at the top. We were either restructuring or leaders were being moved around, and sometimes both at once.

By the time Bob Muglia (BobMu) was my manager, starting in March 1999 and right around the release of follow-on to Office 97, Microsoft had gone through three major restructurings over the course of seven years—changing first to five main operating units then to seven and then back to three. Just keeping track of division acronyms was impossible, and as fast as we could distribute T-shirts and logo items, the acronyms expired. It wasn’t uncommon to enter an office with moving boxes that remained packed in anticipation of the next move.

Desktop Applications had four different executive leadership structures during planning and delivering a single release of Office over 30 months. From the end of Office 97 until we shipped the next product, the larger division containing Office would change names numerous times: ACG (Applications and Content Group), AICG (Applications and Internet Client Group), ATG (Applications and Tools Group), BPG (Business Productivity Group). The groups were each defined as Office and other stuff, often not particularly adjacent in the market. Each one of those changes came with some feeling that even after the successful launch of Office 97, some things needed to be done differently. But what?

While never explicit, the executive changes all had one thing in common. Each was a gradual move towards Apps being managed by executives from Platforms. There was a subtle reminder that the company was a Windows company, and importantly that when it came to the senior executives, it was the Apps teams that needed leadership from Platforms, not the other way around. It always felt like we were getting a message that we needed help in some way.

A level below these new executives, Applications had been stable for quite some time. As described previously, from the earliest days until Mike Maples’ business unit re-organization in the late 1980s, the teams were organized by job function. The business unit function served well through the rise of the Macintosh business leading to Office and the creation of the apps for Windows, until the creation of OPU in 1994, the Office Product Unit. This relative organization stability coincided with a growing execution capability on the team. While products were late, they were (with few exceptions) never out of control. Individuals became strongly committed to the individual apps teams and finishing what you started became a key element of the strengthening culture of Apps.

By way of comparison, Windows ran with parallel teams through much of a release, with one team focused on shipping the current product and another team focused on the next release. Culturally, there were starters and finishers. The starters were the big thinkers in terms of ideas and architecture, and the finishers were the closers who drove a project to completion and managed the complexities of closing down ecosystem contributions.

That meant that at any given juncture there were always two buckets, with code names: Chicago/Cairo, Nashville/Memphis, and Whistler/Blackcomb, for example. When a product finished, there was a changeover in leadership. The finishers came in and the starters moved on. It was their culture. The presence of a future team seemed to me to almost distract executives providing a team to meet with and a place for all the new ideas to go, while the shipping team worked heads down. The handoffs were never that clean and with some frequency the future product failed to make it to market or would change substantially with the shipping leadership.

Office, on the other hand, was predominantly single-threaded—focused on one release at a time. Office believed firmly in a culture of engineers finishing what they started, program managers owning features from start to finish, and testers being involved from the start of a feature. Most of our performance evaluations and promotions were based on understanding complete product cycle contributions. The idea that features that did not fit in one release rolled into the next release did not work for us, simply because we started each release from a clean slate and awaited feedback or learning from the market. It was almost never a good idea to begin a release with what was not finished previously—a lesson that is even more applicable in today’s continuous delivery model. Planning for the next release began informally around beta and then ramped up—a process that I worked a great deal on developing and honing. Our view was that shipping was learning and that assuming what was not complete needed to be finished was not the right place to start.

The Office team’s single-threaded product development proved frustrating to BillG and Platforms over the years, and given the change going on with the internet, browsers, and even org changes, the pressure to be talking about the future was greater than ever. LORG customers also demanded more information about the future, a constant source of tension for Office that lacked a second team building the next release. Because software was always in a constant state of deployment, LORGs wanted assurances that what was being deployed today would remain relevant in the future. Thus, with LORGs came an ever-increasing demand for long term product roadmaps. Accountability to those roadmaps was another issue entirely.

As much as a LORG customer might wish to standardize on a single version of Office and Windows for their standard PC, the realities of release schedules, product updates, evolving PC hardware, and their own desire for new features made that impossible. Like painting the Golden Gate Bridge, the deployment of Office and Windows was always a work in progress.

The execs felt that without a second team available for ongoing conversations, they had no ability to give input. My own experience, especially in watching this from my role as Bill’s TA and in seeing the hand-off between several versions of Windows, was that much information gathered from those meetings was lost in the transition between starters and finishers. The hand-off was a loss of team momentum as well. I was never convinced that it was possible to execute parallel releases. Our experience on Office 95 and Office 97 only cemented how difficult and consuming that could be, and we were extremely constrained and disciplined.

In order to gain more visibility for what appeared to BillG and others to be a secret Office planning process we began planning with more people from other parts of the company—company-wide thought leaders. I documented the offsites with memos and notes and distributed them. This, in turn, created more demand for participation and sharing, which concerned me because we had a strong desire to keep release plans confidential. The business relied on exciting launches and reveals to drive upgrades. We had not yet reconciled the demand for product roadmaps from customers but were already familiar with the ability for any forward-looking materials (especially) slides to find their way to the field, customers, and even the press.

These offsites were an integral part of building a shared view of a product’s future. As much as offsites were loathed, I witnessed their effectiveness (and not) when working for BillG. As such, I put them to use in Office. The offsites were a weird match between people who knew all the details and people who knew none of the details, but everyone had strong opinions often stated as facts when in reality we had very little data about the world as it existed and none about where things were heading. These offsites were useful in bringing a common dialog forward and at the very least when criticism was offered, we knew from where it came.

By this time JonDe was the VP in charge of the whole Office product, OPU and the app teams. He reported to several different executives in a short time. During the transition to the next product release, JonDe and I were determined to embrace a new mantra, “Don’t ship the org chart.”

Collectively we saw too many examples of this in Office 97 and across the company, where the organization mirrored the code architecture and that constrained what could be built, thus determining what would be built, regardless of broader goals. Developers naturally want to own code. Managers of developers want to know which code they own and control the flow of data to and from their code and what other parts of the system can use this code. Over time, for us, this created a code boundary that was enforced by the organization. Products ossify and it becomes difficult to branch into new areas. These boundaries define resource allocation requirements—if a team took a certain number of people to code one release, then it needed to have the same number, or more, next time.

Creating software is always a process of layers, each more abstract than the next. In an ideal world, there are clean layers of abstraction communicating only with layers above and below through pre-determined programmer interfaces. In the real world, not only is it exceedingly difficult to create these nice layers, but it is also nearly impossible to maintain them as the needs of the product evolve over time. In fact, innovation mostly happens when a new product comes along and has a different view of these layers, creating an innovative (better performing, more secure, easier to use) product by busting through layers.

Examples such as integrating charts in Excel, background spelling in Word, or the whole of the graphics features in Office 97 broke through existing or traditional code boundaries. Failing to recognize the power of breaking existing abstractions and, more importantly, not letting the organization determine how code is built is key to innovation. Having fluidity in layers and in ownership of code over time creates innovation and enables flexibility in the organization to take on new problems and bring new perspectives to how features should be implemented.

Planning the release after Office 97 was a chance to step back and create a new process for a new Office product, and a new organization.

We started with the defining characteristic of an Office product planning process—the best combination of top-down, bottom-up, and middle-out planning. This was straight out of the Cape Cod experience (credit where credit is due). It contrasted sharply with the prevailing approaches to product planning that were used across the company and most industries. Historically, the plans for products were driven by the “smart person” or staff who owned pulling together a slide deck. They presented this for review to executives. Over time, the decks became increasingly denser, but the overall integrity of a schedule, engineering plan, or iteration about the plan was all left for after planning. Much of this approach explained the difficulty of finishing a product on time. This worked well when the product plan was a known programming language or a known specification like a video driver. We had far too much iteration in what we were doing, not just how we were doing it, for such a centralized handoff or waterfall approach.

Each App team maintained a sense of rhythm of planning and there were many inconsistencies. In leading Office Program Management, I needed to find a way to bring synergy and consistency across the teams as we moved resources from App teams to OPU to create more suite-wide features. We de-emphasized app- or category-specific investments. This strategy remained controversial (for years) but was abundantly clear to the market and well supported by JonDe.

In order to talk about a new release, we needed a name for it. We settled on calling the next release Office9, complete with a working logo from the design team. The name was simply the next version number, not anything more (recall that Office 95 was the first time we bumped all the app versions to be 7.0, the successor to Word 6.0, followed by Office 97 as version 8.0).

We spent a good hour one day brainstorming potential code names. While Word had used clever code names, such as Spiff and T3, by and large I and Office shunned codenames. Flashy codenames when leaked were fodder for the press. We considered boring codenames like the government uses. My favorite example was Beige. In the end sanity prevailed and for the next decade or more Office stuck to version numbers.

I wrote a memo, Priorities and Processes for Office9, intending for it to be the planning kickoff, sent while the team was in the last days of finishing Office 97 (meaning only a few paid attention). The memo was a call for us to work together across teams. From a feature selection and prioritization, it was too little too soon, but it was the first stake in the ground on what came to be known as a framing memo, a step in the process for creating products.

Most merely wanted to know the release timing, since that was historically the first guidance from management. Office96 slipped nine months, painful and disappointing. Parallel releases proved brutal and the team wanted to make sure not to do that again. The memo announced one release, one ship date, and one product cycle.

The rest was mostly lost on a team focused on shipping a product that was later than we planned, though it was less of a debate across teams than when we began 12/24. The memo said we would have one of everything: one milestone schedule, one feature planning process, one specification process, one engineering process, one beta, one ship date, and so on.

Writing any memo always presented challenges, especially when the organization took everything in it as a requirement or an absolute, or the opposite, random musings from OPU. Starting a tradition, the memo explained itself and what it did and did not mean—it was a framework and any examples were examples, not specific mandates. At the same time there was a lot of subtlety because the absence of a mandate did not mean anything was possible. The polite way of saying this was that the spirit of the articulated direction needed to be followed. The impolite way of saying this was that the DAD organization was extremely empowered in a bottom-up manner, but this empowerment did not give the team the right to do dumb things or anything they wanted.

As a manager, writing a framing memo became an exercise in making sure I had a direct contribution at the start of every product cycle. Memo writing from execs and at length, other than from BillG, was something few did on the product side, though in marketing and sales, yearly memos created by the staff were the norm. It was important to me to put myself on the line like this.

The Office9 memo set a goal of a product plan memo in a few months called a vision memo. This was the first use of the term vision as denoting a product plan. Historically, a vision was more aspirational and less concrete, but I chose to call it such because I wanted us to feel that a release was itself an aspiration even if the document itself was supported by a concrete plan. It was a play on words for sure and some, particularly outside the team, were confused by the level of commitment to the vision. The vision represented our collective performance objectives and review goals, as an organization and individuals.

The vision was the plan. The vision memo became a signature process, and the hallmark of the machinery that became Office and later Windows through the middle-age of PCs. The process of creating a vision and series of offsites, memos, and communications became the subject of both emulation and some mystery. Teams always wanted to know who wrote the memos, when did I “approve,” or how were “decisions made.” While teams across the company looked to the artifacts such as memos, spreadsheets, and slide decks, the reality was it was the team that came together, and those artifacts simply reflected the collaboration versus driving the collaboration. Simply copying the artifacts ended up like the replicated food in the Squire of Gothos from Star Trek, knowing of “all of the Earth forms, but none of the substance” as Spoke remarked.

A unique characteristic of the vision is that it came from the product engineering team, and not a staff planning organization or the marketing team (as a market requirements document or product requirements document as they were often called in Silicon Valley). This was a key part of building a plan that was a combination of top down, bottom up, and middle out (using again those terms from Cape Cod). We were still a technology-driven company or organization with plans emanating from the engineering function. Incorporating the business aspects of the plan was an equally important part of the process, thus presenting a unified view of the entire business.

For the next months, teams brainstormed about what to build or what code to write. I was struggling with how to bring about a more unified approach to planning. I zeroed in on the vestiges of the product unit organization. Each of the GMs of the product units was still focused on a single product. I proposed to JonDe that we combine multiple apps into teams, broadening the scope of a GM while reducing the hierarchy of the organization (by having fewer GMs).

We shipped one Office box. In fact, while we had many SKUs of Office, the overwhelming focus and majority of business customers chose Office Professional: Word, Excel, PowerPoint, Access, and the new Outlook. This core product remained unchanged though different apps (or modules, as BillG called them) came and went over the next few years.

Sitting in the small conference room across from the big executive office on the third floor in building 17, JonDe and I worked to converge on a plan.

We settled on having an organization made up of Authoring (responsible for both Word and PowerPoint), Data Access (Access and Excel), and Office (OPU). This might seem simple but gave us two benefits. First, each of the general managers had oversight for two distinct types of customers, for example lawyers and consultants. Second, the opportunity for code sharing would present itself given the overlap in scenarios, for example the mechanisms for connecting to databases in Excel and Access.

With JonDe now leading all of Office, the logical successor for leading Office development was Duane Campbell (DuaneC), who was leading Excel through Office 97. Even though he was a development manager overseeing almost 50 people through Office 97, he still coded features in the product. He knew the code across every product better than most anyone and was clearly among the best engineers in the company. He also appreciated my Elvis Presley wall clock in my office. Grant George (GrantG) continued to manage Office-wide testing. Grant had proven himself during Office 95 and 97 as a supreme leader of large-scale testing. He single-handedly advanced Office in new ways.

We shifted more resources to OPU, and for DAD we continued to hire as many people from college as we could—everyone was involved in recruiting. Office became the onboarding group for the company and was brimming with the new-hire enthusiasm of hundreds of college interns and hires every year. We easily hired over one hundred full-time people from college every year, or as many as we could get allocated from the recruiting organization. I was taking two or three recruiting trips every year and would continue to do so for the rest of my career. I loved college recruiting.

One organizational problem we faced was that the newest member of the Office box, Outlook, was not even part of this organization. After the heroic efforts to get the first version shipped, the product was moved to be part of the new Internet Client and Collaboration division (ICCD) within the Applications and Internet Client group (AICG). After years of saying Microsoft would not have an internet division (“that would be like having an electricity division,” according to BillG at our Internet Strategy Day press event), an internet division was formed with responsibility for Internet Explorer, email, and many internet-focused products and technologies.

Org chart separations have the potential to take on a life of their own. Outlook was put in organizational proximity with the mail program, called Internet Mail and News, bundled with Windows 95, and eventually (and confusingly) renamed Outlook Express (code-named Athena, recall this was the replacement for Inbox from the Exchange team). The problem was that Outlook was designed for Exchange server. Outlook Express was designed for consumer mail and only worked with the internet protocols used by internet service providers and universities. In product reviews, Outlook’s support for consumer email was rightfully called anemic. Reconciling the strategy for the new Outlook product family became a high priority, especially since we already chose to name them as though they were related. The code bases shared almost nothing technically.

Outlook 97 was placed on a rushed product cycle to fix the deficiencies in internet support. This was a classic strategy that almost always backfired (as would be the case in this instance). What was supposed to take a short couple of months stretched out for more than six and resulted in Outlook 98 shipping in June 1998 (Office 97 shipped in November 1996). While the rest of Office was planning the next release, a key part of the product was working on what was termed an “out-of-band” release. Worse, the release was rather a hack in how the internet was supported. Running Outlook for the first time offered up a choice to run the product in Internet Only or in Corporate or Workgroup. The whole product had basically been split into a giant if statement. As a bonus, the product switched to a different installation technology, playing havoc with our total cost of ownership story. Outlook also missed out on planning with the suite. Yet we had just finished launching and selling LORGs on Outlook as an integral part of the Office suite.

The deficiencies of Outlook caught the eye of a future college-hire, Jensen Harris. He found the time to create add-ins for Outlook 97 that enabled it to do some of the things possible in Outlook Express and expected of any internet mail application. Jensen would go on to become one of the most significant contributors to the design of Outlook, Office, and then Windows.

It was all quite messy and the kind of crisis development that was rapidly becoming incompatible with the LORG focus of our business. We quickly regrouped with the Outlook team for the next release of Office, though as a result fell behind on the integration of Outlook with the suite.

This was literally shipping the org chart. We had to live with Outlook in this state as we planned Office9 and as we created and announced the Office organization.

If the framing memo was the first step of kicking off planning, the second was putting an organization in place. The planning efforts informed the choice of the organization, while at the same time the changes being considered, especially resource changes, inform the planning. Iteration of a feedback loop is crucial to moving forward while also avoiding lock-in based on organization.

We announced the org structure and had our first experience realigning the team and resources for a new release. That was easy. Not really, but it was done. Rolling out the changes and announcement was incredibly stressful for most everyone in management, on every side of the change. We even did a post-mortem on the announcement itself and collected feedback from a survey.

Everything felt new. New organization. Hiring many new people. New product mission. Even a new business with enterprise licensing and LORG customers.

I did learn one thing though as I walked around the halls and the cafeteria after the org change. By and large, most people didn’t really notice or care. They just wanted to know the ship date. milestone schedule, and most of all who their direct manager would be. That was a particularly good lesson for me. It reminded me of a story my Russian teacher from college told me at my 5-year reunion when we caught up. With the fall of communism, I asked him what his friends back in the former Soviet Union thought. He smiled a bit and just said, “Well, everyone still had to wait on line at the GUM department store the next day to see what was in stock.” A good reminder, that even in times of significant change, the local effects are what people pay attention to.

All the teams switched to using a variant of “9” for the names of the apps and we looked and acted like a single team, Office9. At least so far.

On to 048. Pizza for 20 Million People

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