018. Microsoft’s Two Bountiful Gardens

Back to 017. Eyes On Competition, Architecture, and Left Field

One of the first things I did as Technical Assistant was to set up time with each of the leaders of the Office of the President and key executives to see what they could tell me that would help me to work with Bill. Mike Maples offered me a great and lifelong lesson in being in a supporting role while also explaining in his unique way the culture that was at the root of Microsoft—the culture across Apps and Systems where I would spend my whole career.

I had to figure out how to have a high bandwidth (a BillG word) relationship with BillG and the key execs in his orbit, known as the Office of the President created in early 1992. I felt I should reach out to leaders and meet with them to see if they had any idea how to do this job. Microsoft was organized into a triumvirate or troika of executives (something about using a Russian word just after the fall of the Berlin wall seemed exciting to the press): Steve Ballmer (SteveB) leading Worldwide Sales Support Group (WWSSG), MikeMap leading the Worldwide Products Group (WWPG), and Frank Gaudette (FrankGa) leading all the financial and administrative functions. Collectively, this was the Office of the President, which Microsoft promptly turned into the acronym BOOP for Bill and the Office of the President.

The BOOP filled a gap left by the retirement of Jon Shirley (JonS) who, from 1983, served as president and chief operating officer through 1991. JonS brought a level of scale and discipline to Microsoft’s execution that established the solid foundation upon which everything was subsequently built. Jon remained on the board through most of my time at the company. I, and many others, benefited enormously from his wisdom. After Jon retired, Michael Hallman joined to fill Jon’s role. His tenure was only two years and was not a match from the early days. The reports at the time focused on that failing and to some degree viewed the new organization as Microsoft giving up on hiring external executives. As it would turn out, that was probably true.

It was no surprise, but MikeMap reached out even before I had a chance to reach out to him. He was like that. Walking over to his office I was running through the scope of his job in my head.

As I became Technical Assistant, TA, MikeMap was almost a year into managing all product groups and organized them into divisions: Systems, Desktop Applications, Database and Development Tools, Consumer Software Division, and Workgroup Applications. This was an enormous job by Microsoft standards, but relative to Mike’s previous employer IBM ($60 billion in sales, 250,000 employees in 1993) this probably didn’t seem so huge. It was the first time all product development was under one executive who was not BillG. That was actually huge.

WWPG was a sprawling organization. Fiscal 1993, which was only half over at this point, brought in more than $3.75 billion in product revenue, with more than half coming from Applications ($2.17 billion) and about 34 percent from Systems ($1.27 billion). The remainder from hardware and consumer. It had 14,000 employees. While Microsoft did not break out the profitability of each group, the reality was (and for years remained) that the operating systems were more profitable because of the OEM model, the original equipment manufacturers or PC makers. Few inside or outside would realize the revenue size of the applications business relative to MS-DOS and Windows, a theme that would be consistent for another 20 years. By most every account and every action, the operating systems group came first, and applications were the gravy. BillG understood the brilliance of developing both and building the network effect and ecosystem, but emotionally Apps played backup to Systems regardless of revenue, perhaps because of the profit.

Taken all together, this was MikeMap’s WWPG world. The Research & Development budget was $470 million that year, or more than 4,000 people. He also had the marketing for all the WWPG, though there was a significant shift in budget, ownership, and accountability for marketing with SteveB leading sales—distributing much of the spend and accountability to country managers.

Mike brought with him a wealth of experience from IBM. Many believed that wealth of experience demonstrated what we should not be doing or copying. This was decidedly true for the Systems teams who had forged a beneficial, albeit dysfunctional, relationship with IBM over the past decade, most recently with respect to OS/2, which by this time was circling the drain along with the IBM-Microsoft Joint Development Agreement. In practice, MikeMap’s experience in managing organizations at massive scale was not only relevant but essential for Microsoft at this point. He had seen it all when it came to org dynamics and dysfunction. Not only was he in the right place at a much-needed time, but he was exactly the right person.

Mike didn’t fear change. In his first year, he restructured his Apps division from a largely functional organization (for example, one large team of engineers and one large team of marketing) to a group of independent business units. The reason was clear—these were independent businesses. They had distinct customers, with distinct product schedules, and distinct competitive dynamics in the marketplace. There were some shared resources for localization and tooling, but they essentially operated independently.

