Hardcore Software by Steven Sinofsky (Audio Edition)

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

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.

On to 018. Microsoft’s Two Bountiful Gardens

One of the first things I did as Technical Assistant (TA) in early 1993 was attend something called the “Management Conference” which was a new offsite created for emerging people in the company. This was the second or third time it had been run.

This post is free but please tell your friends and subscribe. We’re over 5,000 now and growing every day!

Back to 015. Every Group Is Screwed Up

Getting settled in my new office was pretty much like each of my previous moves. Unpacked my boxes, placed my developer-issued books on my tall bookshelf, and began to setup my new Compaq LTE laptop. This was my first corporate issued laptop.

Trying to figure out what I was supposed to do was a bit weird. It wasn’t like I could check in with my manager, or should I?

BillG was generally free from ceremony and rather spartan in executive presence, including minimal staff. He had JulieG, who handled scheduling, travel (commercial and in coach), direct inbound calls, and everything else (literally). His small reception area had the same oak receiving area that was in the front of every building and it was staffed by an administrative assistant, Debbie Stanley (DebS). She handled all the calls from the switchboard (calls to 206-882-8080 requesting, “Connect me with Bill Gates, please”), as well as all the inbound postal mail and packages (which would eventually get screened, but only later in my tenure). And then there was me. My title was technical assistant, but it became apparent I was really assistant for everything else. I kept his PCs running (at home and the office), mail connected, slides made, and anything else that kept us efficient, especially when we were on the road and it was just the two of us. Bill had not grown a dedicated staff (nor had any executives in the company really) and instead leaned heavily on the team he was working with for any event, sales call, or other external work. If he was giving a speech about Windows, for example, the Windows marketing team and DRG (Developer Relations Group) would make the slides and iterate with him in a meeting before leaving for the event. I’d end up in most of these meetings.

No sooner had I moved into my office than I was off to Semiahmoo, a golf resort near the Canadian border, for the Management Conference. Semiahmoo had become the site of all the official executive offsites, though few of us knew anything about golf (Bill tried, PeteH was really good!), especially me. This was my first time at a fancy offsite with executives and my first opportunity to spend time with about 35 people in jobs I had no familiarity with (sales, subsidiaries, corporate functions). I was told I was invited to attend because of my work on C++ but now attending as TA had the effect of setting me apart, preparing me for how people would react differently to me.

The format of the offsite was straightforward and, as I learned, the canonical Microsoft offsite format. Upon arrival, we had a small mixer that included the most basic of matchmaker games. We each previously provided an interesting, yet unknown, bit of trivia about ourselves and we matched trivia to people by meeting and talking. The fun tidbit we recalled for years was that one attendee had “just met Sting.” That was BillG and he was excited about it.

During the mixer I encountered the first time I had to introduce myself as Bill’s TA. I wasn’t sure how to answer the most basic questions about my new job. Did I say “I’m Bill Gates Technical Assistant” or “I am on BillG’s staff” or maybe “I work for BillG”.  No matter what I came up with I was answered with a pause and then there would be a follow up question asking what I really did. Since I’d been on the job just a few weeks, my answer was always vague, but not on purpose. Even at this offsite, my fellow Microsofties were circumspect or even a bit put off by the role. It became awkward for me. For external use, I ordered business cards that simply said “Technical Assistant to the Chairman” which turned out to mitigate things believe it or not. It was saying Bill’s name that got the attention, not the title. For Japan, I was told I must have a Japanese language card and it must have Bill’s name on it. Internally I quickly came to realize people I was not close to always thought I was eavesdropping or something. To say the role was isolating would be true, but at the same time I found myself in most every meeting with people ten years and 5 stops above my actual pay grade.

We then convened in the small auditorium at the resort. BillG and the new VP of Human Resources, Mike Murray (MikeMur), who moved from Marketing to Human Resources. Before Microsoft he was the legendary head of Mac marketing at Apple who led the launch and creation of the famous 1984 commercial. Mike explained that the offsite was basically the same offsite the executive staff had held and the idea was to see if a “select group of up-and-coming” Softies would come up with better or different answers to the questions posed to executives. There were nine executives in attendance, which was about one-third of the worldwide executive staff at the time. There were only eight executives in the product or technology part of the company and half of them were at the retreat.

We were divided up into five teams of five and, after a brief discussion with a relevant vice president sponsor, we were given a challenge to resolve over the following day and a half.

By design, none of us had firsthand knowledge of the topic at hand and we were 120 miles north of Seattle, practically in Canada. There was no such thing as the internet and no Microsoft library. We could, however, call the library in Redmond to have articles and answers faxed to us. But mostly, we were supposed to brainstorm and use the knowledge we already possessed to extrapolate or divine an answer.

Some people (me) seemed more stressed than others.

It would be a few years until Andy Grove, then CEO of Intel, would write his seminal book on management, Only the Paranoid Survive, though he had written High Output Management years earlier. But long before that or perhaps always, BillG was paranoid. It is no surprise then that most of his brief 30-minute introduction to the offsite was focused on all the ways everything at Microsoft might collapse. In hindsight, as good a management approach as this was, it was arguably a ludicrous proposition that embodied the deep conviction of paranoia that permeated our collective thinking. To those that had been around for the 8-bit PC era and now the struggling mini-computer market, technology companies simply disappearing like a once active geyser at Yellowstone was not in the least bit paranoid.

Still, in 1993, there were already more than 30 million computers running Windows, and over 27 million IBM-compatible PCs were shipped compared to more than 3 million Macs. That statistic obscures the fact that Microsoft was still making much more money for each Mac than for each PC simply because of the dominance of Word and Excel on the Mac compared to the nascent success of Microsoft Apps on Windows, which was still dominated by customers running (primarily) MS-DOS apps like Lotus 1-2-3 and WordPerfect. Those numbers represented a growth of about 30 percent year-over-year, which had been going on for several years already. Microsoft was definitely not on the verge of collapse.

Still, the first breakout topic BillG introduced was “Doomsday,” and that group was assigned the task of outlining a doomsday scenario for how Microsoft’s growth and/or leadership could be attacked by competitors.

Another topic, which would become increasingly important in my role as TA (and later in Office), was how Microsoft could move away from licensing perpetual software and become more of an annuity business. This would also become exceedingly relevant decades later in a world of Software as a Service (SaaS) and subscriptions. When I think about this topic, one I spent many more offsites trying to crack, I realize just how far ahead BillG’s thinking was. Or, admittedly, how far back he was looking since IBM had long since pioneered leasing computing resources rather than selling them.

Owning software was an aberration in the beginning and middle of the PC era. It seemed inevitable that it would end, though many considered computer software to be the logical successor to music or VHS tapes (without the rental!).

Our group’s topic was, “How to fill the void left by the demise of IBM.” It was 1993 and Lou Gerstner had not yet been named CEO, which was just a few weeks away. IBM was on the verge of insolvency. This was not something looked at from afar as IBM and Microsoft were linked by a Joint Development Agreement for OS/2 and IBM remained a leading maker of PCs. The JDA would be wound down but would take some time to do so completely.

Our group’s executive sponsor was Brad Silverberg (BradSi), who was leading the product development and marketing for Windows, including the new version under development code named Chicago, which would become Windows 95 and later consume a huge amount of my attention as TA. Brad was relatively new to Microsoft but joined at a senior level with a great deal of experience, having worked at Apple on the predecessor to Macintosh, Lisa, and then at my nemesis Borland (but at least not on C++). I would be lucky to spend a lot of time with Brad over the next few years and fortunate to have learned from him early in my career, first as an assistant and then as a member of his team.

After the remaining topics were introduced, we broke into groups. Our group could not have been less prepared for discussing the IBM enterprise business. We had a finance person who worked on the costs of software licenses, a Product Support Services (PSS) leader, the general manager of Microsoft Hong Kong, a manager from the consumer software division, a leader from Excel marketing, and a manufacturing specialist who worked at the packaging plant north of main campus.

Not one of us in our group understood the IBM business all that well. My personal experience was with the IBM mainframe at Cornell, loading punch cards and changing the ribbon on the giant IBM printer while wearing arm-length rubber gloves. I sat next to the “ladies” that coded IBM reports when I worked at Martin-Marietta during the summers after my first two years of college where I learned some of the ins and outs of COBOL and RPG, while also setting up brand new IBM PC XT/3270 machines for executives.

Collectively, we knew three things: First, IBM was in dire straits in early 1993 and on the verge of bankruptcy—a rather stunning decline from where it had been a few years earlier when I was working at Martin Marietta and it was on the verge of one hundred billion dollars in revenue. Second, a few of us had read the best seller Father, Son & Co.: My Life at IBM and Beyond by Thomas J. Watson Jr., a personal history of IBM. Third, we had all heard the expression, “Nobody was ever fired for buying IBM.” Our task was to stitch those together into a coherent view of turning Microsoft into a reliable business computing brand.

We sent off an email to the library for a briefer on the IBM business and received back a faxed Annual Report and writeups from financial analysts. We certainly learned things were bleak. Then we also received materials from industry analysts that were looking at IBM mainframes and topics like account management and how many MIPS per year IBM was selling (MIPS are a measure of CPU power used by IBM to measure sales). We had about 50 pages of material to go through. None of it seemed all that relevant to Microsoft’s products or sales efforts.

We were up late and were making progress on the whole idea that Microsoft maintained an arm’s-length relationship with customers, whereas IBM had big account teams assigned to customers and in many cases they worked on site full time (which seemed just crazy to us). Those that worked in the Microsoft field and finance had familiarity with these teams and I realized the people in full suits in the hot Florida summer that occupied our hallways at Martin Marietta were those very account teams.

In the introduction, BillG had pointed out that most of our sales still came from retail sales—literally from people going to the store or ordering multiple copies from a reseller. While we had volume licensing, this was a program about to roll out (and was developed by a member of our team).

Today when I talk about the idea of transitioning Microsoft to the enterprise business, most people can’t believe that was ever a “thing”. Microsoft is perceived to have been born into selling enterprise products. In reality, the company grew out of two other ways to sell software. Bill and Paul pioneered the idea of an OEM relationship with computer makers to include BASIC for a small fee, and later MS-DOS. This proved incredibly profitable at relatively low prices but with very high penetration to each computer sold. Second, products like Word and Excel were sold one copy at a time through retail sales outlets for what seem like incredibly high prices, such as $495 for Word. There was even resistance to “bulk discounts” or “site licenses” because those clearly would end up with much less revenue from customers that used the product the most. While each sale was profitable, perhaps only 10 percent of new PCs owned (legal) copies of Microsoft applications. Microsoft was just figuring out the idea of how to sell just the software (not the hardware) to large businesses. Steve Ballmer moved to lead worldwide sales and was just beginning to build Microsoft’s efforts to be the colossus that it is today. He wasn’t at the retreat. The driving product force behind this transition was Windows NT, which was still months from RTM. The transition to building and selling enterprise products would occupy the next decade of Microsoft’s evolution. This offsite was clearly my introduction to this transition and by proxy, Bill was getting the executive staff broadly familiar with the topic.

We concluded that to fill the void left by IBM we needed to have account teams and build better customer relationships. We needed to de-risk the notion of the PC and PC software. We also needed to be in the networking business, which was dominated by Novell (we had a big project underway called LanMan). Much of what we concluded might seem obvious in hindsight, but in a sense Microsoft was learning this in real time.

We pulled together a deck and I ended up doing the typing (the person most closely resembling program manager at an offsite always made the slides), which, surprisingly, somehow meant I was going to lead the presentation. I was a bit intimidated. I made our group listen to me do a dry run late the night before. That was probably too much, especially since they had all been to a wine reception before.

We were only given a few minutes to present and so there were only about a dozen slides (see what I did there—way too many slides). I vividly recall using some of the (now) vintage PowerPoint clip art. When describing how demanding IT was, I used “demanding guy,” which was a cartoon of a bald man pounding his fist on a table. In describing how IT thought of Microsoft, I used the cartoon of a mainframe computer reaching out and strangling someone.

We presented the idea that IBM was much better at articulating a vision for computing than Microsoft. Microsoft needed to present a more forward-looking vision. The irony was that everything the company talked about was mostly considered vaporware by the press and customers since most of our products were perennially late and released with fewer features than we originally talked about. The idea of not overpromising was a core MikeMap belief, which he instilled in Apps and which was most decidedly a pillar of my own value system. I would struggle with articulating a vision versus overpromising for my entire career.

BillG sat in the front row, hunched over, elbows on his knees, rocking back and forth. With every rock backward his toes would lift up and every rock forward his heels would lift up. That was his trademark that I was growing accustomed to. It meant he was listening. Every once in a while, he grabbed his yellow pad and wrote something down with his felt-tip pen, usually circling or putting a box around whatever he wrote. Before we could even finish, he was asking me (or us) to explain how this elaborate plan would escape creating customer expectations we could not meet. IBM basically promised to deliver no matter the cost, and the best part about Microsoft’s business was that everything we sold was sort of “as is.” We had no idea what was going on with the customer and had the margins to prove it. One could argue this was going to be a lesson that would take a decade or more to learn. BillG was at once concerned about setting higher customer expectations while also failing to provide a compelling vision. That was probably my first and most visceral experience of BillG taking something most think of as an or and turning it into an and.

The offsite essentially wound down as the teams presented. Throughout the two days the other execs came and went. They all had clipboards and were taking notes. Years later, when I possessed a clipboard, I would learn that while the goal was to produce a presentation and enrich yourself, the execs were basically evaluating your performance in the group.

Sneaky.

Back at the office, I started to find a bit of a rhythm though was still unsure of when to participate or not. Given my newly minted expertise one of the strangest things I did just as we got back to the office was to sit in Bill’s office when he and newly appointed IBM CEO Lou Gerstner had a phone call. For Microsoft this was a call to a big customer who made very good PCs that needed an operating system. For IBM, this was a call to a former partner now a supplier or vendor to the PC business, and a competitor with OS/2. The industry was buzzing with how IBM should be broken up and sold off for parts. Conventional wisdom was also pondering a non-technical outsider leading IBM. The most vivid memory I have is Bill articulating how the strength of scale IBM possessed was the reason not to break the company up. Gerstner of course went on to an incredibly successful run, though he did eventually spin off the PC business.

