085. The Memo (Part 1)

Everyone in their career should have one memo that they think of as the most consequential. For me, it is a memo I wrote after a about six weeks on the Windows team. Under intense time pressure to figure out what comes next with Vista rapidly approaching final release (not formally, but it was going to soon be all but impossible for code changes to make their way into the product) I had to come up with next steps. Over the next four posts, I want to share not just the memo but more about what it is like to live through a major organizational crisis and work to set things up for building a new engineering culture and new team structure, all in a couple of months.

Back to 084. How Many On the Team, Exactly?

The history of Windows releases was cursed when it came to product and leadership. Like Star Trek movies, Windows releases alternated between good and bad, odd and even. Line up the OEM products by availability date, and you’ll see this is basically true—starting at Windows 3.0 and changing to the NT kernel with XP (3.0, 3.1, 95, 98, 98 SE, Me, XP, Vista.) Compounding this, the curse says, no leader seemed to last more than two major releases of Windows.

My neighbor, a successful biotech entrepreneur, asked me about the curse the day he read the org announcement in The Wall Street Journal story saying that I was moving to Windows. He wished me luck.

After 140 scheduled 1:1s, 20 team Q&A sessions, over 30 hours of office hours, and countless hallway conversations in a dozen different buildings I had to do some thinking and organize what I observed, heard, and learned. That meant writing.

A dose of reality was needed with BillG, KevinJo, SteveB, and to some degree even the Board.

I did that with a 20-page memo titled Observations, Aspirations, and Directions for Windows and Windows Live. For me writing is thinking and I really had a lot to think about, hoping others would join in. I felt alone for long enough and I was certain SteveB was growing increasingly anxious for what would come next. I had been talking to KevinJo constantly over the past few weeks as he was doing a huge amount assuaging those that essentially rejected the idea of an Office person leading Windows.

The 20 pages were the most difficult I wrote in my entire career—to literally put these words down—I knew they would be impossibly difficult to read. I was deeply concerned that what I wrote would be viewed through the simple lens of setting expectations or painting as bleak a picture as possible so that I could be a hero later.

It seemed that everyone, especially SteveB, wanted the plan for getting things back on track and a product roadmap. He also wanted to be able to communicate to the field and bring comfort to customers, while continuing to support Vista when it shipped. Bill was especially keen to restart discussions over product investments that had been cut since the Longhorn reset. Kevin was getting his footing across wildly disparate businesses including the massive money-losing online services.

I couldn’t kid myself, however, as I too needed a plan. The team was still frantically fixing bugs, but in order to ship by October that would soon end. The bar for fixing bugs would rise dramatically by summer. Idle hands will make trouble for sure. Projects will start, code will be opened up to changes, and worse presumptive commitments to outside customers and partners would be made, and so on (all business as usual for Windows.) For there to be a release that addresses any challenges I would need to orchestrate that every team at a project arrive at the starting line at the same time in order to finish at the same time. In other words, I had only about four months and one shot to get all this figured out.

Adding to the stress, the OEMs were extremely anxious as they were reeling from Vista missing both back to school and holiday selling seasons. They were used to hearing plans, or at least slide decks, about future releases so they too could plan, as much as that was worth. A January launch was painful for PC makers as it meant they had to stock up retail outlets with PCs unsure if the buzz over a new OS release would dampen Holiday sales or not, and then deal with upgrades new customers demanded on those PCs. It was messy.

In round numbers, fiscal year 2005 had revenue of about $40 billion and net income of about $15 billion. The Windows OEM business on its own was $12.2 billion (about 30% of Microsoft—incidentally it is not possible using public data to compare these to today’s Microsoft, much as people claim to) and $9.4B in net income (about 63% of all of Microsoft). OEM revenue was highly concentrated in six major and global PC makers, each CEO with a direct line to SteveB and KevinJo.

My memo solved for none of these immediate issues. Instead, it was a lot of bad news and, in contrast to conventional wisdom or expectations, was less about strategy as it was about execution and culture. It diagnosed, without blame, the situation as I saw it. I provided a ton of data about the organization. I detailed structural problems that I was worried would feel trivial up the management chain. It was a lot of work to count the number of people and find out how much money was being spent (on projects, not salary). It was disappointing that for all of the staff and managers, the most basic controls over dollars and headcount were not in place.

Something BrianV once told me really stuck in my head years earlier. In his inimitable way he reminded me, “There’s just a lot of s**t going on in Windows all the time.”

I was fast learning he meant that in every way possible.

There’s an old business story usually called “The Three Envelopes” about an incoming executive taking over a dysfunctional team. The outgoing exec offers advice to the successor in the form of three envelopes, with instructions saying, “when things get tough, open them one at a time.”

After a bit of time, things indeed got tough. The new exec opens the first envelope. It says, “blame your predecessor.” They do and it buys some time. A bit more time passes, and things take a turn for the worse, so the second envelope is opened. It says, “plan a reorganization” which improves things. Some more time passes and desperate for help, the third envelope is opened. This envelope reads, “prepare three envelopes.”