Leading up to this change in 1989, MikeMap created a brilliant vision presentation, outlining at a deep technical level a vision for the evolution of Office. This was simply a presentation, but the slides and notes remained relevant for years and many, me included, were greatly influenced by it. As a seasoned exec, he knew the necessity and value of repetition, so in many ways this became his stump speech for Apps as he created the new organizational groups. As a result, everyone in Apps knew the vision and reasoning behind the organization Mike put in place and the future direction of products.

The names of these groups are seared into my memory as they became the lingua franca when talking about Apps for many years. Each business unit (BU) represented one product family (Mac and Windows plus some secondary products): Analysis or Excel (ABU), Office, not what might be thought of as Office down the road but Word and the nascent email business (OBU), Graphics or PowerPoint (GBU), Entry or Works (EBU), and the new Data Access or database (DABU). Conversations were littered with the use of ABU, OBU, DABU, EBU to the point of sounding like a language unto itself, or maybe a Beatles song (aboo, ohboo, daboo, eeboo). The leaders of these groups, known as a business unit manager (BUM), were ultimately the key product leaders in Apps and were responsible for the product in every aspect. Mike chose these leaders with care, making sure they came from a variety of backgrounds, not only engineering or marketing.

To my surprise, one thing Mike knew well was my TA job. In fact, he seemed to have more insight than even BillG or NatalieY about what the job could be. IBM had a long history of the TA role going way back. Mike offered me a whole framework for thinking about the role that was not unlike Rumsfeld’s Rules, the famous Washington DC insider memo from the former Secretary of Defense. Mike seemed acutely aware of the risks that could befall me as TA, of which I had no clue. In short order he offered some crisp guidelines that I wrote down (I was always taking notes) and stuck to religiously, even expanded upon and passed to future TAs:

* You are not BillG and don’t pretend to be. People will try to get you to pretend to be BillG or channel him, which you can’t do.

* Avoid talking about what BillG wants or what BillG would like to see. (In other words, I should avoid speaking as though I know that.)

* Remember that people don’t care what you think; they care what BillG thinks. Your opinion isn’t the one people are after. They might act like they care what you think, but don’t be confused.

* Bring an outside perspective rather than more inside baseball. (Mike suggested I could be BillG’s eyes at events and meetings he could not attend, like conferences.)

* Don’t waste BillG’s time and find ways to help him to be more efficient.

Specifically dealing with meetings and reviews, Mike said something that made me think: He said that at review meetings, people are hoping to be and do their best, but in reality they are often at their worst. Even after my first few meetings this was already clear, but it was also awful because for most people a meeting with BillG was a career moment (at least they believed that to be the case) and something that might happen once in a year at most. The smartest, most thoughtful, and hardest working people freeze up or talk gibberish at meetings. The pressure to perform was real. Nothing makes one more acutely aware of the theater of meetings and management than sitting and observing the meetings of others (conversely, not having to be on the hook at meetings also comes with a decided lack of empathy).

Mike’s advice was to get to know people so I could serve as a bridge or lifesaver in meetings by restating or even redirecting an interaction to get to a more productive spot. Nothing would become more important to me over the years than thinking about executive meetings this way. It became almost second nature to me to jump on bad moments and try to diffuse them or pull people out of those horrid tailspins that can happen in reviews.

He also said his experience with BillG was that he loved email and so maybe that would be the best thing to do. Mike was varsity at email but never warmed to tiny laptop keyboards, even on his beloved ThinkPad. This was concrete and actionable for me.

No meeting with MikeMap was complete without a story, allegory, or colorful metaphor, and this introduction to WWPG would be no exception. I asked him for some guidance on working with the Windows teams or understanding the culture a bit, having briefly mentioned my experience with NT (when I met with DaveC to explain why the NT APIs were broken). Windows was clearly front and center for Bill and other than being at the receiving end, so to speak, in Tools I was short on experience and insights.

In a colorful manner that only MikeMap would choose and doing my best to capture, he said:

