087. Reorg! Why Are We Together, Exactly?

After thinking and writing to provide context to BillG, SteveB, and KevinJo, I had to begin the real work of changing the team. As much as I would have liked to avoid the second step of the “Three Envelopes” (having skipped the first) I found myself planning a reorganization. Not just a reorg though—Microsoft was by many accounts in a perennial state of “reorg hell”—I was planning an organizational change and cultural transformation that would have an effect on every member of the team, almost immediately. That meant more writing. More communicating. A lot more.

Back to 086. The Memo (Part 2)

Most big company reorgs are fairly routine affairs that nevertheless cause teams to drop everything, stress out over the weekend (because reorgs always happen on Fridays) and contemplate what might change. But then returning to work on Monday, little changes immediately except for somewhere up the org chain there’s a new boss who will in a matter of time introduce some changes. Most reorgs are not nearly as big a deal as all the time and energy that goes into talking about them.

This was especially true at Microsoft which, at least to many, felt like it was in a constant state of reorg hell. In my early days at the company, I experienced several reorgs in the most senior (other than BillG) executive structure from having a president to not having one, to adding a COO to removing a COO, three-in-a-box (the BOOP, Bill and the Office of the President), back to a president, then a president and COO, then SteveB as CEO and BillG as Chief Software Architect, and so on. Office itself bounced between a few executives over the years as well. In fact, just as I was in the middle of planning this June 2006 announcement, BillG announced he began transitioning from Microsoft to spend more time at the Foundation. Ray Ozzie (ROzzie) would be appointed Chief Software Architect (CSA).

The thing about reorgs is that most people are trained, best case, to scan the reorg mail and see if their team is directly affected by the change. Specifically, how far away is the new boss. If there’s no immediate impact, then just go on doing what they were doing. In practice, most reorgs at scale don’t affect most people directly or immediately.

The Windows and Windows Live changes were not like those reorgs. This was not a change at the top. This was a change for literally everyone in the organization. More than half the team would get new managers soon after Vista shipped, and everyone would have a new manager no more than three hops up the chain.

It was even more than just that. Jobs were changing and with that many mental models of career paths were being upended. Everyone who thought they had plans for what would be next would wake up to something different. Aspirational jobs as a PUM or an architect with no direct reports (or code) were no longer going to be available. We were an engineering organization, and everyone was going to be asked to focus their trajectory on building products. Even becoming a manager was deemphasized as we asked managers to take on more directs while we reduced the percentage of the team that were managers by one-third.

Then beyond that we had every intention of radically changing the way we would work. Everything from the planning process to daily builds to milestones. Even meetings with execs would decidedly change (or mostly go away).

I spent May and June 2006 on two things.

I was mostly meeting more people on the team and figuring out who would be filling in the organization I am about to describe. These meetings were a constant reminder of the desire for change. They were also opportunities for ongoing reminders that Windows and Services are different and more difficult than Office. I probably wrote 500 long emails replying to questions about everything from the future of specific technologies (most of which I knew nothing about: USB, DirectX, virtualization, and more) or to suggestions for how we could improve. I received quite a few questions asking “how do you want us to…?” on everything from hiring to signing purchase orders. There were many questions that were very specific to situations and people that I knew nothing about. The questions always seemed to boil down to process and culture challenges, never about domain expertise. It was 7x24 from the end of March to the end of June.

To remain sane, I was also installing daily builds of Vista and Office 2007 which were both winding down. Not being in the daily triage meetings for Office was kind of sad for me. I vividly remember sneaking over to the ship-room meeting one time, which proved to be silly and indulgent on my part and a distraction to the team. It was, for me, a moment of sanity just to see the team working, and by that I mean not taking any code changes.

Mostly, however, I was genuinely scared. I had absolutely no doubts about what we needed to do, including how to structure the team and what to ask of them. I had a lot of doubt that I’d be able to pull it off and most days wondered if I was the right person to drive these changes. There was so much baggage coming from Office.

Something that I was keenly aware of was how many managers, myself included, viewed reorgs as something of an adversarial process. A reorg was something to protect the team from, not something that could help. Reorgs prevented work from happening and were a distraction. That’s certainly how I treated a lot of what went on above me for most of my career.

Now it was my turn. The very last thing the company needed was for people to view the changes I was putting in place to be prevented or redirected. I was terrified.

Would people quit? Or likely, how many people would quit?

Would people run to the gossipy press or Mini-Microsoft?