Good grief, I thought. I felt like I’d become the punchline to a business joke.

I promised myself I would never blame my predecessor and never ever did. I went out of my way to avoid that not only myself, but to remind people not to do the same. There was no escaping we were going to enter some new era as a team, hopefully for the better, but I was not going to permit our time to be defined as positive compared to a blame-worthy negative.

I was troubled, however, because I knew we were going to reorg. I really thought I could get through this change without becoming a living cliché, but as I quickly realized sometimes a cliché is born out of countless experiences. As it turns out, most of the time to fix a dysfunctional team there’s going to be at least changes in leadership if not structure. With so many of the leaders choosing to make Vista their final release of Windows, I would need to hire replacements, so why not new jobs? The memo was a precursor to much larger changes and designed to motivate those changes with facts, not blame. Unlike most reactionary reorgs I had seen (at Microsoft and elsewhere) it was also not based on swinging a business pendulum in the other direction as is often the case.

I continued to be concerned there was a perception that if we could just get a good strategy deck then my job would be to do what I do, which was to be a tyrant—take the new strategy and execute. The strategy wasn’t there, nor would it be, but I viewed that as a third-order problem. Besides, strategy without a product plan isn’t really a strategy. As the saying goes, “culture eats strategy for breakfast” (often wrongly attributed to guru Peter Drucker.) I was under no illusion that the current team and structure presented with even a perfect product strategy could execute it.

The engineering culture was broken.

In fact, over the previous few years, while SteveB had been increasingly leading the company, he embarked upon initiatives that presumed execution was the key problem to address. Key among those was an updated performance review system based on “commitments.” Everyone was required to document their commitments (goals, tasks) and share them up and down the management chain for review and approval. On some level this is a solid approach, and in start-ups the concept often works well (such as the well-known OKR process used at Google). At scale, however, this type of process too often devolved into people gaming the system with vague commitments or aiming to set low expectations. I was not a fan. That wasn’t going to help this team.

There was a special difficulty in diagnosing and sharing execution and management problems with two people who basically never had managers, BillG and SteveB. KevinJo, on the other hand, was an expert in scale management and a true ally in this regard. In fact, he had clearly orchestrated many more people than I ever had. Adding to the degree of difficulty was to what extent they would, especially Bill, take my assessment personally. I was quite concerned that I would come across as way off base on what needed to change, and even more concerned that this would not go well. Perhaps worse, they would think I was blaming their leadership and JimAll’s as well.

I was having flashbacks to a mismatched conversation with SteveB about Windows Phone leadership (c. 2000) and what was needed back when Steve was looking to change phone leadership for the third time in as many years. He ended up talking to several other product leaders, each of us saying essentially the same thing—the phone needed a full reboot, in the team, business, and code, to compete with (then leader) BlackBerry. There was a mismatch that continued for quite some time.

Avoiding an early product strategy discussion was important. The easiest thing for execs to do in time of crisis is debate the specifics of product features. In those discussions, there’s a strong desire for a silver bullet—one change, one addition, one synergistic initiative, or one deal—and then to ignore all realities and externalities and rush execute that. We were in the midst of the Vista project which itself was designed around both synergy and silver bullet features, such as WinFS and Avalon.

Above all, this would all be extraordinarily difficult for me because I’d been either watching or participating in this brewing problem for most of my career. I had come into this role not thinking there was a Vista crisis but thinking there was a Windows crisis, years in the making, with Vista merely the latest symptom. It was not just the odd-even curse of releases but the challenges we had collaborating because of the differing methodologies of the two gardens, which was difficult in the best of times. Not only would I have to break free of my own prejudice, but any visible display of prejudice would immediately snowball into a horrible situation that would be perceived as something of a hostile takeover of Windows by Office. Given that Office was always viewed as the subservient business and technology, this was not acceptable.

The risk of being rejected outright by the Windows team was very real, much more so than the external view of the savior arriving.

Working to my advantage were the ever-present “quality of life” challenges the team faced. Most every discussion—1:1, team meeting, or small group—was much more about the way work was done rather than what work was done. There was a deep-seated victim complex, and the perpetrators were management at every level and some specific managers/execs. I abstracted these concerns to what I considered three relatively mundane concepts, the kind found in any management book, and illustrated them for BillG, SteveB, and KevinJo with some concrete and dramatic numbers. The details on the Services teams were decidedly different from Windows, though the issues were largely the same. In fact, the challenges were identical, just manifested differently owing to the delivery of code and business model more than anything.

While I diagnosed three main areas to work on, areas that would motivate the proposed changes I was going to make, I spent almost five pages on a situation analysis. Writing about the way I saw things at the time I shared some of the following (summarizing from the original):

Engineering Skill. Windows has the industry leaders in PC technology, having invented much of it. In industry technologies ranging from Wi-Fi, USB, printing to Microsoft’s own technologies such as Hyper-V or DirectX, the team has unmatched and extraordinary technical depth. Translating that depth into high-performance, secure, robust, production code has been challenging. The Longhorn project showed a great deal of technology potential but across the main initiatives there was a broad inability at every level to turn that into products.

