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.

LISTEN to this post — NEW FEATURE — The audio for this post is embedded with the full text and all the images and supporting materials. You can listen right here in the browser or in the substack mobile app (iOS) which is super nice. The separate post with audio will still be there but the emails will stop after this week.

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.1

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.”