I continued to learn how to work with BillG. More than anything I was absorbing his focus on competitors.

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

Back to 014. Chapter III. Executing on the Expansive Vision of Bill Gates

Even to this day I get queasy when I think about being late to this first meeting. If you know me it makes no sense at all. I often wonder if the world was telling me something back then!

I was hyperventilating by the time I got to BillG’s office, having raced from building 17 to the double-X building 8 overlooking the fountain. Being late was out of character for me. I never missed anything. At the time, it was entirely typical for BillG to be late. Bill totally changed this later in life and became maniacal about being on time.

Once I made it to BillG’s office on the second floor (there was an executive suite, but no special receiving area or security or anything), his executive assistant, Julie Girone (JulieG), gave me the look one would expect to receive for showing up late. Still, she pointed to the open glass door, where I got another look, this time from BillG, that basically said, “Nice of you to show up.”

BillG’s desk was a giant pile of memos, papers, magazines, books, a lot of three-ring binders for BillG Reviews, and two old school leather travel suitcases were by the door (I would learn that Bill traveled with one suitcase of clothes and one used as an over-stuffed briefcase and laptop bag). The bookshelves were jammed with more books and older review binders. He had the same oak desk that we all had, but he had the deluxe version with a credenza and a long bookshelf on the wall above. On the few bare walls, there was a framed poster of the layout of an Intel microprocessor and another of a radio wave spectrum map, and on a narrow column was a photo of Henry Ford. Behind the spectrum map was a secret white board.

We sat on the standard-issue Microsoft couch. I tried an icebreaker by mentioning that I had been difficult to get ahold of during college recruiting season three years earlier. BillG un-hunched himself and laughed a bit too loudly with a single “Ha!” and then said, “And you were late to this.”

Okay, this was going well.

What was left of our hour was a blitz of questions—deep technical ones about Windows, C++, and Excel. The former surprised me in a sense because even though he had pushed so hard on NeXTStep, he was not as deep into programming Windows as I might have expected. The latter was interesting since he knew I didn’t work on Excel. As we talked about Excel, the questions were much more about user interface and topics such as handling text in the product, connecting to databases, and new features (at the time) such as toolbars (the rows of icons representing commands, that previously were hidden in menus or complex keyboard sequences) and automatically generating better charts and graphs.

At one point, he said, “You seem to know a lot about Excel.”

This surprised me and I wasn’t sure what to make of it. How could I not know about Excel as it was a flagship app? I was surrounded by the Excel team from ADC (from DougK through that talk with JonDe) through AFX (Jeff and RickP!). And I used it every day for computing all the stats about MFC.

When we discussed Windows, his concern was performance as well as the difficulty of writing software for the platform compared to NeXT. I was super prepared to talk about that. While I was talking Bill would engage in his characteristic rock—a little hunched over, elbows on knees, rocking back and forth in his chair, lifting his toes in an almost choreographed manner, pausing only occasionally to push his eyeglasses back into position.

He talked about C++ at length, without asking any questions, about extending C++ in a proprietary way to make it easier to write Windows programs. While this could, in hindsight, sound nefarious, it was not. First, Borland had not only done this but was touting it in the press. NeXT had essentially taken over a programming language, Objective-C, which was much more appealing to BillG than using an industry language like C++. And second, Microsoft had a long history of essentially owning a language going back to BASIC. This was how the industry worked. IBM owned COBOL and Fortran. Sun and the Unix world owned C. PCs owned BASIC. It seemed like a natural evolution waiting to be exploited to improve the platform. Over the years, we ended up having many debates about when and where proprietary languages and APIs made sense.

Obviously, with our meeting cut short, a second one was needed. For this one, at Jeff’s suggestion, I brought some of the patents I had applied for in developing MFC and we talked about those. BillG loved patents and was interested in what I had filed as a result of working on C++. Patents were new to the company and we had heard the first mention of them at a recent all-company meeting where BillG said we would file patents more often going forward, but they would only be used defensively. This was a big deal because the libertarian streak among programmers was quite real and patents were viewed as almost anti-software by many developers, including me. This was also a response to ongoing litigation with Apple and a lawsuit between Borland and Lotus over whether user interfaces were patentable or simply copyright protected.

I got the job and accepted it. I never really thought about the decision, almost entirely because Jeff told me I needed to do the job for the good of Microsoft. So yeah, that worked.

I was never really sure how much thought Bill put into the role. My sense then and now was he was very happy with the way Aaron had provided a sounding board but remained lukewarm on the role. He was still scaling (as we say now) with the company and was still reluctant to let go.

Later, I learned that after bumping into BillG prior to my official start while at Jeff’s wedding, and having little to say to one another, BillG sent a note to NatalieY expressing concern that I might be too “shy” for the role. At least he didn’t say something about my tardiness.

I started in the new year, after we completed VC++ (RTM!) and our old AFX team was integrated with the larger C++ team in Languages. Right before I left for the holidays, I moved into my new office—my fourth office in three years. Tucked in the back of the executive suite was a supply closet and a small (smaller than typical) window office overlooking the fountain (so that was nice). I had the same oak desk and bookshelf but no room for a guest chair. I shared a wall with BillG on one side and Greg Maffei (GregMa), Microsoft’s then treasurer, on the other. The walls were thin. Greg talked loudly on the phone a lot.

Aaron was still cleaning out his office when I arrived. It was a huge job as there were papers, boxes, books, magazines, products, and piles of stuff. While Aaron was finishing up packing, I began contemplating a trip to Fred Meyer for 409 and Lysol. I was always a bit finnicky between office moves.

The first and most well-formed thing Aaron said to me was, “Look, you have to understand that every group is totally screwed up.”

Okay. Well, that was good to know.

Coincidently, BillG said this same thing to the Wall Street Journal in May 1990 when asked about a late product that year. “I’d say there’s as much screwed up now [at Microsoft] as there always is.” This was in an article at the launch of Windows 3.0 that chronicled all of Microsoft recent failures including OS/2, LanMan, and even optical drives (CD-ROM).

Aaron explained that a big challenge in the job, one I still did not yet understand, was that there seemed to be an endless series of meetings. In each, every group presented what was going wrong. Even if they didn’t offer what was going wrong, the meeting would turn into a forum to find out what was going wrong. This focus on what was not working was a hallmark of not just BillG meetings but email and other interactions. There was little time to waste on what was working.

He offered a second piece of advice. “Bill knows everything about every group and never forgets what they told him at the last review meeting.”

Aaron said, “I thought he knew what was going on because they told him the last meeting and he remembered it. Then after meeting with some groups for a second time I realized he remembered everything—things I didn’t remember and even things the team didn’t remember (or wanted to forget) going into the meeting.”

Good to know. My notetaking skills would be put to good use.

With little additional guidance, he summed it up by saying the job would be what I wanted to make of it and to be helpful to BillG. His parting words were, “Start looking for your next job now because it is going to take you forever to decide which screwed-up team to join.”

In hindsight, all of Aaron’s advice, what little he offered, proved correct.

On to 016. Filling the Void Left By IBM

At the start of Chapter III towards the end of 1992, I thought I was about to start on the next release of Visual C++. Instead, a surprise email has me discussing a new job working for BillG as his “technical assistant”. I begin think about what the company is like to the outside world. Inside the company, we’re just working (and working, and working some more) trying fix the bugs, to ship, and get PCs to actually work. Microsoft was growing up. I was growing up. I didn’t even know Bill yet, having only met him at the new hire party.

This chapter and the following chapter (about 15 posts) describe the next two years. These years were probably the craziest time for the company, for Bill, and even to date for the technology industry.

Just a gentle reminder, this post is free to all those that signed up for the substack. Shortly I might do some posts that are subscriber only. Everyone will receive an excerpt though.

Back to 013. End of the Beginning

I blew off Bill Gates the first time I was supposed to meet with him—well, at least the first 20-plus minutes of our meeting in the fall of 1992.

I had been in AFX group leader Jeff’s office talking about some last-minute ship details for VC++ when I realized, “Oh crap, I am supposed to be meeting with BillG.”

Days earlier, Natalie Yount (NatalieY), at the urging of Jeff, spoke to me about taking a job that I knew nothing about, working for a person I had never really met, doing . . . I had no idea what. It was called technical assistant.

NatalieY represented a rarity at Microsoft. She was a core torch-carrier of the company culture, but not a technical person. She came from the famed Xerox PARC where she worked as a research librarian in the labs during some of the most innovative years at one of the most innovative places in technology (or anywhere). At Microsoft, she quickly captured Microsoft’s culture and became the leader that bridged fresh-out-of-college technologists and the real world.

During our meeting, she and I talked for a bit about me, my least favorite subject, but our conversation did not feel like an interview. Then she described the job. There had only been one other formal technical assistant and that was Aaron Getz (AaronG), another college hire who had worked with DougK on Microsoft Money as the only program manager. Carl Stork (CarlS), a college classmate of BillG’s, had previously unofficially held the job very early on where he worked with Bill on the organization of commands for Multitools apps. Richard Brodie, the original Word for DOS developer and former Xerox PARC engineer held the job for a year. Jabe Blumenthal (JabeB) had as well. JabeB had joined Microsoft as a college hire in the early 1980s. JabeB was the original program manager at Microsoft and had led the design of Microsoft Excel before leading efforts in the newly formed Consumer Software Division, where multimedia CD-ROM products and other home software was being developed.

It sounded like the job was “assist BillG with technical stuff” I thought to myself. In other words, there was no real job description. Jeff later described it as BillG’s “eyes and ears” on a deep technology level so he could continue to be engaged in a way he wanted to. That helped slightly. One thing was clear: The previous holders of this job were Apps program managers, while I was more of a Tools software design engineer. A concern (BillG had, I was told) was that as an SDE I lacked a big picture view and was too focused on the code, but that was not how I had been trained. (JeffH told me not to worry.)

Natalie later sent me a note and copied BillG’s assistant to schedule a meeting.

In thinking about what this sort of meeting would be like and how to prepare, the realities of Microsoft began to sink in. Not the product realities, those I understood well, but the realities of the company and that it, and BillG, were changing.

Jeff, my mentor who clearly arranged for this meeting to happen, offered me some of his insights. First and foremost, he confided in me that the company was now at a scale that Bill can’t keep track at the level of detail that he wants to. This was not to take away from his IQ or anything, but just simply that Microsoft had a lot of stuff going on. Jeff talked about how he could not put a finger on it, but Bill was “different” during the formation and shipping of AFX products—different in the sense that his input was more abstract, strategic for sure, but not at the level of detail he engaged on the evolution of Word or the first versions of Windows. Bill wanted to and believed he could continue to engage at a deep technical level, but Jeff felt he needed tools, or a person, to scale that effort. That’s how he came to suggest me to Bill.

The first few years after Microsoft’s IPO had been kind to Microsoft. Whether before the IPO on the cover of Time Magazine in 1984 or the cover of Fortune Magazine in 1986 just after the IPO, the image of the youthful and brainy nerd cemented Bill as a leading innovator of our age. Heck, it seemed like the whole country was embracing khakis and button-down shirts. It was like the ten-year old film Revenge of the Nerds had become reality.

Then came the book Hard Drive: Bill Gates and the Making of the Microsoft Empire by two reporters for the local Seattle Post-Intelligencer who had covered Microsoft for some time. The book had just come out, Spring 1992. Everyone at the company knew Bill (and allies and employees) did not cooperate. It was clearly intended to portray events in a negative light and was trying to be the first to do so (and succeeded). Writing today, I’ve learned that books like this are written too soon and amplify (or even get incorrect) events that are still happening and still unclear, the fog of war. Even today reading the book’s stories of hidden bugs designed to disadvantage customers or third-party developers seem as patently absurd, and false, as they did back then, even if the book spun a yarn saying otherwise. The arrival of the book began to color interactions with the press that to this point had been even-handed or even celebratory. Microsoft and Bill seemed to be entering the bad part of the cycle of build you up, then tear you down.

The real difficulty was the cloud of regulatory oversight that was just starting to form. While there were one-off stories, there began to be a critical mass of what might be called business practices that were claimed to be at the root of the success Microsoft was achieving. In other words, with the success, people were looking for the cause. Microsoft’s aggressive business practices were starting to be viewed as crossing some line. There had to be a way to explain the success that was not rooted in building great products, or so it seemed.

The way that employees could see this were through stories in trade press most often with quotes from who we viewed as competitors, or perhaps even bitter competitors that had lost. The primary dynamic going on that we talked about at lunch endlessly was how the success of Windows even caught Microsoft off guard compared to the determination to make OS/2 and the IBM partnership work. What Microsoft did was not pull back or even sacrifice that partnership to bolster Windows, but rather was just quick to recognize the product was not working and to find a different path. Unfortunately, most of the leaders in the industry chose to stick with IBM even longer than Microsoft did. That caused a lot of bitterness among the software leaders of the first era of the IBM PC, all of whom were under increasing pressure to have similar success on Windows. My old friend from drinks at the Software Development Conference, Philippe Kahn the founder and CEO of Borland, was one of those who led the charge, even advocating for IBM.

What was so weird was that in the lunchroom we were mostly relieved. It was not a master plan, but a master pivot.

There were then the constant stream of opinion pieces in the trade press criticizing Microsoft for products that were late or buggy. Every product was late and buggy and while we might argue at the very least our products were less buggy given the financial success the industry and customers were expecting better.

Across the industry trading barbs in the press nearly continuously for the past year or more over the future operating system platform was now routine. Analysts and executives on all sides would say the others are spreading “fear, uncertainty, and doubt” or FUD. FUD is a tactic, or theory about a tactic, designed to prevent customers from buying rival products by sowing negative views. In an ironic twist that really gnawed at Microsofties, often it would be said that Microsoft was employing a FUD strategy just as IBM had done before and perhaps even Microsoft, in the early 1990s, had become the new IBM—a recognition of the declining influence of IBM in the personal computer industry and Microsoft’s rising influence, or even dominance. NT was viewed as the center of claims of FUD because it was shipping real soon now, and at the same time Microsoft was indeed putting forth a pretty grand vision for the product that would take years to materialize.