Fatigue. The Online Services team has been running non-stop for years, releasing every month and spawning new projects, but with little in the way of product success or share gains to show. The recent financial results causing a pullback on headcount growth have really left the team shattered. The Windows team is on year 5, though optimistically it is only year three since the reset. The recent schedule change all but cancelled summer and the holiday season for most of the team. The team is fried.

Maturity. There is a decided lack of subtlety or nuance in how the team approaches problems. By and large even the most senior people think and act locally, almost in survival mode. In discussing the situation with senior people, they invariably jump to unsophisticated solutions such as cancelling projects or putting groups under a single manager. The idea of being both fiscally responsible and investment minded is difficult for most to grok.

Bloat. The organization is bloated with middle management. There are too many multi-disciplinary managers (PUMs) which (as will be discussed) create a deficit of senior engineering leaders. This creates an absurd engineering structure where small groups flail on problems too big to solve, escalating to a PUM who has the sole motivation to keep the decision local for fear of losing control while lacking the personal experience to adjudicate the issue. This bloat also caps the ability of the organization to grow senior engineers.

Science Projects. The organization is filled with science projects. These are projects operating as though they are building product features, but they have little chance of achieving critical mass and an even smaller chance of remaining sustainable over time, if they ship at all. One way to view this is how cool it is to be exploratory and entrepreneurial. The vocabulary used to describe these is always “delivering value to customers” which is far from the reality. These continue despite the broad view of a resource crunch.

Hiring. The lack of deep excellence in senior leadership for development, testing, and program management creates a difficult hiring situation. There exists a highly distributed hiring decision process and a large number of open heads. This pressures relatively junior people who are under the gun to deliver to onboard any “warm bodies” they can find and in doing so these hires are often over-leveled or over-compensated, creating a down-stream fairness problem for the whole organization. The PUM model often drives poor calibration for promotions simply because the PUM sees people only through the lens of a tiny team they are trying to hold together.

Competitive Fire. There is a curious lack of competitive fire relative to Macintosh, Linux, Google, and Yahoo. There is a broad and vibrant spirit around the concepts of providing software that competes with these companies, but a clear lack of understanding of how what we build stacks up and what we are doing about it. For the most part this shows as an organizational challenge since everyone thinks to be competitive everything must be under one person and nothing is today. This was particularly odd as I was already running Linux at home long before this job and posting unboxing videos of the iMac to YouTube. I saw few Macs, iPods, or Linux boxes anywhere. In fact, the team was even lobbying to prevent the use of Google search at Microsoft’s firewall. Everyone is aware of these but thinks competing is the job of a mythical compete team or belongs in a compete lab, not just in daily use. This is not just at the top level, but at every subsystem where the technologists are not aware of how competitive platforms support an industry standard technology.

Bureaucracy. The engineering process is loaded with universally accepted yet loathed and mindless bureaucracy. For Windows, the processes pushed down to teams in the name of security, builds, quality, etc. are not yielding the results but forcing people to spend creative energy working around those processes hoping to get something done. In Services, thought and judgment have been replaced by a Rube Goldberg set of key performance indicators that themselves would make for a case study in how to make sure things don’t get done. Even the most basic corporate administration work from finance, to legal, to administrative assistants seem over-staffed relative to headcount. Here again the tiny teams headed by a PUM create excess overhead.

I was rather reluctant to share the above. I recognize just how harsh and potentially insolent these statements were. Any one of them could be taken out of context as too broad an indictment of too many or worse about specific people. For each I could offer specific examples if called to, but I so much wanted to avoid this becoming personal. I saved specific callouts for things that were clearly going well or simply stood out relative to these themes.

This was a brutal list. I remember meeting with BillG and seeing his felt pen markup, his callouts, all over this section of the printed memo—and we debated many points he did not agree with. SteveB was deeply in touch with the management challenges, and his unusually silent agreement spoke volumes as I felt he was disappointed to see these findings while also relieved, in a sense, that someone was willing to diagnose and address them directly.

The bulk of the memo documented three areas in need of attention: decision-making, agile execution, and discipline excellence. I presented a situation analysis with supporting facts and data. To avoid being super negative, I also suggested what our aspirations would be for each of these attributes.

Initially, these felt rather anodyne but soon became rather crisp talking points for what amounted to my stump speech as I began to engage a very small set of people such as Ray Ozzie (ROzzie, now CSA) and Dave Marquardt (member of the Board). I perceived a consistent feeling of uncertainty over what to do with my assessment. The questions were much more about what to do—when WinFS would get done, or what should we tell the OEMs. In KevinJo’s case, he simply agreed and said we need to just keep moving and asked how he could help. He was so supportive.

Decision-making was the first topic to address. Windows was an organization that loved decisions. They loved having decision-making meetings. BillG and SteveB were always meeting with the team on important decisions. What could I possibly mean by decision-making and what should the team aspire to?

On to 086. The Memo (Part 2)

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