017. Eyes On Competition, Architecture, and Whitespace
Apple Macintosh had one extremely good text capability, why couldn’t Windows? –Bill Gates
Back to 016. Filling the Void Left By IBM
I’m still just finding my footing in the role of technical assistant. My first weeks happen to be a flurry of meetings with various product groups. I quickly try to come up with a framework for how Bill works and how he is approaching meetings. I still haven’t talked one on one with him outside of just before meetings, so these are my observations that await validation.
Please don’t hesitate to join in the discussion or to share this post with friends. We’re starting to get deep into the management and strategy lessons I’m lucky enough to accumulate (to put to work soon enough!).
Unsure of exactly how to interact with BillG or what to do at all, I got some insight about a week after the offsite as I was summoned to his office. Holding a Microsoft supplied steno pad like I was going to take shorthand, I headed through the glass door to Bill’s office, where we had our first discussion of expectations and process. He suggested I look at the schedule and be sure to attend review meetings, which sounded easy enough. He told me he didn’t need notes summarizing the meetings (as I had sent him a few times previously) but he told me that I should be on the lookout for any interesting follow-up items. He also did not seem interested in being briefed before the meeting, which seemed fine to me, but later in life I would come to appreciate that this was unique to BillG because he was able to dive into any topic. Rather than briefs, I would develop a process of sending notes on what I had learned about the broader concepts prior to meetings.
Bill then rattled off a list of topics that were top of mind: text strategy and code reuse, forms, indexing, image editing, multimedia authoring, Microsoft research, Lotus Notes, architecture, and more. Bill seemed to think in two dimensions.
First, lists. Everything was always a list. The list of technologies was consistent over time and rarely did something fall off the list. Instead, something was either making progress or something was in a bad state. Usually these technology lists had a single team in mind that owned (or should own) each item or worse there were several teams with competing and suboptimal implementations. The lists were two columns, the problem area in one and the people or teams in the other.
Second, calendars. Everything was always viewed through a time dimension. Bill would routinely sketch out a calendar with a black felt tip on an ever-present legal pad. This would map out the next weeks of meetings or next months of milestones, relative to that list of technologies or perhaps speeches or travel. While Bill was always keenly aware of his time, he often ran late or over in meetings. That would change later in life. We did not have fancy Microsoft Exchange schedules back then with delegate access or anything. In fact, there was no personal Schedule+ calendar for BillG (the Microsoft product we used at the time). Everything was kept in JulieG’s Schedule+ to avoid moving things around or removing appointments “accidently”. The real source of truth was an old fashioned large-format appointment calendar where appointments were written in pencil and the pages archived at the end of the week. If I ever really needed to know what was going on, that calendar was where I looked.
It quickly became clear that redundancy and inefficiency in code and the use of scarce developer resources was top of mind, all the time. Bill was worried about redundancy across groups and, while this was inefficient in headcount, more worrisome was the inefficiency in code and thus memory. Everything always came back to memory because Bill squeezed BASIC into 4K (over the weekend as he would remind people, still). Redundancy also created a suboptimal user experience because no single group devoted the resources to do an excellent job on one code base and every group just built a random (BillG word) subset that was just enough for them. Something like text editing drove him crazy. Everywhere in Windows apps people were building little mini text editors with varying levels of capability. Some supported basic formatting like bold and italics. Some others might support Japanese characters but not right-to-left languages. Others might support editing but did not have good support for copy/paste across apps, and so on.
Several of the topics on that list were places where this inefficiency existed, and it was super annoying (BillG phrase) that no group (or Windows) was solving this problem. Which meant that we needed a group that was hardcore (BillG word) focused on text editing. Apple Macintosh had one extremely good text capability, why couldn’t Windows? (Note to reader, Office eventually solved this with RichEdit leveraging the incredible typography and typing from Word, but it ended up being too late for the internet and so now we’re all using the editing and rendering capabilities of HTML, which are still trying to catch up.) Text editing, forms, graphics, storage, and more were all places where from Bill’s vantage point most everyone was building incomplete subsets of what should be much bolder and more reusable offerings from Microsoft, and Windows.
A constant tension existed between groups trying to keep up with cross-group synergy (loved that word) while being given the latitude to determine their own destiny and a strong desire for a highly leveraged, efficient, and centrally executed plan. BillG meetings were a place where the downsides of empowered execution would constantly bump up against the perceived benefits of coordinated and centralized strategy. There were always more ideas on ways to leverage grand architectural plans than there were practical ways to implement them.
What I came to realize over time was that BillG was not using these meetings to confirm or affirm the direction of a team but rather to push them to do more or to do better. While teams would view a successful meeting as one that did not get redirected, there was rarely praise that matched the confrontation. Unlike leadership and CEO books, or what might get taught in business school, BillG was not asking to look at metrics or hear a presentation on the validation of strategic goals. He also was not there to provide emotional support to the team, at least not yet. He had three tools and he used them: competition, architecture, and (what always seemed to be) some wild card or “whitespace”.
First, how did the product shape up against the main competitor? Every product had a main competitor and BillG is a very (very) competitive person. One of the oldest traditions at the company was the Microgames, an annual summer party up at Hood Canal where teams would compete in a summer camp sort of environment. It was not unheard of for BillG to seek, let’s just say, an advantage for himself. He also assumed competitors would flawlessly execute, and any attempt by a team to claim otherwise was a tactical error in the meeting.
Regardless of having a plan to compete or not, failing to know the competition inside and out meant a meeting was going to go poorly. BillG was a voracious reader of all the trade press and product reviews, and when he wanted to make a point, he would take them at face value and not let groups debunk the claims or test results. Every weekend he read The Economist, which was sent to his house via some sort of VIP subscription. Monday he would devour PC Week and InfoWorld, every day he read the Wall Street Journal and the New York Times, and every month he read BYTE and PC Magazine which at that time were the size of the fall Vogue. Product groups that would attempt to point out that a given review gave a competitor too much credit or were too harsh on Microsoft would find themselves in a debate as though they were talking to the reviewer or an executive from the competing company.
In meetings, Bill would often be provocative to the point of over-stating the strength or capabilities of a competitive product. He would exaggerate the performance of a competitor or even claim a product was faster or easier to use, sometimes without personal knowledge. After a while it became easy to tell he was doing that because I knew if he had used a product but also because he had a bit of a tell in the meetings, often looking at me as if to seek validation. I made it a point of being able to amplify these points from personal experience of some kind. Unless the meeting was not going well, and then I would use up some of my own credibility or competitive experience to bring the meeting back into focus and off the defensive.
Second, and this was a moving target, but how architecturally sound was the product? Was there strategic code reuse? Where did the product make use of native Windows features versus rolling its own implementations? Where did a product have a proprietary advantage? How was the product extensible by developers or customizable by end-users? Was the product redundant at a deep technical level or overlap with another product?
Third, assuming that a product had answers or at least credible discussions for the previous two, BillG always maintained the option to bring up something that seemed from out of left field—but in practice this was his way of making the team think about its product in an entirely different context. The most common way of doing this was to point a product group at another team, usually somewhere in Windows or Microsoft Research, that was doing something BillG viewed as more innovative or had a broader vision or could be connected in a way that the whole was greater than the parts.
Bill thought a great deal about “whitespace”, or new opportunities that were important or critical and fell in between different teams rather than completely within a team. Perhaps it was dealing with IBM all those years, Bill clearly understood that the best way to compete with any company is to build products that fall between two teams (or two executives). In a big company, both teams will usually fight to claim a competitor is in their sights, but rarely will they execute directly. Then when the company is losing the organizations will turn around and say they never intended to compete directly. Some companies were deliberate in hedging bets and having multiple competitors in the labs, so to speak. To Bill this was inefficient and wasteful. He wanted the best group owning competing, which sounded great. At the same time, however, he wanted all the necessary other groups to contribute to a new competitive offering. That, as we will see, was almost always where Microsoft ended up under-performing relative to a focused competitor with only a single organization.
The reason the discussions about unseen opportunities were always the most difficult in meetings was that a team was working on the area, or more likely that some team was doing a little bit of the area, but they did not have a big enough view of the opportunity or they were thinking too tactically to really get ahead. Most of the frustration that would emerge from product meetings would be rooted in the misalignment between what appeared strategic to BillG but meant an overwhelming amount of work and collaboration to a product team for a relatively minor win, and on the unacceptable time scale the work would take place.
I quickly found myself getting into the rhythm of these meetings. As one might expect, not being on the receiving end was far more enjoyable than having to put in tens of hours of preparation and showing up hoping for the best. I essentially bucketed groups into three categories.
There were groups that were executing and had a good story. Fortunately, these were the big groups. It wasn’t like the meetings were always happy time, but by and large the meetings would go as expected. Whether it was the NT team that would show up with performance numbers needing work, or the Office team needing to be easier to use and reduce overlap, the conversations often were tense but not crazy. Whether the group was executing or not looked different in these early days—everything was late so a group that was executing well was just simply late, but not out of control. Most of the time the dates were not even the subject of the meeting and for many projects it could be said it wasn’t even clear what the target dates meant or how reliable any dates were. Generally speaking, just getting to the next milestone (a beta test usually) was all that mattered. As much as it hurts to say, these groups did not need Bill’s help. That was difficult to admit. It was, however, an incredible achievement that the most important products (still very early in their lifecycle) were already staffed with leaders and executing in an autonomous way.
Second there were groups that were executing but their story was not compelling or did not appear to be achieving any sort of escape velocity to speak. Many groups were capable of “shipping” but the problem was that shipping was not going to add up to much in terms of a competitive win or substantial revenue. These meetings in many ways were difficult. Many were products that were started (often by Bill personally) with the best intentions but somehow ended up being less interesting as they closed in on becoming a product. Perhaps the area of “consumer” software meetings, rooted in the innovative work of CD-ROM titles was the most like this. At one point there were dozens of new “titles” for the holiday seasons each with wonderfully rich photographs and text, unlike anything ever seen on a PC, covering topics such as the pioneering Encarta encyclopedia, Dogs, Cats, Musical Instruments, Isaac Asimov's The Ultimate Robot, and the much-loved Cinemania (like today’s IMDB). The challenge with these groups was that the meetings would inevitably focus on that framework of competition, architecture, and whitespace. Those are where Bill was most effective, but not really where the problems were with the efforts.
Third, the groups that were not executing but had wonderful stories to tell. This, as it would turn out, was where I would spend the most of my time and where Bill was spending most of his time. The challenge for me was how to be constructive—how to encourage more execution while not being the one to take away from or deflate the story. There were so many of these projects that I might even say that the early 1990’s were a time when Microsoft had far more great stories than it had execution. In many ways this was the expansive vision Bill had for the company with all cylinders firing.
The next year or so I would spend trying to do my part to help Bill help more teams get from their fantastic stories and lack of execution to a bit more focus on execution. Perhaps what I ended up learning more than anything, was just how much the initial seeding and DNA of a group end up defining the outcome.
I was still getting my rhythm with Bill and earning his trust. I had to figure out how to have a high bandwidth relationship with him and wasn’t there yet. I needed to ramp up more quickly as there were some of the biggest projects in company history underway and these would prove to be the foundation for everything to come over the next decades.
Re Billg’s use of lists, I was taught by Paulma to constantly maintain two similar lists — biggest business/technical problems stack ranked, and strongest team members stack ranked. And if you didn’t have good alignment between your best people and your biggest problems, you probably needed to rethink things. Did billg use the lists the same way?
I love this line: "Bill seemed to think in two dimensions."
This insight: "Perhaps what I ended up learning more than anything, was just how much the initial seeding and DNA of a group end up defining the outcome."
And this acknowledgement: "As much as it hurts to say, these groups did not need Bill’s help. That is difficult to say."