Internally both now and for quite some time, Microsoft felt and acted like the insurgent. The computer companies we knew growing up were being left behind and many companies we knew from just a few years ago were struggling with the transition to PCs from mainframes and minicomputers. It was not difficult to imagine that fate for us if we just missed a few beats, executed slowly, or failed to deliver. At the same time, we were just struggling to keep the wheels on trying to deliver products, fix all the bugs, and make things work.

The narrative outside of power and influence simply didn’t match our day-to-day experience of fragility and challenges. We’d read about power and did not feel it or even understand what it felt like. Certainly, no team returning from a BillG review felt power. They felt the same pressure to achieve technically.

It was all super weird.

These were all really big issues, the subject of lunch time gossip. I could never hope to have an intelligent conversation with BillG about them.

I was more worried about Bill asking me questions about technology I would not know the answer to. Or pushing me on flaws in our products that I had been part of creating. Maybe even saying something that was “the stupidest thing” he had ever heard. I wanted to be “high IQ” even though it was still unclear if I was interviewing for a job or just doing some sort of informational meeting. I had no idea what it was like to change jobs inside of Microsoft and almost no one I know had even done that yet, save for OS/2 people moving as the project started winding down.

I set up a time to meet with BillG.

On to 015. Every Group Is Screwed Up

It is 1992 and we’re finishing up the release of what would become Visual C++. Powering through the battles of naming a product, engaging on reviews, and figuring out what comes next keeps us all busy. At a Seattle-area event learning why Aldus (of PageMaker fame) chose Microsoft C++, I meet a career-long colleague. It is the end of the 16-bit era of Windows as far as developers are concerned, and the start of the Win32 32-bit era. This concludes Chapter II.

Comments for this post are open to all newsletter recipients. I welcome feedback on the journey so far and the structure of this work.

Back to 012. I Shipped, Therefore I Am

As we closed in on release mid-1992, the product needed a name. Naming products at Microsoft was known to be somewhere between painful and traumatic. That proved to be so for my first experience.

I already learned that my accidental naming of Microsoft Foundation Classes caused two problems. One was a cease and desist from a French bank over the use of the acronym MFC as software and banking were the same trademark category. This made us spell out Microsoft Foundation Classes everywhere which led to the second problem of absurd complexity and grammatical gymnastics in our volumes of documentation. Oh well.

It was clear the compiler was going to be version 8 because compilers just get version numbers (and continue to). C8, as everyone called it, ultimately became the world’s best and most industrial strength C++ compiler. It was an achievement.

MFC 1.0 (I’m stubborn about the acronym here) was officially bumped to version 2.0. Class Wizard and App Wizard names remained. Composer became the visual centerpiece of the product and gained the name App Studio, which was how we competed with NeXTStep Interface Builder.

Naming the individual pieces was easy. What to call the entire product was tricky. Microsoft was notorious for finding it difficult to arrive at simple names. In this case, calling the whole collection of tools C++ 8.0 or something descriptive, and the logical successor to C/C++ 7.0, seemed lame and not all that competitive with Turbo from Borland. As we debated, some advocated reusing the Quick moniker, but that represented the low-end or amateur programmer. It was complex.

In the meantime, Microsoft Languages had a huge hit product on its hands, Microsoft Visual Basic or VB. VB came from out of nowhere—it was a combination of Microsoft’s BASIC language runtime with a Windows-based “forms” editor and runtime, an idea originally seeded by an email question from BillG. A runtime or runtime library provides programmers with additional capabilities that can be accessed by the programmer as a form of reusable code. Some runtimes provided simple capabilities such as basic math functions while others can provide sophisticated capabilities for creating games or connecting to databases. Runtimes were in many ways the heart and soul as well as a secret ingredient of the early PC era. Basic had a runtime. dBase had a runtime. Runtimes were even a vibrant market where developers could buy special purpose ones for use in their applications. These runtimes presaged the world today of APIs and services.

GUI forms were windows with buttons, checkboxes, menus, and more associated with them—BillG loved forms and would spend the next decade pushing for more and better implementations from many different groups. VB pioneered the ability to rapidly draw a form then use the BASIC language to program all the logic of an application, called code behind forms. VB 1.0 released approximately 18 months earlier but took the world by storm, particularly among professional developers inside of corporations. In code name shorthand, VB was Ruby plus EB, EB was short for the embedded BASIC runtime, and Ruby was the code name of the forms package, and together had the codename Thunder. A version of the forms portion was created independently by Alan Cooper and acquired by Microsoft. Alan was later honored as an original Windows Pioneer and is known as the Father of Visual Basic for his work.

Coincidently, Visual Basic was also loosely an ancestor in the Quick family of products and the original editor and development environment derived from QuickBASIC. It seemed logical then that the new C++ product should take on a similar naming scheme.

There were a lot of meetings, a great deal of consternation, and even some lawyers. It turned out that the success of VB spawned a cottage industry of people registering product names derived from Visual, before Microsoft. The various Languages marketing teams agreed to start a family of products, first with Visual Basic and then Visual C++. Microsoft also worked to secure a few other visual names (though Visual COBOL never made it to market). While we called the product VC++, BillG stubbornly insisted on calling it VC for some reason.

Just before we launched Visual C++, I attended a fall 1992 meeting hosted by Microsoft at the original Northup building (Microsoft’s second Bellevue location after moving from their downtown location in the early 1980s) down State Route 520 adjacent to Burgermaster, then home to Microsoft University (a.k.a. MSU), which created books and training materials for Microsoft products. At this meeting, local commercial companies talked about their experience using the new C++ compiler and tools from Microsoft—specifically, why they chose Microsoft over Borland (which was all we cared about).

Seattle was home to a couple of large independent companies building Windows software back then. The largest among them was Aldus, creators of PageMaker and inventors of the desktop publishing software category. PageMaker was an early Windows app and one of the first to require a mouse, and it was also a big product with a lot of code. Winning them as a customer over Borland was a big deal.

When it came time to present, the PageMaker engineering manager made a strong case for why Microsoft’s product was solid. She presented a full suite of Aldus benchmarks for compile time (the time to produce a running program from source code) and runtime performance for key operations (PageMaker was computation-intensive and highly dependent on how well C++ created code). She also talked about the transition from C to C++ and value of a standards-compliant compiler like Microsoft’s in their rewrite of PageMaker for modern Windows. All in all it is fair to say she did a great pitch for Microsoft. Sitting in the back with a few members of the team, we were beaming with pride.

After the presentation I went to thank the speaker. She introduced herself as Julie Larson. We talked for quite a bit in the parking lot about their internal C++ library (which sounded surprisingly Old AFX like as described by another speaker, the architect of that), and after a while she mentioned it was late and “I need to get off my feet” as she glanced down towards the ground. I was a bit confused by that comment and then realized she was pregnant, something I might have noticed at first and then did that awkward thing one might do to avoid looking down or commenting (Microsoft would soon experience its first baby boom, having just gone through a first wave of thirtieth birthday parties). I mention this only because while on leave with her new daughter Katie, she was recruited by Denis Gilbert (DenisG), the new general manager of VC++, to join the team. This chance meeting and Denis’s strong recruiting work began an incredibly important Microsoft career. JulieLar would go on to be a key leader, along with many alumni of the VC++ product cycle, in the elevation of Visual C++ to the Visual Studio product line. Later, she became arguably the company’s most significant leader and manager in building human-centric Microsoft products. For me, meeting her was the start of an incredibly important product development partnership.

Leading up to the launch event, I was quite busy learning the ropes with the press—something that I would end up doing a lot more of for the rest of my time at Microsoft. The focus of the VC++ product messaging ended up being the ability to create Windows programs, and that made me a good spokesperson. We spent a lot of energy trying to move the evaluation criteria for “compilers,” from compilation speed and code size to how fast a Windows program could be written and how easy it was to modify it.

The state of the art in evaluating products, perhaps represented best by the elaborate labs at BYTE magazine or PC Magazine, was to have dozens of PCs running all sorts of automated tests dozens of times, averaging the results and compiling endless tables of comparisons. These labs were incredible and rivaled our own in-house testing labs. There was a strong desire to distill results down to quantitative measures that readers loved, which always posed a challenge when working to tilt evaluation criteria towards what we were strong at. Ultimately, VC++ did well in reviews but still took a few years to win over the hearts of developers even if we won over the minds.

In the early 1990s, the press reviewed products in two waves. Usually at RTM the next issue of a monthly or weekly would have a first look short form that was usually not much more than the voice of the company, perhaps with a little doubt as to execution or a bit of wait and see. Then after a few months and an editorial calendar opening an in-depth review would appear. These reviews were often the work of a full team and weeks or more of dedicated work, from benchmarks to real-world usage across the leading products in the category.

The most fun was the trek up to BYTE magazine’s offices in rural New Hampshire in what was a converted agriculture or bovine research facility of some kind (no really, it had huge elevators to move cows around). The trip there always included a stay-over (because we were well outside day trip distance) in the famous Jack Daniels Motor Inn and the Peterborough Diner. Today, the only equivalent of reviews like we used to receive are those that run in Ars Technica. A typical review would be ten or more pages, with several full page tables. Part of visiting each publication, usually for a half day or more, was an attempt to influence the rows of all those tables—what criteria would be evaluated. While we were adversaries in a sense, I made a ton of great friends on those trips across editors and writers.

I mention these trips and the reviews because Jeff had instilled in me an absolute obsession with reviews and digging in and reading them in depth. This was quite different than what you hear about people in other creative fields that stay away from the potential criticism of reviews or reviewers who aren’t necessarily skilled (or whatever). Jeff’s view and that of Apps was the opposite and reviews were everyone’s job to understand, read, and absorb, and not just our reviews but the competition as well. BillG read all the reviews too and he was always current and up to date. Losing a review was almost a guarantee that you’d receive email asking why.  

Everything was in the home stretch. That meant that while people were coming to work to triage and investigate, it always appeared as though they were not doing much but postponing issues and re-running tests. In the projects of this scale and duration, there was an irony that productivity dropped to effectively zero at the end of projects. Making any change was always more risky than shipping whatever was being fixed.

The Group Product Manager in charge of marketing for the Languages business picked a launch date and venue at the Software Development Conference (SD93) in February at the Santa Clara Convention Center. The event featured black-tie presenters and an orchestra theme—Visualize Your Masterpiece. This venue was generally where big tools for developers were launched, the newly recruited marketing leader Jim McCarthy (JimMcC) pulled out all the stops for a huge event.

Back in Redmond in our AFX hallway there was clearly a well-earned sense, from Jeff, of mission accomplished. He had led the creation of a new team, alignment of strategies across the historically strong-minded Languages group, and created a new category of professional development tools for Windows and in Windows. To some, he redeemed himself from that Word experience. We accomplished the BillG goal of not making the same mistakes again. The two years went by quickly and even though I felt like I had wasted a lot of time early on, looking back, at what we accomplished would not have been possible without all we had endured. I learned the classic engineering lesson that every failure is simply practice for success.

The introduction of Windows 3.0 and products like Visual C++ for Windows marked the end of the first era of personal computing and the start of the transition into the next—while Windows 3.0 and 16-bit successors were the overwhelming customer choice, attention already shifted to full, or native, or real 32-bit computing as shown by Windows NT previews. Win32 is where developers wanted to be. In fact, a quick turnaround of Visual C++ 1.0 specifically for Windows NT was in the works.

The GUI revolution was about to kick off a colossal expansion of computing throughout the workforce and home, and then the internet accelerated that (or perhaps it enabled the internet?) beyond anything imagined in Redmond.

Culturally within Microsoft, I came to understand that in a sense I completed my schooling in the worldview of Apps and I fully embraced that culture. This was almost certainly pre-ordained by my path to Microsoft having started out in computing building business apps, and at each step I saw the product built through the lens of the end-user or business problem rather than from the bottom-up or technology perspective. The Microsoft Apps culture was also one that held a distinct view of how teams are led and managed and products planned and executed, distinct from the traditions I saw in Systems and Languages. Jeff created a little Apps “island” in the sea of Languages and Systems when he created the AFX team. My Apps perspective would stay with me for the rest of my career. I owe everything to Jeff, and he was not done supporting me.

Having said that, while that perspective would prove transformative for me as a future manager, there were also times it would test me.

With 1993 coming to an end, the team geared up for future releases, including the transformation of VC++ to Visual Studio. I too was ready to build on our successful product. My mentor Jeff and HR leader Natalie Yount (NatalieY) had different plans for me as I was about to find out.

On to 014. Executing on the Expansive Vision of Bill Gates (Chapter III)

Attending and presenting at the first Win32 Windows Professional Developer Conference (PDC) and meeting (and being intimidated by) Dave Cutler along the way. Shipping my first product while navigating the contentious battle for the real first product.

Back to 011. A Strategy for the ‘90s: Windows

By July 1992, it seemed like the whole of the industry gathered in San Francisco at the Moscone Center for the first Win32 Professional Developers Conference, which came to be known as the Win32 PDC, named after the 32-bit Windows APIs that were unveiled and the cornerstone of the event. For the first time Microsoft also mentioned Chicago, the code name for the successor to Windows 3.11, which would become Windows 95, real soon now. More than 5,000 developers attended this event, an enormous number, and were introduced to Windows NT 3.1 Preliminary Release Build 297, dated June 28 and provided to attendees. As I recall, something like 25,000 developers ultimately received the first CDROM.

Windows NT was a next-generation operating system, aiming for the professional workstation and high-end data center markets to compete with Unix and VMS (from Digital Equipment Corporation, DEC). TThe project leader and architect was the legendary Dave Cutler (DaveC) and included a group of experienced industry engineers also from DEC, collectively the key members of the original VMS team. Windows NT was a 32-bit (and soon 64-bit) operating system designed from the start to run on several of the latest microprocessors, including those from Intel rival AMD and Silicon Valley upstart MIPS. When it was under development, it was always scheduled to ship real soon now, though the project was always under control and managed with military precision and discipline. The task of building NT was immense. Like every project, it just took longer than people thought it would, even the most experienced people.

At the PDC the OS was referred to as a beta by most. Not quite a beta, officially it was labeled Preliminary Release for Developers. It was a build (basically the most current version that worked). The team was extremely hardcore about maintaining daily quality. Every day a build was created that was reliable enough for the team to self-host. The NT daily build was as solid as anything Microsoft was doing at the time, and it was a new OS built from scratch running on brand new hardware. It was impressive, even in its early stages.