How much email would be sent to SteveB or BillG? And, yikes, would they answer it?

What if no one wanted any of the new jobs I was proposing?

My first step was to figure out the new leaders. In picking those leaders I was also certain of how the overall organization would be shaped, my direct reports and their direct reports and so on. This structural change was the visible symbol of the reorg. It was a massive pivot away from a product unit organization to what I called a “functional organization.” A functional organization is based on having discipline specific leaders reporting at the top and their teams consisting entirely of people within those disciplines of development, testing, and program management. Across each of the disciplines we would have mirror structures of group managers, leads, and individuals. I sketched out the math and knew we could build the organization out of about 40 teams of 25 developers each (and 25 testers and a dozen program managers, under their discipline leaders.) In due course, the intention would be to organize COSD this way as well though we needed to let them finish Vista for a bit more time.

I would love to spend more words in this section describing the inherent tradeoffs between these two organization types, but it would be a bit of a distraction from the story. Instead, I would refer the reader to Functional versus Unit Organizations, an essay I wrote in 2016 on this topic.

In assembling a team of new leaders, I tried not to be the guy who brought “his people” from his old job, but there simply weren’t any candidates in Windows that would champion the changes we needed. You’re not supposed to show up with a team, but managers almost always do. I never understood why that was the case, but after living through this I have a more visceral understanding. It is not about the personal connection, as most think, but in times of change you need to have a team of people who share the same world view by default without having to guide at each step. Without that, change is impossible.

I thought I wasn’t going to be that exec, but I was. Only to a point, however. Within the team, I was able to find a balance of “natives” and “imports.”

Here’s how the leadership team shaped up: The Search team remained as it was, under Christopher Payne (ChrisPa) working on its own roadmap and plans, but with much more capital and more people and soon a functional org structure. Chris Jones (ChrisJo), a longtime executive on the Windows Client team, would lead program management, design, and research for Windows Live Experience, WLX. Leading development would be Steve Liffick (SteveL.) Steve had Windows Live deep in his DNA, but he had been a program manager his entire career (having grown up in Seattle, interned at Microsoft, and joined straight out of college the same summer as I did.) The challenge facing the team was a lack of senior enough software engineering leadership to manage a team of several hundred, so he agreed to manage the engineering team and would prove to do an excellent job over time. Arthur de Haan (ArthurdH), a longtime test leader in Office who had built out the internet services operational infrastructure, also joined the team to lead test and internet operations.

The new name for Windows Client was the Windows Experience team, or WEX (pronounced weks). WEX needed a program management leader. In many ways this job was the program management job at Microsoft. Vista screamed out in need of program management—it needed a holistic view of the user, the customer, and the experience. Julie Larson Green (JulieLar) was ready for a new and bigger challenge after leading such an extraordinary effort redesigning the Office user interface. She was just recently promoted to vice president for that contribution on top of her long history of successful product development and team leadership.

Aleš Holeček (AlesH, which coincidentally is the proper pronunciation of Aleš) wore his Czech heritage proudly and maintained close connections to Prague, one of the most creative and vibrant tech communities in Europe. He also frequently, and inexplicably, wore bright red pants. AlesH was in the process of leading a rescue mission for large parts of the most visible portions of the Longhorn Reset. In short order, as a new hire to Microsoft, he had established himself as a strong leader and deeply knowledgeable and respectful of Windows as a third party developer, but also clear on where Windows needed to go. After several discussions, I sent him the shortest of emails asking if he wanted the job leading WEX Development. An hour later we had a leader.

The testing role for WEX was going to be the most visible testing leadership job in the entire company. Windows, almost more than anything, was a product of testing. Grant George (GrantG) was busy completing Office 2007 and was so focused he was reluctant to even chat about what comes next—focus was one of Grant’s defining traits as a test leader. In speaking with him, it was clear he was excited about the challenge. But he had also been much more deeply involved with Windows than I had considered, especially over the past few months, and hesitated because of his concerns about the culture. After a couple of weeks of being left to his own thoughts, he came back willing to sign up. This was a huge win for the team.

With a team in place, I penned the longest reorg mail of all time. In hindsight, this surprised nobody, but at the time it was, well, shocking. It was not just an announcement, but an explanation and justification for an organizational pivot—moving from product units to a functional organization with large groups of each engineering discipline and very few product unit managers. While not an intentional play on words, functional organization worked that way too.

