019. BillG the Manager
“Intelli…what?”–Bill Gates
The breadth of the Microsoft product line and the rapid turnover of core technologies all but precluded BillG from micro-managing the company in spite of the perceptions and lore around that topic. In less than 10 years the technology base of the business changed from the 8-bit BASIC era to the 16-bit MS-DOS era and to now the tail end of the 16-bit Windows era, on the verge of the Win32 decade. How did Bill manage this — where and how did he engage? This post introduces the topic and along with the next several posts we will explore some specific projects.
Please feel free to share this and subscribers, please join in the discussion.
Back to 018. Microsoft’s Two Bountiful Gardens
At 38, having grown Microsoft as CEO from the start, Bill was leading Microsoft at a global scale that in 1993 was comparable to an industrial-era CEO. Even the legendary Thomas Watson Jr., son of the IBM founder, did not lead IBM until his 40s. Microsoft could never have scaled the way it did had BillG managed via a centralized hub-and-spoke system, with everything bottlenecked through him. In many ways, this was BillG’s product leadership gift to Microsoft—a deeply empowered organization that also had deep product conversations at the top and across the whole organization.
This video from the early 1980’s is a great introduction to the breadth of Microsoft’s product offerings, even at a very early stage of the company. It also features some vintage BillG voiceover and early sales executive Vern Raburn. (Source: Microsoft videotape)
Bill honed a set of undocumented principles that defined interactions with product groups. The times of legendary BillG reviews characterized by hardcore challenges and even insults had become, mostly, a thing of the past excepting the occasional sentimental outburst. More generally, they were a collective memory of hyper-growth moments any start-up experiences, only before the modern era when such stories were more commonly understood.
Much later in 2006, when BillG announced his intent to transition from full time Microsoft and part time philanthropy to full time philanthropy, many reporters surprised him by asking how Microsoft would continue without his coordination of technical strategy and oversight. But even in the early ’90s, at the height of the deepest and most challenging technology strategy questions, he never devoted the bulk of his time to micromanaging product development. He spent a good deal of time engaged with products, but there were far too many at too many stages of development to micro-manage them. In many ways this was the opposite of the approach Steve Jobs took, even if both were known for their own forms of challenging interactions. The most obvious contrast between the two was the breadth of the product line and the different market touchpoints.
Having grown up through Development Tools and Languages, I was familiar with Microsoft’s product line, but only as TA did it become clear how comparatively broad Microsoft had so quickly become. The software world was thought of through a lens of major categories: operating systems, tools and languages, networking, and applications, roughly mirroring Microsoft’s org chart. The latter was thought of as word processing, spreadsheets, graphics, databases, as well as assorted smaller categories. It was easy to identify leaders in each of those areas—names that were tip of the tongue at the time and most of which are no longer in the PC software space (IBM, Borland, Novell, WordPerfect, Lotus, Aldus, Ashton Tate, and many more). The ah-ha moment in the early 1990s was the realization that no company on that list was competing in more than one category. Microsoft was hardly winning in every category. In fact, in most categories it was new entry, a distant second, or even third place, but the company was in every space. Bill was committed and patient. Microsoft was relentless. And Microsoft was focused on Windows.
BillG had fostered Microsoft with a grand vision to compete in every category of PC software, from some of the earliest days. With rare exceptions, no other company set out to do that. BillG led a deep technology strategy. It started with the operating system, supported by tools and languages, and then using those to build applications. This seemed simple enough. In fact, it is what IBM built for mainframes and DEC built for minicomputers.
There was a crucial difference. Microsoft did not build hardware and was not vertically integrated to reduce competition. Microsoft built an operating system on an openly architected PC (the same Intel-based architecture that came to power both Macintosh and Linux years later) and published APIs so that anyone could build tools and applications for the operating system—an open hardware platform and open operating system APIs. This approach simply addressed all the early challenges Microsoft itself faced trying to figure out how to build winning applications—it was so busy dealing with dozens of proprietary computing platforms, each with their own tools and APIs just different enough to make things difficult, but not so different as to be valuable. Bill saw the value in software and in openness at key points in the overall architecture. At the formation of the company, he and PaulA saw the immense and expansive value of software and, essentially, the liability that being in the hardware business carried. Building Microsoft’s software-only business on an open hardware platform where many players competed to drive prices down while maintaining compatibility with the operating system was one of the all-time great strategy choices. The idea of building hardware seemed like a sucker’s bet, with low margins, manufacturing, and inventory—the baggage of the physical world. While Microsoft would dabble in peripherals or hardware that could bootstrap new PC scenarios, building whole computers was a headache better left to others.
Expanding the impact of that breadth software strategy was BillG’s day-to-day operating model, not micromanaging the specifics of any given project. I am painting this with a broad brush, intentionally so. Part of the difference between the then dominant cultures of Systems and Apps was that during the MikeMap era (and arguably during the earlier JeffH era), Apps weaned itself from Bill’s intense and constant scrutiny whereas the Systems culture more clearly embraced that dynamic. That was largely true until PaulMa took a more hands-off (or walled-off) approach to the nurturing of the NT project.
In his May 1991 email, “Challenges and Strategy,” BillG set the company on the Windows strategy, clarifying the foundations for every product and group, solidifying what had been complex platform choices every team faced. Regardless of whether Bill was a savant when it came to the technical details of projects or he simply remembered everything each group sent or told him, he operated the company at a higher level of abstraction than reporters believed to be the case in 2008 when he ultimately reduced his full-time commitment to Microsoft.
I had a glimpse of this when our AFX team had our pivotal review. Later as TA I was there to connect the dots and amplify the Windows strategy. By and large the company was still wrapping itself around the details of what it really meant to embrace Windows, exclusively. That, and coping with the myriad of choices and decisions that come from the tension between aligning with a Windows strategy and having some control over your own destiny as a product. Which version of Windows? When is that shipping? Will the APIs our product needs be in Windows? Will those APIs work on older versions of Windows? What about Windows NT? On, which microprocessors? What about the other parts of Microsoft? The questions were endless. This was truly big company stuff—the strategy at a high level is one thing, but execution across a $600M (1994) research and development budget was another. The fascinating thing was how products so quickly scaled beyond what Bill personally experienced as a programmer, both in size and technology specifics. This was to be expected—by any measure the company was huge—but people and Bill himself still expected to interact on product details as though he was a member of the product team. I often found myself looking for ways to help Bill engage at that level, even if just for show.
In addition to the Windows strategy, with the late 1993 launch of Office 4, Microsoft also declared 1994 “Year of Office”. It was the biggest launch for Apps and represented a major pivot of the organization to the opportunity of selling a suite of products. This too was in the earliest days of a strategy, one that I would end up spending significant time on as TA and then later as a member of the team.
Just because Bill operated at a level of abstraction across products groups did not preclude product groups from engaging on what might seem like relatively small, non-technical matters. One of the more entertaining meetings I attended was preparing for the launch of Office 4, which was a worldwide event complete with a reporter given permission to shadow the team. A key differentiator would be how the user would experience “intelligence” in the product, so that it understood what was intended and how to achieve it in the new Office software. The development team built a series of features along the lines of what was termed “basic use” such as AutoCorrect in Word, AutoFilter in Excel tables, and a host of Wizards (guided step-by-step flows such as for creating charts), and more. To bring them together and actually communicate with the market and on retail packaging, the marketing team came up with an umbrella term. Pete Higgins (PeteH) came over to brief BillG on that choice in a small meeting in Bill’s office.
PeteH was by then the spiritual leader of the business side of Apps. He rose through the ranks of Excel and was clearly MikeMap’s lead executive. Pete was the kind of calm and in control leader that everyone enjoyed working for—he was at once clearly the boss, but also a member of the team. Pete was a native of the Seattle area, high school football star, and Stanford graduate. He was a new generation of Microsoft product executive, coming from the business and not the coding side. For me in my TA role, Pete was one of my biggest supporters and mentors and made connecting with Apps super easy.
Sitting at the little couch under the Intel chip poster, after going through the details of the launch, Pete said the proverbial “there’s one more thing.” Bill rocking in his chair shook his head, given that the meeting was mostly an uneventful recap of the upcoming press tour. Pete went on to explain the problem of communicating all the features and how Microsoft needed a term to market and describe them. Pete was dancing around this because he knew well enough that Bill was not a fan of “marketing”. Ever so delicately Pete said, “this is your chance…we want to go with this term but if you don’t like it…”
Pete then said, “IntelliSense. Microsoft Office introduces IntelliSense.”
Bill’s reply, “Intelli…what?”
Pete again tried to position the positioning, his instinct about resistance proving correct. “It is IntelliSense…it means that Office has built-in intelligence, and it understands what you need and how to do it.”
Bill still not warming up, went full pedantic, “what intelligence…is there a Prolog rules engine, a neural network, ….” He was also making the scrunched up surprised look that he does, which turns out (once you realize it) to also be a bit sarcastic. It meant he was warming up.
A few more times back and forth, and Pete just made Bill say IntelliSense in a sentence one more time, which he did with kind of a devilish smirk.
Done.
Looking back this all seems absurd. Consternation over a single phrase. Literally seeking approval to use it from the CEO of a billion-dollar company. All on the heels of what was no doubt months of preparation, including getting SteveB’s approval which was actually critical. Finally, the theater that Pete would pull the plug a few weeks before the tour. In some ways this was the Apps way of bringing decisions to Bill—it wasn’t really a choice and it had been broadly vetted and was buttoned-up. Any debate would probably be theater more than anything.
On average, there was one product-focused meeting on most days. Most teams saw Bill once or twice a year. NathanM saw Bill most every day or at least in most every technology context, present day or far out there. Most executives, like PaulMa, PeteH (leading Apps), and Susan Boeschen (SusanB leading consumer), saw Bill in product review contexts several times a month because each had many ongoing projects or, in the case of the big projects (like operating systems), many large components. Everyone was in constant contact over email. Bill was always forwarding emails across the company, adding relevant people from all levels of the organization to the CC line, and never backed off a good reply-all opportunity. Phone or in-person 1:1s were not the typical way of interacting across the product executive team. For the most part, work happened in groups or at least with an audience, with outcomes and flare-ups quickly disseminated by email. I found myself constantly on the move walking around campus from one building to the next to meet people in person, rarely was I in my office (a pattern that continued my entire career).
I was often asked to meet with teams before they met with Bill. They hoped for insight into how BillG might think about choices and decisions or even the presentation overall. I often disappointed teams in these pre-meetings since I was hardly a stand-in for Bill, and I was hardcore about leaving any such impression. Pre-meetings gave me a chance to better understand the issues the team was struggling with and to make sure those were brought forward in an objective and transparent manner. The fastest path to failure was to structure a conversation so Bill discovered an issue rather than having it revealed to him. To be fair, an equally fast path to failure was a first slide listing a slew of problems and issues in the hopes of inoculating the remainder of the meeting. In that case, I would caution teams that they were exposing themselves to the inevitable “How can this be so difficult?” comments. Getting this balance right was the essence of leading an effective meeting.
For most meetings, I wrote a summary meeting preview. Even though Bill said he did not want this, I could not help myself. While he was always effective, I felt that a little bit of specifics could go a long way in making the meeting more effective and less random. I could tell he had read my mail if he raised a point verbatim from my note, and frequently he would kick off the meeting doing so, never crediting me of course. In these, and all mails talking about other teams, I always tried to separate the facts of the meeting, the team’s analysis, and my own opinion. Bill was transparent with email and thought little of forwarding an entire thread. I learned the ramifications of that the hard way.
As an example of where I failed to follow my own rules about fact versus opinion, I totally offended Jim Allchin (JimAll), leading the Cairo project, on the role of a specific technology in distributed programming. Not only did Jim inform me that my opinions were wrong, but also that I stepped all over his own PhD dissertation as a leading expert. In hindsight, this was terrifying—Jim’s reply was brutal—but it proved a good early learning experience, so to speak.
While the product line was already broad, the expansion to entirely new areas was unstoppable. On most any product area, we were forming an opinion, beginning work, or already in the market. There was not a booth at a tradeshow, a focused conference, or a major company looking to partner that Microsoft was not already connected to or connecting with in some way. While Microsoft was in the earliest days of achieving a PC in every home (about 25 percent of US households in 1993) and on every desktop (about half of US workers in 1993), every day in this job was either furthering that or expanding beyond homes and desktops from data centers to handhelds to airplanes (the first in-flight PC-based system was an early partnership between Microsoft and an airline, including certification for Windows Server).1
Product meetings had no set format or structure and usually reflected the culture of the organization. This might be a surprise to some as many CEOs (or perhaps their staff!) might have imposed some more rigor on meetings. Microsoft had two bountiful gardens, but there were micro-cultures throughout out the company. While one group did slick and well-rehearsed presentations, another might present research-heavy deep dives. Bill often pushed a team outside its comfort zone, deliberately pushing the team to discuss places they were less prepared, or even less interested. It was a technique he employed. He once said to me, “Why spend all the time with the Windows team talking about architecture, if that was their predisposition anyway?” This was also a strategy to level the playing field—talking about architecture to Windows or ease of use to Excel was too lopsided and Bill was disadvantaged.
The reality of BillG Reviews never lived up to lore.
Most meetings progressed without incident—meaning without yelling. Sometimes, though, there were comments such as “That was the stupidest thing I ever heard” or “That is brain-dead.” The worst was “That’s trivial . . . let me show you.” Those were all the clichés that teams anticipated but then wore as a badge of honor. They happened with far less frequency compared to how much they were talked about. Even over the short period of time I worked as TA, Bill became more intentional in his use of meeting dynamics. Still, the first seconds of a meeting remained a bit of a mood thermometer, pity those for whom it was clearly a bad day.
When meetings ended up “bad” it was always because the team was poorly prepared, or they came to talk about the project in a way that diverged from expectations. There were typical capital offenses in the meeting, such as failing to understand a product strategy of competitors or downplaying a competitor’s potential. Worst was coming across as though a product was making mostly tactical decisions driven by schedule or failing to understand the architecture of the product relative to the evolving platform and related teams across Microsoft. PivotTables were just making their way across most teams, so many were still making the common errors of using static charts and graphs that always seemed to have the data oriented or filtered in the least useful way. Those moments always held potential for a lively discussion.
Part of my role was to reduce the potential for such liveliness ahead of time. I tried to alert teams about potential issues without acting as a surrogate for Bill, and to make sure meetings did not save the difficult or bad news for the end. I was also there to throw myself on the grenade, so to speak, and get meetings back on track by helping the team through a tough moment—usually by restating or interpreting what they were saying or by redirecting the topic at hand to a follow-up discussion.
By far the biggest strategic error one could make was knowingly duplicating code outside core expertise, and then compounding that by attempting to explain why in this particular case it is justified. Microsoft Publisher was a new product in the desktop publishing category. It was being built by the Consumer Division under the leadership of Melinda French (MelindaF). The product aimed for the small business and non-professional market, compared to the incumbent Aldus PageMaker. It differentiated itself with ease-of-use features, pioneering Wizards and other user interface innovations. But it also produced printed pages that looked a lot like what one should be able to create with Microsoft Word. This overlap was the source of endless consternation—why can’t they share code, why can’t Word do all these features, and then ultimately why does Publisher even exist. Yet, customers loved it. At one point, a meeting went down a rabbit hole over bullets and numbering and how Publisher was basically writing all the same code Word was and wasting everyone’s resources. There was little actionable in this kind of rant, but it did establish the norm of being called out for redundancy and the need to be prepared to cope with the feedback.
Bill maintained a deep commitment to evaluating a portfolio of efforts, and even within a single product he believed in the portfolio approach of features—not every product nor every feature was a winner or a breakthrough, but on the whole something needed to be working. As much as Bill might give a group a difficult time (as happened with Visual C++), he knew there was always more to the product and more products to the company. It was not just that Bill was building a product portfolio for Microsoft, he was managing the teams as a portfolio of efforts. This portfolio approach created a resiliency in the company—resilient to the unpredictable nature of technology bets and to the ability of the people on the team to execute. Not everything went as planned nor did every planned bet ultimately make sense.
Whether deliberate or not, BillG had three axes that created a constant state of balance, of push and pull, across the hundred teams creating software. Bill’s approach of constantly balancing the tension between innovation and shipping, expanding the portfolio while maintaining coherency, and the injection of new ideas while also executing on existing work proved to be the most interesting “management” lesson. The next three sections are examples of each of these dimensions.
On to 020. Innovation versus Shipping: The Cairo Project
https://nces.ed.gov/programs/digest/d08/tables/dt08_432.asp
There are two important elements to Bill's management style. He was deeply interested in how things worked in the products, and set the tone that managers needed to know how things worked. That was a huge strength of Microsoft's management team (and a weakness when people lacked the human aspects of managing) and critical to Microsoft being able to do all of the things it did. The company lost this to a degree along the turn of the century and it resulted in several project failures.
Bill also, as Steven wrote, would purposely drive conversations and challenge people in order to find the weak spots. He was sometimes brutal on a personal level when doing so. However, these discussions were often valuable. Bill did not have to know the answer. These discussions often drove substantial follow up that developed valuable insights. In addition he was good about having the discussions not break the delegation barrier. He wasn't telling people what to do, he was telling people he didn't think they had thought something through. Sometimes that was a painful discussion. Sometimes that was a waste of time. But also sometimes it was super valuable (Bill term) and really helped those of us working on the products.
These are a joy to read. Thank you!
One (obvious) observation from my time at Microsoft is that there was always a strong, top-down push for early (some might say premature ...) dependencies and code re-use. One of many problems with Longhorn.
Interestingly, at Facebook there was never any top-down push for code re-use. Over nearly a decade, I rarely saw a classic Microsoft-style architecture diagram in an exec review (the only exception was new Microsoft hires who were still adapting). No exec ever asked if a team was using the latest-and-greatest internal framework.
But – in my opinion – there was far less code duplication at Facebook than at Microsoft. Code unification/clean-up was a constant, bottoms-up effort from various teams (e.g., the Product Infrastructure team). Projects like GraphQL, React, React Native, etc. were entirely organic, bottoms-up efforts.
I've never been able to fully explain the difference. There was clearly a confluence of factors:
- A single, always up-to-date codebase (easier to reuse code)
- A culture that primarily optimized for speed of execution
- Daily releases (vs. multi-year releases with discrete RTMs)
- A culture that celebrated engineers improving core abstractions
- Etc.
But I can't help but wonder to what extent Bill's constant pushing on this issue actually worsened it, e.g.:
- Bill would detect some area of duplication
- He would push some team to create a framework to unify the thing
- He would push other teams to take a premature dependency on that framework
- Dependent teams would be burned and learn to avoid future dependencies at all costs (real artists ship)
- The cycle would repeat
Certainly one of the unspoken lessons I learned at Microsoft was that you were crazy to take a dependency on any piece of code that hadn't shipped yet.
It feels like a cautionary tale in the exertion of power – the harder you push, the worse you make it.