Along with the compiler and tools from the Languages group, a major effort, we released a beta version of our entire MFC application framework, which eventually became version 2.0. This included the ability to create Windows programs for NT on MIPS and ‘386 chips (by this time the industry was calling chips ‘386 because the i386 from Intel had a competitor in the AMD Am386 which was fully compatible), and Win32 (and also Windows 3, now referred to as Win16). For the sake of completeness, I should mention “Win32s” the implementation of the Win32 API on Windows 3.1. It was viewed as potential way to expand Win32 applications to existing PCs. In the end it sounded better than it really was (we even considered using it for the C++ product), but at the time it was comforting to developers who thought it would expand the reach of new Win32 applications and a classic Microsoft approach of trying to include existing hardware and code in a new strategy.

Reaching this milestone was huge for our AFX team, all 18,692 lines of code.

Our team shipped our first product! I shipped a product! It was a beta and all, but still. It was on a CDROM and everything!

It was also my first time speaking at an industry conference. This was a huge conference with many tracks and a wide range of developers. C++ and OOP were extremely hot topics, so I ended up giving a talk to what seemed like the largest room I had ever been in, certainly bigger than the USENIX ballroom and bigger than any meeting on Microsoft’s campus. By this time, we had a great story to tell about being reformed oopaholics and “hardcore”, using C++ as a better C, and, importantly, about our class library being all about Windows and not competing with Windows or duplicating it.

A funny thing happened along the way to the PDC—I got to meet DaveC. It was terrifying. And then gratifying.

As soon as it became clear that MFC and C++ would ship with the PDC release of Windows NT we were introduced to the NT “ship room.” This was a conference room, but one where the team met every day to discuss bugs and propose changes to the product. The NT team (and many other teams) preferred to call it the “War Room” as a source of pride, sometimes even officially with an officially engraved door sign. I always hated that term and wouldn’t use it (building software is not a war, at the very least). It was lorded over by the most imposing engineer I ever met, DaveC. Everyone was terrified of Dave. No one wanted to be responsible for slowing down the progress or worse introducing an error somewhere that caused problems for others. The ship rooms in Apps were challenging but nothing at all like this one. During the NT project, Dave famously put his fist through the wall. The team memorialized the hole by writing the date next to it with a marker and putting a wood frame aound it. Things were different over there. My role was to attend these meetings regularly and not say anything, and if I was asked something, to say that “MFC was on track and had no issues.” And then go back and do everything to have no issues. Keith Rowe (KeithRo) had the job representing the compiler to the ship room and was constantly given a much harder time at these meetings. I am certain his Canadian disposition served him well in these moments. I just sat in the back and wasn’t allowed to make a mistake.

There was just one thing. I thought the Windows NT team was making a mistake, and a big one. We were building MFC to make it easy for programmers to create apps for either 16-bit Windows 3.0 as it was shipping millions of copies and for the new 32-bit Windows NT. We were committed to using the Windows APIs and not fixing them or changing them. Unfortunately, there was an organizational and philosophical schism across the 16-bit Windows 3 team and the 32-bit NT team. The resulting divide created a difference in the APIs for each Windows, a difference in expression (in WINDOWS.H to be specific) that made it difficult for the APIs to work in C++. Ostensibly, this was due to expanding the APIs to handle twice as many bytes that is “widening” from 16 to 32 bits. But much of it was also rooted in assumptions for how compilers worked which were not correct. The functionality was the same, but it would have made it tricky for developers and would not have worked if there was ever a world where we would move from 32 bits to 64 bits (which of course happened a decade later). The idea of a seamless and scalable API from 16-bit to 32-bit (also 64-bit) Windows was a key strategic initiative and it felt like we were at ground zero showing it was not coming together nearly as clean as it could. There were also a good number of gratuitous changes in Windows APIs (among the 350 or so that existed at the time) that were made by the NT team, likely “fixing” some irregularities or inconsistencies in the original Windows APIs.

Jeff thought this was a great opportunity for me to show leadership—an opportunity for advancement as they say in the military. He sent mail to DaveC subject line “Win32 issue” and copied me suggesting that I meet with DaveC.

Once again… terrified.

I was a newly-minted lead who had never shipped. I hid in the back of the ship room. I was trying to ship our product for the first time on the biggest train at Microsoft. I was supposed to meet with a larger than life General of Windows NT. On some level, I wanted none of this.

I went over to meet DaveC though. It was just the two of us in one of the tiny conference rooms (a single 60 inch round table) that made up the interior ends of the single X buildings. I was sitting there. He walked in and looked at me and in an annoyed tone barked, “Who are you and why are you here?” I was prepared with all sorts of printouts and descriptions of the problem and began to explain. There was an argument of sorts but mostly he kept asking me why I waited so long to bring this up. This would be a massive change, when every change was scrutinized, even without the PDC deadline. Like every good engineering manager, I would come to understand figuring out who messed up was far less important than the stress over fixing it so late in the process.

I went on to explain that we were a new project and the first people doing C++ programs on top of both Win16 and Win32. I explained how we modified the code in question and tested it and it works fine—of course everyone always says that about changes. I tried to steer the conversation, to the degree you could call it that, to where Win32 varied from Win16. I didn’t understand why things changed or assign blame. There was some more yelling, though not clearly at me as much as at the situation. I recall sticking to my ground only because it seemed so obvious and even trivial. In hindsight, I had no experience with how off-the-rails things can go by making small changes toward the end of a project. These would be changes in the mother of all files, WINDOWS.H. I really can’t believe I advocated making that change. I’m pretty sure later in my career when sitting in the other seat I never would have accepted it so late.

Nevertheless, the change happened. I didn’t ever get the benefit of an admission of my correct view in person. Rather on my way back to building 17 (while I was feeling like throwing up), DaveC sent an email to Jeff that read, “fine” or something like that. Jeff was proud of me and I was relieved and felt I accomplished something but really it was just weird. To be honest, I felt best when RickP, someone I thought so highly of, said months later, “I heard you went and fought with Dave Cutler [emphasis in his voice] over this change and won.”

Shortly after the PDC, Microsoft C/C++ version 7.0 Development System for Windows released to manufacturing in August 1992. It took time to manufacture and distribute to stores because the box weighed over 42 pounds in shipping and included 23 floppy disks and over 10,000 pages of printed documentation in 24 books. The box was so large that Microsoft’s own manufacturing facility could not handle it and it was ultimately packaged at a plant in Oregon that handled sporting equipment. This was physically the heaviest product Microsoft ever shipped and the last time a developer product was released on floppy disks.

With C7 shipped MFC 1.0, a subset of the pre-release product from the PDC. It was a set of “helper” classes that could be used to make some aspects of C++ easier. It was not a framework for building an application, but rather simply some reusable code. Importantly, it was our team shipping and that is what mattered. At Microsoft, shipping equated to being relevant, plus real artists ship.

MFC 1.0 was constrained, and everything Jeff (and ScottRa) thought would happen did, which was that the product helped our team figure out how to ship. The biggest lesson a new team can have about shipping is that once you ship, it gets easier to do it as a team the next time.

We had work real to do to compete with the NeXT system.

We hardly had time to catch our breath. While we were shipping MFC 1.0, the bulk of the AFX team, about 15 of us, was building an entirely new tool for creating Windows apps, with the code name Composer, playing off the idea of art and artists creating and shipping.