On the last Thursday in June 2006 (breaking with the tradition of Friday afternoon reorg mails), I sent out a 3-page email with an attached 20-page memo (with no org chart or diagram, and no to-be-hired spots). At more than 13,000 words the memo was titled “Windows and Windows Live: Organizing for agility, Competing with focus, Building must-have software.”

I even did something I had never done before, which was to copy the mail to all of Microsoft’s executive staff and their direct reports all around the world. There were about 150 execs at the time plus their directs (and usually staff). I broadcast the mail, in the last days of the Vista project, to send a message that we were working and making progress.

As soon as this mail landed in the inboxes of about 6,000 full time engineers (and designers, localizers, planners, and more) they would all hear that their jobs would be different. But precisely how would take time. It would take weeks to build out the five or so layers of the organization, down from 7 to 10. There was no spreadsheet with all the answers for each person. Not even close.

In fact, taking a lesson from Office, we put in motion something that was yet another point of evidence of how different things would be. There was going to be a bit of a free market for people to stick their collective heads up and decide what they might want to work on next. Everyone had a job, working on their old area or perhaps trying something new. At the same time, the new execs would be choosing new direct reports who in turn would be choosing new managers and those people choosing new leads.

The previous two sections detailed the process I used to learn and the memo I wrote for an audience of three to crystallize my thinking. Now it should be clear it was a rough draft for broader communication. I moved from “Observations, Aspiration and Directions” to “Organizing” and as you look at both you can see the tone moving from analysis to action. In many ways I was employing the same planning process we use for software to design the organization—open a funnel to inputs, iterate, and at each step distill down the actions to what is essential for success.  

But hitting send on this memo led to the most workplace stress I had ever experienced or would experience, not to mention the stress for all the new leaders who would be crushed with questions and concerns. Significantly, I knew how stressful this was for every individual. I felt or hoped that the messages would be read and considered even if not immediately validated, recognizing the emotional nature of so much change.