Microsoft is like a home with two amazing gardens; one is the OS and one is Apps. Each is a beautiful garden, a very successful garden, in its own right. One of these gardens is maintained by people who are always in the dirt, with tools flying around, dirt everywhere, scraped knees and cut fingers, and in general just chaotic. But you look over to them when they are done and there is a nice garden. The other garden, well, you just look and there are nice flowers, and they are just tended to calmly by people. The first garden is the OS. The second is Apps.

His view, which I ascribed to, was that the origin of each business contributed to this differing culture. To build an OS required being way ahead of yourself—the need for getting OEMs (massive giant companies) to make bets, device makers to build drivers, firmware, and more all require a level of evangelism that forces a level of aggressiveness that is akin to swinging tools around quite a bit. Building an operating system and computer while also creating an ecosystem of partnerships is a massive bootstrap problem. At the start, there’s no computer and no operating system and everyone just wants to wait and see what happens—no one wants to be first and risk the opportunity costs. While individuals used an operating system, the paying customers were PC makers and to a considerable extent the wide array of independent hardware and software makers that were critical to fostering an ecosystem. Successfully bootstrapping created MS-DOS and later Windows, and that first garden.

Apps, which was making huge amounts of money and just recently closed in on the scale of Lotus and WordPerfect, had to start with individual customers and win them over, almost one at a time. This end-user appeal—specifically when it meant getting on a plane and visiting banks on Wall Street to woo them to Excel or government lawyers to get them to switch from WordPerfect—required a much more subtle approach. The culture of Apps was one of building, learning, and refining. It was often self-described as almost Japanese-like, which at the time was a high form of praise given the incredible rise of Japan’s electronics and manufacturing industries. In the Apps market, it wasn’t the absence of products that drove the culture, but the presence of so many alternatives. While people were using Word and Excel for the workplace, the paying customer was an individual or small department that was making a choice about what software to use and winning over these influential end-users were critical to gaining early momentum. Successfully winning over customers created Excel and Word, first on the Mac and then on Windows, and the second garden.

Neither culture was wrong or right in isolation, but in the context of the need for the business to be successful each culture made sense. I would spend the next two decades bouncing between each of these cultures trying to bridge them, work with them, and even transform them. It is why when people believed Microsoft was made of up fiefdoms or organizations out to get each other that I take strong objection—each culture had problems, self-realized shortcomings, or systematic issues, but each was what was needed and what was right at the time for what needed to get done. Conversely, those who saw Microsoft as one Borg-like entity were far removed from the realities of what it was like to make products inside the company.

This analogy and description fit my reality. It was vastly different than the politics or power portrayed over the years. Cultures evolve, but to experience the two gardens was to experience teams that were the culture of the work that needed to be done and not politics or pettiness.

While there were two cultures and Apps was making a lot of money, there were no doubts about the “high order bit” (a BillG expression), and that was Systems (now slowly becoming known as Platforms, while Apps was still a few years from becoming known as Office given the Office product was only about 15% of sales in 1993). The company, and BillG himself, saw everything from the perspective of the Windows product and ecosystem. It was the big bet, and it was the primary engine. The success of Windows would enable the success of Apps, from Microsoft and third parties, and the growth of many companies making PCs. Seeing the choice of software and PCs would make Windows more attractive and further attract customers, developers, and hardware makers.

Culturally, Systems dominated. The culture of Systems was the culture of Microsoft and in many ways the culture of BillG himself. The outside world was beginning to see all of this. Internally, there was most decidedly a hierarchy, with Systems at the top and by and large the NT team, even though the product had not yet shipped, at the top of the top in terms of perceived product technical leadership.

The Apps teams, as strong as they were and as market leading as they were, did not seem to have that technical glow that the Systems always had, business results notwithstanding. It was not unusual for topics to come up where a Systems person was asked (or might volunteer) to opine about the best way to solve an Apps issue. It might be extreme, but the general view could be distilled down to the belief that Systems was truly difficult engineering work and Apps were mostly trivial. Such characterizations would often surface at review meetings where Systems would be proposing or discussing a new operating system feature that would replace something in Word or Excel with a few OS API calls. As a builder of a framework (and on a team) that straddled Systems and Apps, I found myself in the middle of many of these discussions. I became somewhat of a shuttle diplomat explaining to Apps why the OS felt it could add value by building an API (and not remove a competitive advantage) and describing to Systems the complexity of the implementation in the apps should they hope to replace code. From toolbars to standard dialog boxes to database connectivity and later HTML and networking, as it turned out both Apps and Systems were doing a lot of the same work, only differently. And BillG hated redundancy.