Composer was the tool to compete with NeXTStep Interface Builder, where a developer arranged the dialog boxes and menus of their app using a mouse and GUI. Composer was also going to be the first large-scale Microsoft app written in C++, using MFC. We were self-hosted or, as the Windows NT team called it, eating our own dogfood (An expression rooted in the 1970s commercial for Alpo dogfood—"the kind dogs love to eat”—and later used in an email from PaulMa extolling the virtues of using pre-release software ourselves). Composer was using the complete class library we shipped in beta at the PDC.

We still needed magic though. Composer already had a competitor recently acquired by Borland shipping with their C++. Borland Resource Workshop (BRW) became a favorite among developers. There was also a Borland Class Library called Object Windows Library (OWL). To me, OWL seemed a lot like Old AFX (bloated and different than Windows). With these tools, however, Borland was making significant headway with professionals.

ScottRa was the magician. The key challenge with Windows programming was that it was finnicky and verbose. There was a lot of bookkeeping and rote code that was error prone. Doing simple things, like putting up a dialog box for the user to make some choices and acting on those choices, was hundreds of lines of code, all with ample opportunity for mistakes. For most professional programmers who honed their skills in character mode and MS-DOS, this stuff was maddening.

Visual Basic pioneered the concept of making it easy to code GUI programs. The problem was that it was not viewed as a professional tool and was much more geared toward business app developers and not commercial C programmers. In use, NeXTStep looked like Visual Basic but used what was considered a more professional (albeit obscure) language.

ScottRa previously worked on something used across the big shipping products in Apps (Word and Excel) called SDM, standard dialog manager. It made it easy to design user interface and get information to and from the end-user. He cleverly took those same techniques and built a way for MFC to accomplish this same task. Instead of designing the interface by typing text in an editor, a programmer used Composer to connect windows, buttons, and checkboxes (controls) to MFC C++ classes. The programmer added any extra required code, like if the input needed to be a valid phone number or something. Even better, if the developer needed to add another control, that could be done without any worries about breaking what was there.

We believed we created the first graphical tool for C++ programming that allowed code to be created and modified and then later changed without breaking it. Programming tools that created code were common, but they were usually limited to only creating code once or creating very fragile code that was difficult for programmers to modify or incorporate into large-scale projects.

Composer was slick. Super slick. Thanks to the program management from ClifS and the coding artistry of BradCh, the app itself was pioneering user interface techniques for Windows soon seen across the industry. A favorite example was the small property inspector window that floated on top, always showing the details of what was being worked on. It had a cool little thumbtack to keep it locked in position.

This wasn’t all a theory, either. It was being used in practice. Composer was being used to build Composer, which was itself built with MFC. We were building GUI tools using a GUI framework. Having said that, there was one challenge. We did not have a GUI code editor or debugger. Those tools were still the old C 7 character mode tools. It was not at all clear we could make the tools run well on Windows 3.0, while Windows NT was still not going to be a broadly used commercial product for some time. On the other hand, the next C++ product wouldn’t be ready for some time. This was, again, a classic schedule chicken between two big teams with their own agendas.

The Languages team previously shipped the Quick C compiler for Windows, but it was a different code base from the professional compiler. The editor and debugger, collectively called an integrated development environment (IDE), were not nearly the same level of professional tool as the character mode ones. The challenge was if we as a big team could bring the IDE together with Composer and MFC to create a professional development environment in and for Windows, then we would have something to compete with NeXTStep.

It was rather contentious. The idea of being on Windows 3 was technically problematic because Windows was not robust enough for development. If the program crashed while being written then the programming tools crashed too, probably losing work. Since programs always crashed when being built, Windows was pretty useless as a programing host. That didn’t stop Borland though. Many professionals were on OS/2 and anxiously awaiting (or moving to) Windows NT. For better or worse, there were many fans of the C6 and C7 character mode tools. While the need and wish were obvious, the technical limitations were plentiful.

Schedule chicken is never fun, and generally at this point in Microsoft’s evolving engineer culture, everyone was wrong about their dates. I think many on AFX felt the Languages team was too conservative on making the bet on GUI. Many on the Languages team thought the AFX team was naïve and was not being pragmatic about what could be done or the risk to losing to Borland if we got caught not shipping for a long time while we waited on Windows. There were deep concerns on all sides about performance such as speed to compile a program, which reviewers measured in exhaustive multi-page reviews. There was tension and frustration, and we were still behind both Borland and NeXTStep. The Languages team was much more concerned about Borland, especially with the various teams at Microsoft continuing to make noise about performance relative to Borland. We were just as concerned about NeXT because that was the charter of our group. With no prior product experience and no connection to existing customers, the choice to build GUI tools seemed abundantly clear to me. In reality, I had a lack of empathy and experience upon which to base my opinion.

We needed a decision across the teams, so Jeff scheduled a meeting with MikeMap, who by now was leading all of product development at Microsoft in a sprawling role as executive vice president of the Worldwide Products Group.

This was my first senior executive meeting. I am sure MikeMap had already heard all sides of this in previous discussions with various leaders, as should have been the case. I was a new lead sitting in the outer ring of chairs—the observer seats. Many people were in the meeting, which began with a slide outlining the big decision to be made. The decision was whether to make a big leap to a Windows/GUI integrated development environment on NT or to stick with what we knew to be a favorite among high-end professionals (especially those in Apps), which was a character mode IDE, or could we make something work on Windows 3 (and how). There were schedule questions (and chicken) and also technology questions.

There was an enormous deck with insane levels of detail across marketing and engineering. Right at the start the first slide was labeled, “Decision” and an indication that the team was looking to Mike to lead the way.

MikeMap had a sage and entertaining way of disarming any room and imparting wisdom at the same time, and he was about to do that. He looked around the room and said, in his Oklahoman accent, “There’s a lot here . . . much more than I can absorb in an hour. How long have y’all been working on these foils and this problem?”

The room looked perplexed. MikeMap was still fairly new to most people, especially Languages. Everyone sort of mumbled in their own way, an indication that basically this is all we’d been working on for weeks or more.

Mike then said, “Y’all been working on this longer than me, and know more than I will ever know. Why don’t you just tell me what you decided to do and then we can move the project forward?”

It was an incredible moment and frankly the opposite of everything I’d been culturally prepared to hear. We all envisioned executives as people we went to for answers, especially BillG and the big architects. Here was the newest but most experienced senior person at the company, telling us to decide on our own. Classic Mike, as it would turn out. That single interaction made a profound impression, and it was the first of many lessons from Mike in this same spirit.

Nevertheless, we debated vigorously among ourselves in front of Mike (a mistake). At one point, from the gallery, I overstepped my bounds and pushed too hard and in too negative a way in favor of moving to Windows. At least in my head I thought what I was saying was obvious. Microsoft was a contentious place, but it also wasn’t in-your-face aggressive, especially around Apps, which had a far more refined culture than Windows (especially Windows NT). And definitely wrong to do in front of Mike. And from the gallery.

With all pros and cons aired, the team committed to building a Windows hosted toolset and to find a way to make things work for Windows 3.0, committing to a separate project optimized for NT later. Composer would be one part of a complete Windows development toolset, including a compiler, code editor, debugger, and so on. We were, at least we thought, on a path to have something credible to compete with Borland and NeXTStep. The meeting was tough and what people were really looking for was the right to own the target ship date if they were also being asked to create a new product. That’s what Mike could assure the team.

After the meeting, someone told Jeff that my participation in the meeting was poorly received. He summoned me and insisted that, by the end of the day, I personally go and apologize to the leader of the C++ dev team, Dave Weil (DaveWe) then report back. Sheepishly, I did what I was told. I most definitely learned my lesson.

Jeff was cool like that, perhaps due to his own experiences. At a time when Microsoft barely had any people management at all and most of HR was recruiting, I was getting a lesson. As I would soon appreciate, especially after Windows Word and with the arrival of MikeMap, an incredibly strong and maturing management culture had developed in Apps but still needed to make it to new people like me and to Windows.

It would come to define the teams I later worked on and how we (and I) aspired to lead.

With the tension behind us, we were in the final stages of shipping a Windows IDE, a new Composer, a complete class library MFC 2.0, and a tool for creating apps. This last tool was known as App Wizard, or AppWiz as we liked to call it.

AppWiz was our big demo. In an era where creating a Windows app could take days and required a 900-page book, a developer could with a few clicks and without ever leaving the comfort of Windows create an app. It was industrial strength and professional. We still had to prove to pros that this was not a toy app and was as powerful as writing a C app in the style of Charles Petzold’s Programming Windows book, the bible of Windows programming.

Taking a lesson from shipping MFC 1.0, we tracked daily the lines of code and size in bytes of MFC 2.0 but also the number of clicks, lines of code, and size of the “Hello World” app created with AppWiz. Our goal was to fit Hello World on a single page, or even better a single slide, without cheating or breaking the purity of the MFC app framework. We achieved this goal and it really wasn’t a hack or fake. In a just a few clicks, a fully functional program capable of having multiple windows, file open/save dialogs, help menu (that was important back then), and even an About . . . box (even more important since that is where the name of the programmers often went). The killer feature, which was even eventually employed by Netscape for Windows, was printing with print preview, notoriously difficult features. We made them essentially “free”—all the programmer needed to do was add the code for drawing his or her content on the screen.

Given the compelling nature of the demos, I was about to experience hand-to-hand combat in the world of software and developer tools. Borland was going all out to gain the upper hand, and with the beta release of what was being called C 8 (and what was in the NT PDC build) there was starting to be some grumbling about how efficient and “compliant” MFC was with industry standards.

The way this was done back then was two-fold. First, companies wrote detailed technical white papers of 20 to 30 pages and circulated them to the press and influential analysts. These papers served as background material and were used by writers as sources. They rarely saw the light of day because by reusing the content in them rather than quoting them directly all the analysts and writers seemed more objective and smarter. These white papers amounted to “gentlemanly trash talk.” This was sort of the air war of competition.

Second was the use of the old USENET newsgroups at a grassroots or hand-to-hand combat level. This was much more direct and much less polite when going after each other. USENET was a massive trove of the internet’s first worldwide bulletin board system. It was organized into groups much like today’s Reddit. There were several interesting groups for MFC and C++ with names like comp.lang.c++.standards or comp.os.ms-windows.programmer. Getting on the internet (technically this was pretty much all that was on the internet in 1991) from within Microsoft wasn’t easy back then so often I dialed up from home (or went downstairs to the lobby and used the fax line) and went through my own dial-up service (crazy as it sounds). Eventually the groups were available internally through a mirror site.

On these groups people posted arguments or rants about topics, and then a long argument thread ensued. I spent hours debating people, some anonymous and some from Borland even, over the esoteric aspects of C++ language syntax and rules or topics like the performance of MFC Windows programs. The old internet devolved the same way today’s internet does, only the tools change. Most discussions eventually end up in a stalemate or name-calling.

Eventually, I took matters into my own hands. Back from the Borland Developer Conference (BDC) in San Diego that I attended under an assumed name since my original registration was rejected as a Microsoft employee (Borland was like that), I wrote my first guerrilla marketing and technical buzzsaw taken to a competitive product. A technical buzzsaw was a favorite Microsoft technique used to look at a competitive product (or even code from another team) and quickly find all its flaws or weaknesses. At the conference, they were vicious and trashed the current release of C++ and the beta with MFC 2.0. All fired up, I wrote my first white paper, Borland C++ & Application Frameworks 3.0 vs. Microsoft C/C++ 7.0: An Exposé (A Draft Response Prepared by Microsoft Development). I did my best work to shred the Borland competitive assertions in a whitepaper they distributed at their conference.

This was the start of writing missives late at night in hotel rooms, which became a pattern for some of my best work (said humbly).

We just needed to ship. At least I shipped once, finally.

On to 013. End of the Beginning

Back to 010. Our BillG Review

Finally, in the Spring 1991 we had clarity on our platform mess, but complexity in how to move forward. I get promoted to a lead software design engineer. I worry about getting fired for ordering T-shirt. We “rm -rf” all that old work so we have a clean slate and refer to all of that as “Old AFX”. We are building tools for Windows, running on Windows, and a class library that was dedicated to building Windows apps.

Note: This is a bit longer than I expect sections to be normally. Lots going on in a short time.

With our BillG review completed we needed to regroup. We knew what we did wrong technically, but we lacked a strategy to build a product that involved target customers and product goals. We were a technology team in search of a problem. Microsoft’s strategy was coming into focus and Jeff set our small team up to be the glue by amplifying our efforts. We needed to ship. Shipping is everything.

The traditional C compiler team was working on C++ after the death march release of C 6. They were making progress on what was an enormous task. The team of about two dozen brilliant compiler and code-generation expert developers added Martin O’Riordan (MartinO), who pioneered the implementation of many of the esoteric features of C++ in the Glockenspiel compiler (the one we had been using for ET++ and AFX). The team was making significant progress at the core compiler technology and immersed itself in the language standardization process ensuring Microsoft had a front row seat for C++.

Windows 3.0 shipped and exceeded any and all expectations. Pre-installed sales in its first few months shot up to more than one million copies. By the time our BillG Review happened, Windows 3.0 sold twice that or more. Work was well underway for the successor, Windows 3.1, which would make substantial progress in using the latest Intel processors, significantly improving networking and file sharing, and adding new user interface APIs that would make building Windows programs easier.

Its success meant that our strategy was handed to us. With all the conflicting goals and external relationships, knowing what to do or having a feeling about what made sense from a technology perspective is not the makings of a strategy. Strategic shifts, like the one BillG orchestrated with the transition to GUI in the first place, take clear, top-down, direction. We had anything but that, still.

Windows morphed into Microsoft’s main strategy, from a side project. While the Apps team was already heavily invested in Macintosh, when it came to Microsoft’s operating systems we were inconsistently spread across MS-DOS, Windows, and OS/2.

Often, in times of strategic turmoil or doubt, a few simple observations on the state of the world expressed plainly can lead to an effective strategy, removing ambiguity and doubt.

Our team knew we needed something to compete with NeXTStep and we knew we were going to use C++. We had two big problems.

First, AFX was given the mission to develop tools for all of the platforms Apps might build for, which included Windows (which at the time would always mean some of the older versions and the newest ones), Macintosh (where the money came from), OS/2 (because that was the company strategy), and even MS-DOS (where most of the customers still were).

Second, we had been strategically focused on professional developers, which might not sound like much but implied many things about the product such as using character-based tools instead of GUI and not worrying much about how easy it was to write programs. The most important apps of the new era were being written by professionals, not hobbyists, but now Borland was attracting professionals.

We were hamstrung by the perceived need to cater to professional developers who were focused on the complex Microsoft platform strategy of MS-DOS, Windows, and OS/2. How could we pick one without breaking the strategy? Who were we, the small group in Apps, to make such a decision?

The answer was right in front of our faces. Windows 3.0 sales surpassed Macintosh sales. In the entire first year, Windows 3.0 sold about 4 million units, almost twice the number of Macintosh computers sold and over twice the number of all Windows units sold previously since 1985. Windows sales were doubling in months and Macintosh was growing sporadically but about 30% per year on average. The rest of MikeMap’s Apps organization turned to focus boldly and clearly on Windows (and Macintosh) at the expense of MS-DOS and OS/2, which led to only one conclusion: Focus our efforts on Windows. Borland was already doing that. Many application vendors were starting to do that (except for the biggest ones). The situation for programmers was rapidly becoming one where if someone was building a new app, then it would be on Windows. For existing companies, the question was not if the focus would shift almost exclusively to Windows, but when. Even Macintosh started to be questioned in some commercial circles, simply because of the growth rates and urgency around Windows.

This change happened in the span of months and was as dramatic for us as it was for everyone, including our friends and co-workers in Systems. In Systems they were still trying to get OS/2 to work and executives were still navigating a relationship with IBM. That relationship had cooled substantially in public with increasingly political statements being made about who would support what and when. Rather than clarify a partnership, these began to clarify a reality. Windows was the breakout. Everything else was going to be left behind.

This was a classic case of the internal situation making something seem bold, but from the competitive marketplace the choice was obvious. Windows.

The summer of 1991 would prove to be a pivotal time for Microsoft and the industry. In hindsight, this was most decidedly a moment along with a memo to prove it and decisions around that. Rarely in corporate evolution do incredible successes so easily connect to specific dates and choices, but Microsoft’s early years seemed to be marked by several BillG moments. Microsoft, just a decade earlier, closed the deal with IBM and the single decision to codify Microsoft’s right to license MS-DOS to other PC makers was documented in a succinct business plan memo. And just a few years after that, Microsoft stopped building new applications for MS-DOS to focus on GUI at an offsite led by Bill. It is amazing that the most early and key strategic choices the company made could be connected to specific events and moments in time.

In the Spring of 1991 BillG set aside a week, as he was doing regularly, to get away and update himself on the latest technical developments, called “Think Week.” As I would learn personally in just a few short years, most of the time was spent deep in reading, but he would also commit to writing. This particular week, deep in the success of Windows 3.0 and ongoing development of Windows 3.1 and the ongoing frustrations of OS/2 development, he took a step back to consider, and decide, Microsoft’s big platform bet.

As I would come to learn this was a prototypical BillG memo. It was a series of seemingly unrelated points, usually detailed in a bulleted list, each with a block of strongly imperative and candid text. It was also, for lack of a better word, a bit paranoid (especially in hindsight when one considers all the issues). Yet when reading the memo in the context of the moment, it is clear that while these might be a bit of a laundry list of everything he was worried about, it is just as much a list of all that must go right for a strategy to be successful. Bill knew more than anyone just how fragile the world of software can be to companies. While I’m forward referencing a bit, he was fond of saying that a company’s most difficult times are seeded when things appear to be going perfectly well. The list of just PC software companies in decline or that vanished was already long.

Bill detailed this strategy in the widely read email he originally sent to only the executives, but quickly raced around the company (and is now online due to leaks and also the discovery phase of litigation where some of our best emails are now available). Microsoft had always been an exceedingly open culture when it came to mail forwarding or including others in email. This was from the top-down. BillG, more than anyone, overshared, whether on the CC line or simply forwarding and asking for views then forwarding those views to others. I did not personally know this yet, though had already seen many BillG mails.

In the same way that DEC’s strategy for the ’80s was VAX—one architecture, one operating system—our strategy for the ’90s is Windows—one evolving architecture, a couple of implementations. Everything we do should focus on making Windows more successful.

Bill Gates, May 16, 1991

This was the first BillG Memo that I saw, and in hindsight it showed the deep thought that Bill put into focusing the company on Windows in a time of change. The May 16, 1991, mail also made it into the San Jose Mercury News and Wall Street Journal and then even into some of the trials and tribulations with regulators. I was too naïve and too much of a true-blue believer to even consider the negatives or theories in the press on what was significant. I took the memo at face value. The memo was abundantly clear. “In the same way that DEC’s strategy for the ’80s was VAX—one architecture, one operating system—our strategy for the ’90s is Windows—one evolving architecture, a couple of implementations. Everything we do should focus on making Windows more successful.”

The press mostly focused on the sections of the memo expressing concerns about competitors. The Wall Street Journal headline was “Microsoft Founder Gates, in Memo, Warns of Attack and Defeat by Rivals” and discussed the widening rift with IBM, even saying Microsoft “lashed out” at IBM. The memo’s ever-present competitive tone using war-like terminology such as “attack” and thinking through competitive battle scenarios were too exciting to be omitted from coverage.

The simplest summary is to repeat our strategy in its simplest form -- "Windows -- one evolving architecture, a couple of implementations and an immense number of great applications from Microsoft and others.

Bill Gates, May 16, 1991

In fact, the memo codified what the market had seemingly decided—the winner was Windows. Bill was clarifying, crystalizing, and emphasizing that point with specific calls to action. He made sure that everyone knew OS/2 was no longer a priority and that we now had a strategy that was entirely Windows. In concluding he restated this as “The simplest summary is to repeat our strategy in its simplest form – ‘Windows’ – one evolving architecture, a couple of implementations and an immense number of great applications from Microsoft and others."

For most of us in Apps, the part that seemed more newsworthy was a clear mention of what until then was simply known as “Advanced Windows” or usually OS/2 3.0, was now a full bet on Windows and that Microsoft was no longer committed to making the imminent release of OS/2 2.0 a priority. The memo acknowledged that the relationship with IBM would be difficult but optimistically noted that Microsoft would come out a bigger and stronger company no longer successful simply because of support from IBM.

The "a couple of implementations" is a somewhat humorous reference to the fact that our NT based versions and our non-NT versions have a different code in a number of areas to allow us to have both the advanced features we want and be fairly small on the Intel architecture. Eventually we will get back to one implementation but it will take four years before we use NT for everything. I would not use this simple summary for outside consumption—there it would be more like "Windows—one evolving architecture with hardware freedom for all users and freedom to choose amongst the largest set of applications.

Bill Gates, May 16, 1991

In hindsight there is a fun section in the memo where Bill points out the reality that Microsoft currently has “a couple of implementations” of Windows technologies and it would take “four years before we use NT for everything.” It would be almost ten years and eight or so releases of the two different main code bases to get to one operating system code base, Windows XP.

The bet on Windows, the bet on what was now becoming known as simply NT internally was now clear. While initially NT was an abbreviation for “New Technology” it was common knowledge that we were not to confirm that brief history and to say it is just the two letters (something about lawyers and trademarks was the hallway talk). Literally overnight the efforts around OS/2 and MS-DOS fell from most everyone’s plate and certainly all new projects reset their focus to be Windows.

Where did that leave our AFX effort and competing with NeXT? The memo also pointed out that the most important differentiator between operating systems and most important criteria for winning in the market would be “hardware freedom for all users and freedom to choose amongst the largest set of applications.” It was our job in AFX to build the tools to enable the largest set of applications to exist.

Our challenge was that the C++ product team, managed in a different group reporting to MikeMap, did not have it so easy. Unlike AFX, which had no existing code or commitments, the C++ product group was committed to delivering the C++ compiler which was becoming essential for the creation of NT and to deliver C++ for Windows 3.1 and later. That support was for the professional tools, professional in the sense that they were character-based command line tools.

Oh, and Windows NT already had a target ship date towards the end of the year. This was an experienced team that was making progress. There was a real urgency to have C++ tools for the upcoming developer preview release of NT. Microsoft was already planning a big conference for professional developers and part of that conference would be a preview of Windows NT and the tools required to build applications.

There was a lot going on and while the strategic shift was clarifying, the next level of detail when it comes to figuring out the ordering and priorities of projects still needed to be worked out.

At the same time, there was no way for us to build, from scratch, an entire suite of GUI tools competitive with NeXTStep in the months remaining in 1991. Jeff was a master at schedules and understanding where groups really stood relative to where their optimistic plans were—he lived through 10 years of app schedules and death marches. Plus, the C 6 team just shipped after their own march and they needed a significant update, C 6.0a, to address concerns that the initial product was buggy.

A key insight Jeff brought was directly connected to his experience working with Apple and Steve Jobs, most recently reflected in ChrisP’s “Shipping Software” tech talk. The idea that being grand architecturally is a distant second to being pragmatic and shipping product. Steve Jobs famously rallied the Macintosh team with the mantra real artists ship, a play on Picasso’s famous saying, “Good artists borrow, great artists steal.”

Jeff told us to put our oopaholic problems aside and said, “Enough is enough. It’s time for us to ship.”

Like all lofty goals, we needed to break the project down. There was an obvious step to take. First get C++ done, which was necessary since our tools were built in C++. From there, we could build the Windows GUI tools in C++ and fully bootstrap or self-host. This two-step plan also created an opportunity for our AFX team to ship “something” or “anything” with the forthcoming character-based C++ compiler.

The C++ compiler coincidently needed something as well. Borland was busy building an application framework. Microsoft had none. Borland led the way in telling a new generation of programmers how to use the latest in object-oriented tools to build Windows programs, on Windows. That meant Microsoft was ceding control of the actual platform it was creating to Borland.

When it came to class libraries, we still needed a philosophy or point of view that helped to guide us—all we had was a failed oopaholic view. That’s where my experience at USENIX came in. Returning to the slides I presented, as per the JeffH requirement, after laying out the context of the conference one slide was all that mattered.

Restating my conference lesson, I put on a slide “C++ is a programming language not a religion.” Certainly obvious, but not to anyone on the leading edge of technology who believed that C++ required a new way to think about programming. I went on to say that the lessons I took away from the conference were that C++ was a better C, not a new way to do everything. The most effective way to use C++ was to stick to a “sane subset” of the language, which was basically heresy to all the people advocating for adding new features and complexity to the language. While the Languages team was required to implement the public standards (which were being developed at the time and we were active members of the ANSI committee), there was no reason for our own class library to serve as a “compiler test suite.”

This philosophy of C++ minimalism was the first step in building our class library. The second was the impetus of ScottRa and RickP. Both had built many layers to insulate people from variations in different operating systems and platforms and both knew the cost in memory size and code complexity that comes with that. While it always seemed like a good idea at the time, eventually the team building the layer found itself having to do as much work as each of the operating systems. That meant a small effort turned out to require two or three times the effort of some large teams, which were, effectively, competition.

Given the realignment of MikeMap’s Apps division around Windows versus being everything to everyone along with our newly minted religion around C++ minimalism versus oopaholism, we had a strategy. We would build tools for Windows, running on Windows, and a class library that was dedicated to building Windows apps, not an academic exercise in OOP.

During a doorway conversation with Jeff, we discussed how we would ship. We were trying to find a way to break down the problem to give the team time to build our NeXTStep competitor. Jeff asked if there was a way to ship part of the class library with the forthcoming C++ compiler and then ship the rest with an update that included the new GUI tools.

In hindsight, I think Jeff knew the answer. Yes, we could. Still, I gave him that answer. Our ideas for a minimal class library could easily be partitioned into parts applicable to Windows and parts that were more in line with the focus on the first C++ release that was about character mode. We sketched out what was known as the class hierarchy based on what we called foundation classes and Windows classes. These foundation classes would be the minimal product we could ship in time for the developer conference, and would simply give a bit of a flavor of the class library to follow. They weren’t even all that helpful for writing Windows programs…yet.

Jeff asked if I would lead the near-term project—the first release of AFX that was aligned with C++ 7.0, the obvious next name for the compiler product.

I had no idea what lead meant except that I was being asked to ship, and that was exciting. I still reported to ScottRa, but Jeff promoted me to manager. One day I was not a manager. Then I was. At first, I thought, Wow, everything is going to be different. Except at Microsoft in those days, especially working for Jeff, that was not the case. Jeff’s idea of a manager was to take people who were so productive that they could do the previously required work but also have enough extra time to manage. The management part was an add-on. There was no such thing as a manager who didn’t also code. ScottRa was a full-time developer. So was GarthH. Everyone was writing code. Managers just did some extra stuff for a half a day a week or so.

My first direct reports were RickP and Eric Schlegel (EricSc). Eric recently graduated from Dartmouth and knew everything there was to be known about Macintosh. RickP, a pioneering engineer on the Excel team who created much of the layer of code that helped Excel work across Windows and Mac, was a legend. While we became great hallway friends, the idea of me managing Rick was absurd. I had literally nothing to offer him. Rick wasn’t looking for anything, though, and it ended up being a great chance for us to officially hang out. He knew the work that needed to be done and wanted to do it. He was better at it than anyone else. Eric was going to work on some Mac-specific tooling as part of a broader project that remained in place.

We defined a project and built a schedule. Next, we needed to ship. We needed to create a source code project, an SLM project. In a symbolic gesture of ridding ourselves of the past evils of oopaholism, we created the new afx source code project, deleted the old project, and, for good measure, I deleted the last copy of the code: “rm -rf afx”. That wasn’t quite the command for the source control system but became how we symbolically told the story of becoming recovered oopaholics by using the well-known Unix terminology. I deleted all the files from our failed project, which we started referring to as Old AFX.

We had a clean slate.

But first things first, we needed a T-shirt. Without a T-shirt there was no way to start a project, and frankly that explained a lot about the previous years. Getting a shirt in those days was no easy task. First, it had to only be one color because silk screening multiple colors was prohibitively expensive. Second, a big deposit was required as was a commitment to a certain quantity. There was a place by the Kingdome, in industrial Seattle, where we went to check proofs. It was crazy.

I needed a design. The lesson that came out of the BillG Review for us was that we had not been in tune to the market while at the same time we were sloppy. At the time my uncle, a banker, was working at Prudential, which had the slogan, “Rock Solid. Market Wise.” I called him up and asked him to send me some letterhead or a poster or something (there was no internet). I received a big FedEx tube the next day (wow!) filled with all sorts of slogan items. At the Microsoft library I made a scan of the logo using the public scanner. Using Windows Paint, I added “Microsoft Foundation Classes” across the top of the Rock of Gibraltar along with the (trademarked) Prudential tagline. Then our group’s administrative assistant, Kathleen Thompson (KathT), who later contributed to the thousands of pages of documentation as a writer, guided me through the process of getting a T-shirt made.

There was one problem. I did the classic Microsoft thing of acting first and not asking permission. Thinking about the minibar incident, I chose to pay for the shirts myself and work it out later. I wrote a check for $450. Two weeks later, we had T-shirts. And apparently, we also named our first product. Microsoft Foundation Classes (MFC), which I came up with for the shirts, had stuck. We were building MFC 1.0.

I proudly gave Jeff a shirt when they arrived. His first comment was not “Did you get permission for the logo?” but rather “Who paid for these?” My answer was “I did,” and before I managed to ask for reimbursement he smiled and mouthed, “Good answer.” It was a different era. People thought of company money differently, as if Microsoft was still a start-up, and as crazy as it was to pay for T-shirts, I understood Jeff’s point as we started to see the spending all around the company increase. A few weeks later, a reimbursement check (a physical check) arrived. Jeff worked the amount out with KathT.

Coding the project was a whirlwind through the next few months. The Languages team worked under a deadline that wasn’t realistic, but we were only a small deliverable to their big project and were not in a position to play schedule chicken, a common description used when two groups shared an unrealistic deadline.

Surprisingly, decision-making clarity came from having a clear point of view, a tight deadline, and constraints. This idea of a “clear point of view” was something Jeff instilled in me during one of our many conversations. He would use the expression to highlight a unique perspective or belief that defines a product, or guiding light. It was new to me, though years later I understood why it was referred to as a North Star.

While this was all happening to me, it was also changing me. While I was on the job for almost two years, I had not really transitioned from graduate school to industry. And then I did, and it happened fast. Big and small things were happening to the product quickly too, seemingly all at the same time.

We had to choose naming conventions for objects in our source code—what the code looked like in books and what happened when thousands of programmers typed each day. This was essentially a life-or-death struggle and picking wrong could be legitimately alienating. Microsoft Apps championed a specific and rigorous naming convention called Hungarian, which we learned in ADC. It was pioneered by CharlesS and was his Stanford PhD dissertation. Windows took Hungarian and basically broke it in ways that made Apps people cringe. MFC was both a new language with many new idioms and straddling the world between Apps and Systems. But time, pressure, and clarity of mission made it simple, and we picked a few conventions that came to define C++ for a generation of programmers: Classes start with a C as in CString; member variables start with an m_; and everything starts with our main class CObject, which was super lean and had no memory cost. That was the whole oopaholic philosophy swung 180 degrees from conventional wisdom. Also, when it came to tabs versus spaces, we chose correctly.

What previously took weeks, we dispensed within a day.

Scott and I worked on diagrams for the class hierarchy, sort of a family tree of the product. We drew them in PowerPoint, which only had basic shapes then and didn’t even have good alignment tools, and then at night I took them to the all-night Kinko’s on Capitol Hill where they could make copies the size of posters. Class hierarchy posters were the currency of the C++ world, and we had the best.

Sticking with the RickP philosophy of not duplicating code from Windows, we made a lot of choices that went against what people hoping for cross-platform code would have liked. We used existing Windows OS implementations for most everything in MFC 1.0, including files, strings, and more. If the intention was running this code on another OS then it meant basically implementing those parts of Windows. It wasn’t about being sneaky, it was about being efficient for people writing Windows programs, which we felt was where the world was heading. It was our strategy to make Windows programs efficient and easier to write.

We decided that for credibility with developers we would ship our library source code. Microsoft never shipped source code and guarded it closely. In this case, though, Jeff thought this was important and supported us. This meant, however, that we needed to make our code pretty and free of the kinds of things that routinely peppered the code of Microsoft products—comments like //BUG or //DON’T TOUCH THIS CODE. As part of this we also chose to use the Afx prefix in the code as well, which ended up being the source of many rumors trying to discern its meaning.

Finally, we were absolute zealots about performance and memory usage. We were running on 16-bit computers with Windows 3.0 and memory was tight. RickP taught me a bunch of ways to measure and report on memory usage that I not only implemented but reported out every single day. Every night, late, I mailed out the changes to the project in lines of code, size of compiled code in bytes, and size of the most trivial program, “Hello World.” Displaying Hello World on the screen was a technique pioneered by the creators of the C programming language. It allowed programmers to compare programming languages (which they loved to do) by looking at the simplest program.

If something went in the wrong direction, we were required to explain it. Every. Single. Day.

While this was going on, we were helping the compiler team to ship. There was a massive amount of work to build a C++ compiler and we were one of the only products under development using C++.

Since we still needed to compete with Steve Jobs, our team was simultaneously working on an even bigger project. Version 1.0 of the Foundation classes were a fraction of the scope of what we needed to get done.

On to 012. I Shipped, Therefore I Am

Back to 009. Password is NeXTStep

The story of my first BillG review, except I’m too junior to attend. Soon I will find myself doing nothing but BillG reviews for almost two years. For now, I had to sit out this transformational meeting. All is not lost as I was on my first business trip which also proved transformational.

Jeff scheduled a BillG Review for a week or so after App Month. I could not imagine why as we had nothing to show so it seemed like an opportunity to get yelled at. Still, Bill was anxious for our progress and Jeff, having learned some valuable lessons about overpromising, was careful to moderate Bill’s expectations. But the prospect of a looming BillG Review was intense, I quickly learned.

In 1991, a BillG Review was a big deal, a really big deal. The company was large enough that most teams were not having routine (say monthly) in-person contact with Bill (though email was nearly constant), but it was also small enough that he knew most of the key developers and program managers, especially on the main products. AFX was a main product, sort of as it had the attention of one. Our team was small and I was too junior and never shipped anything so obviously wasn’t invited. I felt left out, but I also relieved. I was too new to be called stupid or to say “the dumbest thing” BillG ever heard. I had not established my “IQ”. These were all examples of well-known Billg-isms, right up there with rocking back and forth in his chair. But still I felt I was missing out.

The team was supposed to show Bill our progress and how close we were to state-of-the-art tools for GUI and beating Steve Jobs at his own game. Any indications of progress were poor. Our code was big and bloated. Our tools were not revolutionary. We could not create GUI programs quickly. But we understood the existing tools well. We wrote many memos on how NeXTStep, Borland, ET++, and several other commercial products were superior to Microsoft’s lack of products.

Jeff knew Bill and understood how he worked better than most anyone. Jeff asked us to put together our materials—literally printouts of code, APIs, benchmarks of memory usage, competitive product briefs, and more—and assemble them into a binder. Back in those days a “good” review came with a big binder of papers that were sent over a day or so before the meeting so Bill could prepare. Bill read everything. Bill remembered everything he read. Jeff knew we had to be buttoned up, of course.

We also knew we had been poor engineers.

I spent many evenings standing in RickP’s doorway talking and learning from him. Rick was the nicest, most thoughtful developer and, at the same time, he was unbelievably hardcore, the ultimate Microsoft accolade for a developer, focused on every line of code, every byte of memory, and every CPU cycle.

Ahead of the BillG Review, he did a group presentation summing up his App Month. He had slides—everyone was flummoxed! Rick never made slides or even led meetings. Our conference rooms had overhead projectors so when we used slides (which MikeMap referred to as the IBM word foils) we prepared them in PowerPoint (or Word), printed them out, and then photocopied them onto transparency pages.

The title of Rick’s talk read, “What Would Make Rick Happy?”

Through a series of slides, Rick took his perspectives of building real shipping apps and his hardcore focus on performance and reliability and defined a broad set of criteria for how a reusable framework should be built. He played back all the choices made on the Excel layer system but applied them broadly. This presentation hit me like a 16-ton weight. He converted me to a performance zealot in 20 minutes—a transformation of the highest order. Whenever I encounter a buggy, slow, fat product I think back to how unhappy that would make Rick and ask myself, “What Would Make Rick Happy?”

In addition to being hardcore about performance and bloat, Rick made a number of incredibly astute observations that would carry great weight moving forward in terms of distinguishing our product. First among those was that we tried to “fix” the operating system. We took building a cross-platform framework as a chance to cherry pick the best concepts from each target operating system, or more likely simply our favorites. We thought of that as making a new and better OS. In fact, it was just different.

Jeff had a great way of describing this both to BillG and back to us. He would remind us that the OS groups were huge teams of 100 engineers compared to our team. How could our tiny team possibly “compete” with those big teams at designing an operating system. Even more straightforward, was how could our team of one contract documentation writer compete with the dozens of books about programming Windows, Macintosh, or OS/2 that filled Tower Books. There would never be enough to learn about our framework. What is amazing about this point is that literally every framework was doing this same sort of fixing of operating systems. Even more amazing, this tradition of cross-platform tools inadvertently creating new platforms without the resources to maintain or document them, or even to be competitive continues to this day.

Rick also had some other observations about working with an operating system that proved especially important as our strategy would unfold after the BillG review. In particular Rick cautioned about redundancy and reimplementing concepts already in the OS. A common example was how the OS maintained a list of windows but so did the framework. Not only was that more memory, more code, but it was a chance for the two lists to disagree, and introduce bugs. The whole concept of not maintaining copies of information the OS already had was critical to performance. If an app needed to know something then there needed to be only one place to look.

In general these observations, rules if you will, formed the foundation of what was to come. They were more than observations or theories, however, as we learned them from our experience building the framework that didn’t work. Jeff felt leading with what we learned was a key way to engage BillG on failure. These concepts proved the core of what we learned.

Up until that point, I had almost exclusively only interacted with other software design engineers, developers or devs as we called ourselves. A unique role, particularly in Apps, was Program Management or PM. PM originated in the Excel team as a role responsible for making sure the product being built was easy to use, met the needs of customers, and achieved business goals. The role came about as a way to make sure developer schedule time would be used more efficiently by avoiding false starts and rework, while connecting the dots between the ever-increasing number of features.

Prior to the introduction of PM, most debates about what to build were settled by the developer writing the code and based on what they felt was right, however they defined right. If it didn’t work out then it would be rewritten. If developers did not agree, an endless email thread ensued, and continued until someone got bored or more likely the most forcefully expressed point of view would win. We called this pre-PM era “testosterone-based development”. PMs created processes reflecting customer needs in the product, at least something more than just asking friends in the hallway which constituted feedback and planning in the early days. PMs also represented the product to other teams and was generally viewed as the face of the team, even though they were peers with development and also software test engineering.

Generally PM led the BillG Review. Clif Swigget (ClifS), who joined from the Macintosh apps team where he worked on a well-known database product called Microsoft File, jumped right in. What a challenging way to begin. ClifS and the team were as ready as they could be for a meeting where we basically had nothing but a year’s worth of learning to show. BillG was not likely to be impressed by mere learning.

To sum up our learning we referred to our “condition” as oopaholism. That’s how we described ourselves to BillG.

We drank far too much of the object-oriented programming Kool-Aid, using techniques and approaches that might be good in academia or look great on paper but were wholly inappropriate for building industrial-strength, commercial software at scale. Maybe this was naïve, but every new wave of technology comes with it a certain amount of religion and zealotry, even if it isn’t immediately practical. There was an optimism that the new way would solve all the old problems and be better, faster, easier, and cheaper. In reality, things almost never worked like that. OOP proved itself to be more of a passing fad and a lot less than a whole new approach. OOP influenced everything to come but was not the change-agent the zealots believed it would be. A recurring theme in new technologies is how often the first try at something serves, to a much larger degree, as inspiration and influence rather than as a foundation for implementation.

My contribution, entirely a failure, was about to go through my first BillG Review, and it terrified me. Not only was I not at the meeting, but I would be out of town when it took place. That was a blessing, as it turns out.

While it was happening, I attended the 1991 USENIX C++ Conference in Washington, DC. As conditions for attending, Jeff insisted that I fly coach, book a cheap room, eat no elaborate dinners, and, above all, I was to write a trip report and lead a group meeting on what I learned when I got back. It wasn’t just that Jeff believed we should spend Microsoft money like it was our own last dollar, but that spending should result in a contribution to the group not for the benefit of one. The worst part: I was OOF for a couple of days. OOF is common tech community jargon originating back with mainframes meaning out of [computer] facility that also had a specific implementation in Unix email where you could leave an automatic reply message with the details of the absence. I edited my .oof file saying I’d be back by the end of the week and detailed the conference I was attending. Before the broad use of mobile phones and laptops—a ubiquitous Compaq LTE laptop was still more than a year from reality—I was able to check my voice mail using my Microsoft AT&T calling card, something I’d do at the inevitable layover at the ORD United terminal. Those were the days?

The conference seemed small, and everyone seemed so grown up. They had big titles, like chief scientist and vice president, and they were with big companies, like AT&T, IBM, General Electric, and Texas Instruments, but unlike me, they were real adults. It terrified me. I made the rounds, booth to booth, sporting my first ever conference badge with Microsoft affiliation, and in the small hotel ballroom used for the main session I quietly sat in the back row, quiet and intimidated.

Over the course of the conference, about twenty papers were presented, and all were extremely relevant to what I was working on. Long before there was Linux, there was UNIX, the famed operating system from 1970s AT&T Labs favored in academia and research. USENIX was more of a bottom-up conference of system administrators, programmers, and scientists, all working on the leading edge of the UNIX system, not a highbrow academic conference. The C++ language originated from this community, and the first gatherings focused on C++ language design were hosted by this group. Unlike the strictly academic conferences I followed in graduate school, the USENIX conferences were geared toward industry or at least non-tenure track faculty.

The debate at the conference centered around the controversy over evolving the C++ language, which at the time seemed premature. This was a language almost no one was using commercially and with almost no tools support beyond UNIX, but that’s the world they worked in. Contributors debated the use of “proposed” C++ features such as multiple inheritance, templates, and even my old favorite, garbage collection. All the while there were reports about new class libraries being developed everywhere.

In one small session, Martin Carroll, a well-known AT&T C++ proponent, gave a talk on some detailed aspects of the language, and toward the end in Q&A someone asked about using the feature in their code. The answer was something I would use for years. “You’re writing code for your product, not a compiler test suite,” meaning the presence of a feature in the language didn’t mean it had to be used. There was no reason for code to touch every language feature. This presentation later led to my own version of “What Would Steven Like?” My thoughts were racing with ideas to develop a set of rules to govern our use of C++ while making sure RickP got what he wanted for performance.

When I got back to the office, I was anxious to hear how the BillG Review had gone. Unsurprisingly, my voicemails pining for details had gone unanswered.

Was BillG in a good mood? Did anyone say the “stupidest thing” BillG had ever heard? Was there yelling? Did anyone get called “random”? Maybe someone was called “high IQ”?

A BillG Review was generally viewed as an exercise in survival more than an opportunity to shine. At least that’s how we, the broad base of people who only heard about the meetings after the fact, perceived them.

I walked the hallways in search of the scoop. Given that we had nothing to show and that Bill was anxious to compete, ScottRa, who attended the meeting, said that it went “as well as could be expected.” He said there was no yelling but a strong sense of disappointment. Jeff, I was told, took the brunt of the negatives and discussed many of the challenges—tools that didn’t yet exist, cross-platform development, new team, and new technologies. ScottRa said we needed to come up with a plan.

Finally, in a hallway chat, Jeff later reiterated that the meeting was rough and Bill was disappointed but he “behaved,” and that Scott and others did well. The meeting was replayed a dozen times that day pairwise. Each of us must have heard the story several times from each participant, trying to gauge the tone and every nuance. It was like hearing about an amazing concert that I didn’t get to attend, but instead of music it was my future career at Microsoft.

Jeff detailed the meeting summary from BillG. It was not the kind of summary anyone expected.

He said that Bill concluded the meeting by saying something like, “It is disappointing that we haven’t made the progress we would have hoped. But it sounds like the team has learned a lot while making many mistakes. The thing we can’t do is make those same mistakes again while we come back as soon as we can with a product that is competitive.”

That sure didn’t sound like the BillG we were all terrified of.

As Jeff explained, Bill appreciated learning and understood, if not embraced, the failure that could happen while learning. While at events like intern parties or new hire gatherings he often told stories about appreciating failure (like Xerox not capitalizing on the invention of the GUI), he never seemed to use examples of failure from within Microsoft.

It was a relief. It would also foreshadow that the caricature of BillG was not always the same as BillG the manager, leader, and CEO. At least I had one counterpoint.

I still had to give a presentation on my trip. My presentation about what I learned was presented as a series of new rules for using C++ that we should follow. I won’t dull down this exciting story with a diatribe about programming language design but suffice it to say we took to heart the idea that as powerful as OOP was, using C++ as a better C would be our hallmark. We would apply RickP’s and the Microsoft hardcore ethos to OOP. I don’t really know what made me assert all this stuff in what was supposed to be a trip report. In hindsight, I think I was just totally jazzed by attending a conference and also in a bit of a panic over what was now coming up on my second anniversary with no shipping code. Maybe it was just that we made it through the BillG review, though that was all Jeff’s doing.

From that point forward, we became reformed oopaholics. AFX was the hardcore OOP group. We still had no product plan, but as a team we lived through a failed project and as I know now that is something that can become a team building experience. I don’t think BillG was thinking about that point, but Jeff certainly was.

Not only did we survive what should have been a horrible meeting, but at least by Microsoft standards it was motivational. We were given license to regroup, plan what to do, but to execute quickly. We needed a focus.

Focus was difficult to come by given how many operating systems or platforms we were on the hook to support. NeXT only had to support one. Apple Macintosh only supported one. Microsoft was, on its own, building MS-DOS, Windows, OS/2, and supporting Macintosh, and more…

Shipping would clarify things. Shipping was everything. This was just sinking in for me. If you’re not shipping you’re literally not doing anything. Excel 3.0 had just finished. This was the version of Excel that took advantage of Windows 3.0 memory management and also worked on the Macintosh. It was an amazing product.

It also shipped 11 days later than its original schedule. A noteworthy event. A memo was circulating about a talk Chris Peters (ChrisP) gave as a TechTalk to developers. I did not know Chris personally, yet. He was already a legend in the hallways and JonDe’s manager. His talk was Shipping Software On Time and by all accounts he was the master of the new shipping software religion in Apps based on leading the Excel 3.0 project. The memo hung on my relite for years (yes, my relite was crowded). This memo meant everything and was also everything we were not doing.

The essence of the memo was commitment and accountability to a ship date, not a target ship date, not a date like “first half” or “second quarter.” Those were, as Chris would say, “180 dates” or “90 dates”. There are many variables in a project, the ship date cannot be one of them. He went on and on about shipping. Everyone on the team has one job, “SHIP PRODUCTS”. And to really hammer the point he explained how everyone else comes to work trying to prevent a team from shipping. Hardcore. Hardcore Software.

We needed to ship. Something. Fast. On time.

On to 011. Strategy for the ‘90s: Windows

Back to 008. Competing with Steve Jobs (the First Time) [Chapter II]

It is only fitting that a post about an accomplishment by Steve Jobs would come on the eve of his birthday.

NeXT, founded and led by Steve Jobs, developed new hardware, a new OS, and, importantly, entirely new object-oriented tools to build programs for their platform. The computers were not selling well (yet), but there was a growing belief that the technology was unique and forward-looking. Due in no small part to Jobs himself, the industry stood up and took notice.

One person really noticed. That was BillG.

Steve Jobs was famously separated from Apple in 1985, and later created NeXT Inc. along with several key members of the Apple Macintosh team (he also started Pixar but that’s another story). NeXT produced three main products and had recently been refreshed with new models after the 1988 launch.

First there was the NeXT computer which was a blazing fast workstation class computer (along with an incredible display, fancy optical drive, and a laser printer). Second, was the operating system that ran on the computer, object-oriented (of course) with a graphical user-interface, called NeXTStep. And third, an incredibly rich set of tools for programmers to build object-oriented GUI programs for the hardware and OS, called Interface Builder. The whole product was launched in 1988 as almost a “super Macintosh” or at least was viewed that way by many. It was covered broadly across mainstream press because of the fascination with new home computers and of course Steve Jobs. By this point, many local newspapers were covering home computers as a regular section, something that seemed inconceivable just a few years earlier.

NeXTStep, while object-oriented, did not use C++ but a different object-oriented language which only made it seem cooler. BillG who believed strongly in having complete ownership of a programming language, thus his general reservations around C++ as I would soon learn, and his favorable views of Objective-C.

On my first college recruiting trip to Cornell in search of more Microsofties, I visited my old lab where many of the Macintosh computers were replaced with NeXT computers. Steve Jobs’ new company followed the same marketing plan that Apple followed with the launch of Macintosh, convincing a number of computer science departments to make a bet on NeXT. This would not be the first time a recruiting trip to Cornell would show me something unexpected.

ScottRa procured a NeXT computer, the new pizza box form factor (like a true workstation) and we would explore it late into the night, sharing our discoveries with each other and the rest of our team. It was truly a marvel of engineering and experience. It was amazing to me that a computer and software built from scratch could do so much (technically, much of the core operating system was built on a research project foundation from Carnegie Mellon University, known as Mach, which becomes important later in this story).

It ran at full 32-bits and running a variant of Unix under the graphical interface it rivaled the workstations I used in graduate school. It featured a level of sophistication in software and features that made Windows 3.0 PCs seem almost toy-like while having an ease of use of a packaged software product. It cost almost $10,000 1990 dollars and had minimal support from mainstream software makers who were already busy navigating MS-DOS, Windows, and OS/2.

Still the capabilities were so significant that NeXT was viewed as a major strategic “threat” (Microsoft, as I was learning, frequently used that to describe competitors). ScottRa explained to me the importance of competing with NeXT but I had difficulty grokking what that meant for our little team tasked with building cross-platform tools.

It became increasingly clear to me, however, why our source code server was named \OBJECTS. Scott cleverly named the share \DART, a joke that was lost on me for years. I’ll never forget the first time he told me the password. He said, “the password is ‘NeXTStep’, capitalized correctly.” Everyone by then knew it was “NeXTStep” or perhaps “NeXTSTEP”.

While I had no first-hand knowledge, the idea was in the air that BillG was frustrated at trailing a product by Steve Jobs. NeXT appeared to be a better product than anything Microsoft was about to ship or had planned for the foreseeable future. One of the things I am thankful for is having a direct competitor at such an early stage in my career. While how to compete was fuzzy, it was clear what we were supposed to compete with. Rumors of what BillG thought were cool or competing products or features would race around the company, and NeXT was one of those products. Microsoft was a product company, so the fact that it cost so much money or sold so few units was no excuse for not knowing what a product did or why it was viewed as good (and what we would do about it). BillG was (and remains) fiercely competitive and would often drive conversations about competitors in a relentless fashion, never allowing a team to dismiss one aspect of a competitor simply because of some relative weakness, no matter how overwhelming a weakness it might be. A product that is fantastic but not selling at all is every bit as formidable as your actual number one competitor, at least that is how we had to treat it when it came to BillG.

The rivalry between Bill and Steve was real. Everyone knew about it. We’d been through yearly company meeting updates on the litigation between companies and could read the trade press reviews of Macintosh versus Windows. That’s why our little team was funded. It was why our conference room had a NeXT computer costing as much as four developer PCs.

The Systems division was responsible for delivering the SDK for the platform, though they relied on the Tools team to deliver the underlying compilers and other tools. The SDK was supposed to make it possible to build GUI applications. Unfortunately, the tools were mostly the bare minimum and lacked the elegance seen on Macintosh and NeXT.

The Systems team, aware of NeXT and the high bar it set, staffed an additional, smaller team to build much more innovative and competitive tools for OS/2 and Windows.

I had no idea what they were up to. BillG did of course. But now Microsoft had two small teams chartered to compete with NeXT while the much larger teams in Windows and Tools were not focused on NeXT as a competitor. This struck me as weird, but what did I know?

Jeff Harbers (JeffH) had firsthand knowledge of the BillG–Steve Jobs rivalry. Jeff was the engineering manager for Apps and led many of the earliest Apps products back when the team was merely one group of developers assigned to projects as needed, much like a typical start-up. He was hired to bring a level of experience and engineering quality to Apps and was part of the founding Apps team at Microsoft. Jeff was the first person hired by CharlesS. He had been in the middle of many technical conversations between BillG and Steve Jobs during the development of the Macintosh and Microsoft’s commitment to delivering Word and Excel with the release of the Mac in 1984. Above all, though, Jeff had a well-earned reputation for being direct and accountable, with a strong commitment to excellence in engineering and quality—owing to his background in traditional mechanical engineering more than the hacker ethos.

Jeff’s email name did not have the first letter of his last name, because there weren’t any other Jeffs when he arrived. I thought this was kind of cool. But it drove BillG kind of nuts. Still, Jeff insisted on maintaining Jeff as his email, so BillG created an alias that directed email sent to JeffH to his Jeff account, just so he didn’t have to see “Jeff.” Years later with Microsoft’s more friendly email system, the alias JeffH was spelled out as “Jeff Harbers forwarding alias for BillG.” That was what happened when stubborn met stubborn.

Given his skill and experience and his understanding of Apps development, BillG tasked Jeff with merging the two teams and creating a new group to take on NeXTStep and to bring innovation and object-oriented tools like NeXTStep to Windows and OS/2 development. OS/2 was still top of mind in 1990.

This marked the start of a Microsoft entry into object-oriented development tools.

Because this team spanned both Apps and Systems and Jeff was an Apps person, the team reported to Mike Maples (MikeMap), vice president of the Applications Software division. Little did I know, but this spanning of Apps and Systems, while reporting to Apps, was quite a crazy structure and was a “condition” upon which Jeff would run the team. Microsoft was still a startup in the sense of the CEO creating ad hoc organizations around an individual.

MikeMap transformed Microsoft and set it up to be the product company it is today, quite literally. He joined Microsoft in the summer of 1988, as one of the earliest VPs at the company. So much of Microsoft culture today—that of Office, the quality of the products, and most of all the scaling of Office from a chaotic, infinitely buggy, siloed organization to one of the largest and most profitable software engineering product teams in the world—is a debt owed to MikeMap.

Mike was the opposite of the Microsoft archetype, older than most, having graduated from college in 1965 (the year I was born). He grew up in Oklahoma and attended Oklahoma City University and earned an MBA as well. Prior to Microsoft he worked at IBM for more than two decades. The news of his hire caused a lot of worry about blue suits, white shirts, meetings (with “foils”), and even songs (yes, IBM had corporate songs). The stories of IBM’s process were legendary at Microsoft because of the close working partnership between companies in Systems. Instead, Mike, with his disarming Oklahoma accent, showed up in plaid button-down shirts.

Both MikeMap and JeffH would become two of the most important mentors at Microsoft, for me and for many others.

Under direction of BillG, Jeff assembled a new founding team. It included two developers who I was in in awe of, Brad Christian (BradCh) and Rick Powell (RickP), and from Systems, Microsoft legend Neil Konzen (NeilK) and Garth Hitchens (GarthH). Plus me, the new kid. ScottRa reported to Jeff. He would quickly attract more from inside the company and we were soon about ten SDEs. BradCh was one of the main developers on Windows Word. RickP was likewise a key developer on Excel. NeilK was an original original, joining Microsoft while in high school biking over to the offices. He worked on the Apple Z-80 Softcard, Multiplan, Windows, and was leading the graphical subsystem of OS/2, and much more. Famously, Neil wrote the BASIC game DONKEY that shipped with MS-DOS originally. His initials, NK, were also embedded in every MultiPlan file as an identifier.

I could not resist making a quick video of DONKEY.BAS. This is running on original PC XT hardware under MS-DOS 1.1 in EGA graphics mode with 640K memory. Enjoy the sound, that’s the PC fan and 10MB hard drive [personal collection]

The charter of this new group was defined by the aggressive mission to utilize the latest in object-oriented C++ technology to provide tools and libraries for developers writing the most advanced GUI applications on the market. In the context of the time, this was wide-open and, importantly, had all the buzzwords that mattered—object-oriented, GUI, C++, and for Microsoft, developers.

I was new to corporate organization tensions, but they were readily visible. Alone, and having not done much for a year, I felt it. Between the two parts of our new team, the Apps Tools part and the Systems part, there was somewhat of a rivalry given we were jammed together in a typical corporate reorg. Add to that a concern about having Jeff as our manager—at least that’s what I was hearing in the late-night hallway chats.

A big deal at the time, though one that had played out before my arrival, Jeff came with some history that made some people uneasy. Back when Jeff was as an overall engineering manager in Apps, the most significant and somewhat out-of-control project at the time was the first version of Word for Windows. This project became legendary as both an incredible success after the fact and an incredible death march while it was happening. The project was in a Harvard Business School case study that detailed the frustration the developers had with management (photocopies of photocopies of that case study seemed to be in everyone’s file cabinet). While not referenced by name, the case study stated that “upper management” referred to the Word team as the “worst in Applications development.”

The “worst” team description came from Jeff around the time he reached a breaking point that led to a 12-month leave (uncommon at the time, but his decision). His characterization of the team ruffled feathers even when he returned one year later. But in truth, the development of Word for Windows caused several people to reach their limits. Many moved on. As I learned from Zero Defects, the early “big” projects had a lot of problems and those had a lot of causes. Jeff was more of a symptom than the cause, at least that is what I came to conclude.

While we were eager to start, Jeff insisted we first come together as a team at a retreat to help alleviate the angst. The retreat felt like one of those Dilbert-esque corporate team-building offsites. Jeff was always a rugged individualist (he lived in Antarctica for a year before joining Microsoft), but his return from leave came with a bit of a reflective side that led to the offsite. Other than resident adviser training in college, I had never participated in anything like this. Our team went to the Westin Hotel in Seattle (cool because I walked to the hotel from my Capitol Hill apartment) and we stayed overnight.

Professional facilitators took us through a series of forgettable bonding and exploring exercises. We even lined up and passed oranges to each other from under our chins. It was like a scene from The Office. We spoke in pairs about our feelings and goals. We did trust exercises. JeffH talked a great deal about renewal, alluding to his Word experience.

At the end of the day, we had a fancy hotel dinner. It was the first time I ordered wine on Microsoft’s tab (actually ever, but that’s another story), a bottle of red, which I then promptly tipped all over the table onto BradCh. Later in the evening, KirkG suggested we raid the minibar. It sounded like a good idea at the time, so we did, but I was reprimanded by Jeff once he saw the bill afterward. It was so terrifying that I thought I would get fired, but it also instilled, for the first time, my sense that Microsoft was indeed a start-up when it came to spending money. The company had completed its first $1 billion sales year. I got a stern talking to over the minibar.

Back at work, job one was NeXTStep.

We started building a cross-platform application framework, basically the starting point for using C++ and being object-oriented. The ET++ experiment we trained on was such a framework, but the marketplace was already flooded with such frameworks that aimed to make it easier to create GUI programs that worked easily on any GUI operating system. Borland, our real competitor, had such a framework, called Object Windows Library, or OWL.

NeXTStep was based on the Objective-C programming language, and not C++. The NeXT system was alone in embracing this language and that was the subject of much debate on the USENET discussion forums—USENET was among the earliest internet services where mostly grad students exchanged ideas (it is often likened to today’s Reddit). The main differentiator, and key point of conflict on USENET, was that Objective-C had garbage collection (via reference counting to be technically specific)—that memory management technique I favored in graduate school and then abandoned once I was schooled in the real world by JonDe.

Because we were to compete with NeXT, we needed to have everything NeXTStep had, but better. That was only logical. Our framework also used automatic garbage collection, which we were going to add to C++ (going against the grain of the C++ language purists and the most experienced people I knew, JonDe and DougK). Given the construct of our group—RickP, NeilK, who built the windowing system, ScottRa with experience in architecting applications, BradCh, GarthH, and so on, we were like the X-Men, each with a superpower destined to be part of one significant framework.

Except me. I had no experience doing anything. I brought to the table my academic background in data storage and what was known as object persistence and garbage collection, so I worked on the ability of the framework to save and load objects from memory to disk. Everything we were doing was our own invention—it was neither Windows nor OS/2; it was not standard C++; it wasn’t built using standard PC graphics. It was a perfectly consistent and well-architected system, unrelated to everything. To be fair to ourselves, that is how every application framework was done at the time.

Our project needed a name. We referred to it by the generic name af for application framework. One night, ScottRa and I were talking, and I mentioned that I saw an exhibit at Boeing about a new fighter jet, the FX or something. We joked about how there’s always an X in cool products and thus we christened the project AFX. Over the years we would make many jokes about what it stood for, like application frameworkx or application framework eXtentions, but it was never an acronym.

We spent about nine months building our framework. We were a product team. We were writing code, checking in code, building tests, and doing all the things I thought a product team did. I certainly was naïve.

Jeff didn’t see us making progress and the experienced product people on the team knew this. RickP bemoaned this fact to me in his straight-forward and honest manner at some of our nightly chats. We were spending a lot of time fighting the tools that didn’t help us to do the non-standard things we were trying to do, as well as debating esoteric, almost academic object-oriented philosophy all while NeXTStep was getting better.

To prove our work, Jeff declared App Month, which meant taking time to use our framework to build apps ourselves to determine if our product made it easy for developers to create apps. Though we didn’t realize it at the time, there was a method to Jeff’s madness. Jeff was obsessed with getting customer feedback and understanding the customer we were building product for, something already baked deeply into Apps culture. He told us to come up with an app on our own and spend a month building it, using our framework.

For my App Month I chose to build a personal finance app. I figured with our great framework and a month I would be able to beat the Microsoft Money team led by DougK, which at the time was only two or three developers. Really, I thought I could beat DougK because I had an application framework. I worked day and night, but I struggled with tools.

After a month, I created a bloated, slow, flaky program that only drew a check on a screen and saved it to a disk for a later reload. It didn’t have a check register. It didn’t print checks. It didn’t do any math. It didn’t have accounts, payees, categories, or, well, anything. I disliked it and I got the feeling everyone else did too.

I wasn’t alone. My teammates all experienced the same problems in their apps—games, utilities, and productivity apps alike. None of us achieved anything impressive.

Our mood sat somewhere between humiliated and disappointed. I was now 18 months or so into my career and was staring at the second time a project went nowhere.

On to 010. Our BillG Review