There was sizable pent-up demand for a reorg as that is what people were expecting, but I was terrified that somewhere in this memo I unintentionally offended someone, or that I perhaps expressed too much candor, offending a constituency in a deep and unrecoverable way. I was certain that I was going to immediately get an email from Mary Jo Foley at ZDNet, who was going to reprint the whole memo (I even had a “I am being transparent so don’t make me regret it" plea in the mail message cover note). It worked. No leaks.

I diverged from Microsoft culture in ways many found shocking but was routine for me and Office. I sent out a reorg mail without a directed acyclic graph of the organization at the top of the mail. Even more shocking, there was no org chart at all. When people opened the mail, it was as if they had opened a box of Cracker Jack candy and couldn’t find the prize. I received countless replies to the mail asking for the org chart, some of them not particularly supportive of this cultural statement which was simply perceived as incompetence or insensitivity. Additionally, the organization was complete in the mail, absent any open positions or to-be-hired.

On the other hand, I also received so many replies that were positive beyond words. The desire for something significant to put the team on a path to better results was clearly in the air. From my former co-worker in Office, Jeanne Sheldon (JeanneS), who is (even to this day) an absolute stickler for brevity and clarity in writing (a decade leading Word testing would do that even if originally choosing to work on Word because of this skill) had perhaps the kindest words. Jeanne replied to me saying “This doc is a masterpiece of clarity and focus. Although it is long, it could have been neither longer nor shorter. Wish you could do another employee poll tomorrow.” I needed that.

Much to my relief, the mail received a rather heartwarming reception. I received hundreds of messages from people who appreciated the transparency—the mere heft of 20 pages, which I know most people did not comb over like the Code of Hammurabi or anything, provided some air cover. (Some even complained about having to read a memo of such length—a complaint that would become something of my brand if it wasn’t already.) Being able to answer questions in town hall settings and then saying “there’s more in the memo” became a bit of a rallying cry for me along with a pointer to the inevitable follow-up post on my Office Hours blog.

Still, I received a few dozen deeply emotional mails combined with one-on-one conversations. These were people who were the most affected, particularly by the perceived loss of status or career trajectory when it came to product unit management. I knew these conversations would be the most difficult and dealt with those the best I could. No one was being demoted in any way from my perspective and the organization had a place of equal level and opportunity for everyone. There were no formal staff reductions at all. Surprisingly, we fielded queries from the press about layoffs which were never considered. I was asking people to take on roles more directly accountable to engineering outcomes. For some, and it was a small number, it was just not appealing, and they moved on. Each one of these cases was enormously difficult. I’d like to say there was some emotional distance for me because I didn’t create the situation we were in, but there’s no way to avoid the feelings of the moment—I in fact did create this change.

With the mail and the memo, I went out on tour and so did each of the new leaders. The slides to explain the reorg were focused on the strategy of “Why are we doing this” and “Why are we together.” KevinJo came up with a hierarchy that we used across his expansive world consisting of product lines, engineering areas, and feature teams. Kevin was used to organizing tens of thousands of people and had real insights in how to use hierarchy to communicate.  

I answered the “Why are we doing this” question with a slide on “Goals of Organization Changes.” This was the core of the discussion. I made people sit through my talking about this slide at length rather than, as usually done, emphasizing the structure or org chart of the team. The reasons behind the org were a direct reflection of the past 90 days of learning as I thought back to the first memo previously described.  Many of the exact same words were used that I had written a month earlier.

In the description of product lines, we intentionally left off the name COSD but it was implied in the Windows/Windows Live product area. People would get the message that COSD was part of Windows, not separate or even Windows entirely.

To address the question of why we were together I created a table of the engineering areas for WWL: Search, Live Experiences, Internet Explorer, Windows Experience. The “glue” as I said at the time was that Windows, as critical as it is, needed a series of connected services that were core to Windows. This was a subtle shift away from Services independently focused solely on advertising. This vision would take time to materialize. One can see how Apple was also just starting this same push with iLife and iWork on the Mac. Recalling the fits and starts of services connected to Apple products is a great learning exercise. What we know as iCloud today was originally launched in 2000 as iTools, which were desktop applications for photos, video, and productivity. In 2002 the addition of email and other online services came with the branding of the .mac service. Then in 2008 (two years after our org change) the service was renamed to MobileMe and greatly expanded, which lasted until 2011 when it became iCloud. Phew. That is some journey to get right. We would struggle much the same. It is interesting when everyone seems to have the same idea of where to go but takes many years to get there and not everyone even arrives at the future the same way.

The other glue across WWL was Internet Explorer. This was the era when tuning online services to the latest browser was still important. The struggle to deliver great experiences via the web that matched desktop applications was significant, as was owning the “frame window” for delivering advertising and promotions. Due to the declining popularity of IE and lack of work on a new version, Search and WLX (and the rest of the internet) had pivoted hard to optimizing for Firefox. It is not without irony that as I write this in June 2022, Microsoft has just announced that Internet Explorer has been officially retired and replaced by the Edge browser based on Google’s open sourced code.

Each of WEX, WLX, Search, and Internet Explorer had sections that outlined the major themes to be investigated or worked on for the next products. There were no names of feature teams, no schedules, no user interface sketches. Astute readers could see where we were heading and how, as we dove into more understanding about these areas, it would inform the next level of the org structure and then specific product features would follow. This is what we had mastered in the past four releases of Office, so I felt confident we could scale it here.

Change started with this memo. I summarized this change as follows, quoting from the original memo:

This memo represents a change.  Change is difficult.  Change is uncomfortable.  Changes that look good today might also have looked good before and failed.  Changes that look good today might not be so great tomorrow.  Change is risky.  The changes outlined here are not just tweaks, but represent the first steps in working in a substantially different manner.  Many of the issues raised by members of the team are about the culture of our organization—these are the aspects of “how we work” that must be addressed. 

This memo is about the top line changes—the organization and priorities—and over the coming months the way we work together will also change.  We will push more decisions down.  We will aspire to a more consensus approach to decision making, rather than an escalation approach.  We will streamline our organization with fewer managers overall, and fewer levels of hierarchy.  We will value our core engineering disciplines more and demonstrate this by building an organization that focuses on the role of development, testing, program management, with integral contributions across the product line from design, usability, planning, localization, business development, operations, and more.  We will ask our teams to be clearly focused on deep technical contribution in a smaller number of well-defined areas, rather than breadth of coverage at too shallow a level.  We will allocate resources more deliberately and generally in smaller teams.  All of us may not operate with the same tempo, but we will all operate with a rhythm and not move from crisis to crisis.  We will operate with a clear framework with a clear understanding of how we will define success, a framework that is flexible and has vast room for innovation, yet represents a commitment to customers that we will deliver. 

These changes are part of the agenda of this memo and our organization moving forward, but will require all of us to learn and grow together.  I am committed to doing my part.  I will not dive into the middle of situations.  I will not randomize your work.  I will not be a bottleneck for decisions.  I am here to work with the senior leaders of the team to provide the framework, define success, provide the resources that map to those, and make sure we have the right people with the right skills in the right jobs to get the work done that you commit to doing.  That is my commitment to change. 

A few weeks after this communication blitz (July 22), KevinJo announced that Jon DeVaan (JonDe) was going to lead COSD also reporting to him. Partnering with JonDe was going to make everything better—Microsoft was very lucky that Jon took on this role. This was a bit of a reunion for us. I thought back to meeting Jon the first time in the summer of 1989 when he pointed out so thoughtfully how interesting yet naïve (in a commercial sense) my views of memory management bugs were. Then through a few releases of Office as peers and then Jon as my manager, promoting me to vice president. Over the past few years while I remained in Office, Jon had been leading a new team called Engineering Excellence, which brought all manner of excellence company wide. Under Jon’s leadership the team introduced and deployed tools and software for training and management as well as individual excellence. Largely not followed outside of Microsoft, the EE team was critical in scaling, training, and developing the company’s engineering capabilities across every product line. It was the first substantial effort at training engineers since “Klunder College” for new applications developers, which ended decades earlier. Jon was uniquely qualified given his lifetime of experience to re-energize the engineering culture of Windows. So loved as an engineering leader, an early 1990s pre-beta build of Excel once read “Excel DeVeloper Release” in the About box.

Jon created a top-level organization structure to parallel WEX by naming three senior leaders for development, program management, and testing, respectively Ben Fathi (BenFa), Chuck Chan (ChuckC), and Darren Muir (DMuir), each experienced Windows leaders, for a new team Windows Core Services (WCS). Their peers and counterparts in WEX were AlesH, JulieLar, and GrantG. In addition, Jon would have a team of architects (the original COSD architecture team) as well as the corporate resource team for security engineering, a.k.a. Trustworthy Computing, and a large team providing the fundamentals engineering, engineering tools and measurement, sustained engineering, and support for in-market products that would produce urgent, monthly, and regular service updates led by Wael Bahaa-El-Din (WaelB) called Windows Engineering Services (WES.)

The WEX and WCS split of Windows was a first turn of the crank organizationally to building a unified Windows team. Jon and I were 1000 percent unified at the top. Our respective teams were unified. Still, it would be fair to say that the old rivalry or tension between Windows Client and COSD would continue to manifest itself until we were well into building the next product. Jon and I were working to create an organization of peers, but history did not see the teams that way. There was a lot WEX would need to prove to WCS in term of focus on performance and quality, and much WCS would need to prove in terms of building an exciting product. When tensions would arise so would the old names of Client and COSD—that’s how Jon and I knew we still in the midst of a culture transformation. In practice, the COSD name stuck around for the release as we most always were talking about WCS and WES (I will generally refer to COSD throughout this chapter.)

In practice, this was all part of the slow-rolling process of changing the direction (the culture) of a giant ship. The structure is only the first change of many. I remember when I was relatively new to Microsoft and BillG created the Office of the President and announced it at a big meeting (well, it wasn’t that big since all of Apps fit in the old Kodiak room back then—still hundreds of people total) and then went back to my office and kept working. An analogy I often used about change came to mind. The reorg was like how the Soviet Union fell and then the next day everyone was back at GUM waiting for winter coats to arrive, but over time there would be huge cultural changes.

As interested (or perplexed) as people were with these changes, they wanted to know who their boss would be and what they were going to build. Reorgs always come down to the most localized interpretation possible.

Something I should say about this organization that is incredibly important. While I’m obviously as biased as can be, this was the very best team at precisely the right time to do exactly what Microsoft needed to get done. Perhaps that is a bit much to say, this was decidedly a collection of Super Friends, each of whom brought their own unique “super-power” when Microsoft needed it. For the remainder of this work, everything good that I will write about happened because of this group of leaders. The Microsoft of today owes them enormous gratitude, not just because of what they did from this point forward for Windows, but several were also foundational leaders of Office that so dominates Microsoft today. They ran towards the fire.

But figuring out what we would do was going to take another six months. Whether that seemed like a lot of time or a little was a matter of perspective. Teams that were done with Vista would just start doing what they thought should come next, likely what was just cut, rather than what might be optimal for a product plan. Whether the team wanted to acknowledge it or not, there was also a ton of work to be done on the basics of the engineering system.

The changes weren’t over. They had barely started.

On to 088. Planning the Most Important Windows Ever

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