Whether Systems had a superiority complex or Apps had an inferiority complex, and whether either was appropriate, would be a matter of perspective. But when it came to resolving differences, there were no doubts where the definitive opinion would come from.

I continued my Meet the BOOP and executives tour, talking to Paul Maritz (PaulMa), who with the creation of WWPG was managing the Windows product line.

Previously at Intel, Paul had enough experience with new projects at companies to know it was important to allow something time to reach maturity rather than subject it to an internal dialog too soon. NT had been nurtured essentially off on the side, which had worked well for Windows 3.0 previously—meaning it was making progress without a great deal of meddling from executives or other product groups. NT was in the final, intense stretches of what ultimately became a four-year project from inception to shipping the first release. NT was originally begun to compete with Unix as a distinct high-end offering from Microsoft. The major change that was announced at the 1992 PDC a few months earlier was how the 32-bit Windows API would be scalable from the low end with Chicago to the highest end with Windows NT—this was called Windows 32, usually shortened to Win32.

Since the release of Windows 3.0, a major update was in the works and about to release. Windows 3.1 would add support that would greatly improve the ability to run several programs at once and support a lot of memory (very helpful for VC++!) by running only in protected mode. Importantly, a significant update was also planned that would add workgroup networking. The “workgroup” buzzword, pioneered by the billion-dollar revenue Lotus Corporation, had infected Windows as well. In fact, it was in large part the concerns over Lotus that led to releasing an updated SKU of Windows called Windows for Workgroups.

Whereas the Apps division was organized around business units that had an easy mapping from boxes on a retail shelf to top levels in the organization, the Platforms organization was mostly a cluster of technology focused teams, often overlapping to some degree. There were many projects spinning at different velocities with competing interests between different product release timelines. The org structure was not inherently a challenge, but the high variance in actual versus planned ship dates was a challenge. Again, this relates to the challenges of bootstrapping a wide range of ecosystem partners and the constant flow of new technologies and industry standards that might make it into whatever release of the operating system might be on the horizon.

Paul suggested that I could help to do my part to assist in keeping BillG informed enough to minimize random inbound commentary. I was beginning to get a sense of the different relationship BillG had with Systems as compared to his relationship with Apps. While Bill, perhaps through MikeMap, had already put some distance between himself and Apps, with Systems they were trying to figure out how to best channel his efforts and avoid being randomized.

I spoke with Nathan Myhrvold (NathanM) who had the most fluid and continuous contact with BillG. Microsoft Research (MSR) was also only a few months old and getting off the ground, launching with a detailed memo explaining the philosophy and structure of MSR. It was exciting to BillG. MSR became an increasingly important part of Microsoft and my role as TA given how much BillG was personally working on the new division. Nathan proposed MSR to BillG in 1991, and with much fanfare MSR was created with the hiring of significant research talent in Speech and Natural Language from IBM. Later in 1992, Rick Rashid (Rashid) joined from Carnegie Mellon University in a major statement of the importance that MSR would bring. Nathan’s memo on MSR aimed to structure MSR to avoid the most common failures, particularly around technology transfer from lab to product group, that had come to define computer science research (notably, the failure of Xerox to capitalize on graphical interface and more).

Microsoft had two bountiful gardens, and BillG’s goal with MSR was to create a third. There was little doubt as MSR grew where Bill believed the highest IQ people in the company were. He was well-versed in the history of all the corporate labs and in how opportunities were missed or squandered and was determined to do something different and better.

After meeting with many senior people, I became obsessed with not wasting BillG’s time. Though, I got off to a slow start trying to figure out how to “add value” without asking. I began what would become our tradition of many late-night email threads about various topics. Sometimes BillG would kick off a thread asking about a product or technology. Other times I would share something I learned and that would kick off another thread. We had many threads going in parallel.

Understanding the products and technologies was not the difficult part of the job. Figuring out the realities of management was the challenge. BillG never really talked about management (or process or schedules or customers). He talked about products and technology.

I’d often ask myself if he was even managing or if he was, was he doing so consciously?

On to 019. BillG the Manager

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