Hardcore Software by Steven Sinofsky (Audio Edition)

There was no shortage of energy around the internet. It was clear that a bunch of stuff would happen. Turning that energy into something resembling a strategy was an open question. For all the excitement, each group seemed to have its own way of defining the Internet, or its own view of how it could subsume the Internet into existing products. Convening an offsite of the 20 or so most senior product leaders in the company was a big deal. All I could really do was create an opportunity for leaders to lead and strategy to emerge. The rest was up to BillG and those leaders. JAllard and I brought the enthusiasm and hopefully a spark. It was not going to be easy.

Back to 027. Internet Evangelist

Microsoft loved a good offsite. We loved a chance to “wallow” in the minutiae of technologies, implementation, and competitors. We also enjoyed tearing apart ideas and approaches with our proverbial tech buzzsaw. In setting up the offsite I had no idea how critical it would become.

BillG famously tilted (or pivoted) the company away from character-based MS-DOS products to graphical user interface products in a retreat just a decade earlier. Platform shifts in technology seem to come in these decade waves (though perhaps that is a retroactive timeline). Was the Internet the next platform shift, even though GUI had just started? Was this offsite going to be as pivotal to Microsoft’s future as when the bet was made on making Excel for Macintosh? I certainly hoped for that, but had no idea how the company’s leaders would see things when they were all assembled to discuss it. I thought about that as I remembered DougK, the inventor of minimal recalculation in spreadsheets, telling me the story of leaving Microsoft after that offsite because he disagreed with the new direction.

Scheduled for April 5, 1994 (coincidentally the day after the incorporation of Mosaic Communications Corporation—later to be renamed Netscape Corporation—created by legendary founder of SGI, Jim Clark, and original Mosaic programmer Marc Andreessen), I prepared the mother of all briefing books for the offsite. No offsite was complete without an elaborate briefing book. I hand carried the entire thing to the copy center (MSCOPY) and ordered 30 copies, doubled-sided, bound, with tabs. They called me an hour later and told me I needed two volumes, so I headed back and removed enough pages to keep it at the 300-page limit.

Looking at the book now, it serves as a great reminder of just how small the whole of the internet was back then. One of the books I ordered for many people was by Ed Krol, The Whole Internet: User’s Guide and Catalog. How crazy to think that the entirety of the Internet could be represented as a book and cataloged, but that was sort of what it was. Similarly, the technology underpinnings were perhaps 100 pages of protocols and formats that everyone at the offsite could easily absorb.

Episode of Computer Chronicles from 1993, hosted by Stewart Cheifet. (Source: https://archive.org/details/computerchronicles)

One of the most popular prep materials was a copy of a video tape episode of The Computer Chronicles, the award winning Public Television show hosted by Stewart Cheifet from 1983-2002. The video was essentially the entire briefing book in a one hour television segment. It is a remarkable time capsule of the 1993 Internet. It was already a bit out of date by the time of the offsite but it was easily absorbed, especially for those who did not come by my office for a demo.

Perhaps I got a little carried away.

About 20 people gathered at Shumway Mansion in Kirkland about 8AM, early for developers. In his introduction without any slides, Bill improvised the term “mania” to describe the internet and emphasized a core company value, which was that exponential phenomena cannot be ignored. The internet was exponential. He said something that I thought was critically important and returned to time and time again over the years that followed. He told us the internet was not to be “studied.” It was already decided that it would be a critical part of our next wave of products. We were kicking off the process to decide what to do, not if we should do anything. His choice of words and body language was as strong as his email a few years ago declaring Windows our strategy.

In order to develop a plan, we divided into three groups, each given a set of questions:

* Systems. How do we make Microsoft platforms the preferred choice for internet as both a client and server? How do we make internet applications available given that most everything is free? What is the internet experience missing that we could provide? How does Cairo/EMS (the next, next generation OS and the new mail server, both very early in development) complement or conflict with the above?

* Tools and Services. Can Microsoft use the internet for customer support? How do we connect with developers using the internet? If we use the internet for support will we get credit for providing better support compared to what we do on CompuServe? How do our existing tools such as WinHelp and Word relate to/benefit from/compete with internet formats? Where do the new tools being developed for Marvel (notably a tool known as Blackbird) fit in?

* Online Strategy. Should our online service Marvel embrace the internet? How do we make our clients the best internet clients? What value do we bring to the internet community?

The natural reaction to such a situation at Microsoft was not to push back because of schedules or capacity, but rather to go after the other side on technical grounds. The technique of arguing against a new technology (competitive product and alternative architecture, for example), not on the basis of one’s own constraints but on the lack of merits of another approach. That was known as applying the technology buzzsaw. The basic goal was to find all the flaws on the other side to avoid admitting lacking the engineering agility to get it done.

As an example, with respect to the HTML format, there were two schools of thought. Blackbird was chartered to create a high-end authoring tool to enable content creators to make rich, interactive content for the Marvel network, like our CD-ROM titles. It cast a very long shadow and was a widely feared (and misunderstood) product, even without ever shipping. In a relative sense, HTML was a trivial subset of what “Hollywood” or magazines needed to bring their brands to the WWW. Marvel was embracing that class of content owner as a core potential partner, so HTML was broadly deficient. At the same time, a divergent view came from the Word team that embraced being able to edit HTML from within Word—Word routinely dealt with formats with lower fidelity, so it seemed perfectly fine to think of HTML as a supported format. In fact, HTML was even a subset of a just released add-on for Word called SGML Author (SGML was a mega-standard upon which HTML was loosely based).

Connectivity to AOL and CompuServe used the X.25 telecom standard—that is, connectivity provided by analog, dial-up phone lines—so ubiquitous and reliable that it was a stronghold for the telecom companies. The idea that consumers had access to the internet outside of that network or even that the packet-switched network (TCP/IP) would mature to be reliable and widely available seemed crazy. Others, seeing the exponential growth in internet users connecting with local connectivity providers using new packet-switched protocols, believed it was investing in legacy to even consider worrying about old-style connectivity and partners.

This led to a good debate over how and if Marvel should be focused purely on internet protocols for the service or not.

There was also an interesting conversation taking place surrounding various new projects intersecting, with no real way to reconcile the overlap between them. The relationship between new mail service EMS and the new online service Marvel was one example, and a topic that continued to smolder. Marvel, competing with AOL, would clearly have email and discussion boards. Marvel was already working to understand a potential relationship to USENET (and the NNTP protocol it used). EMS was an enterprise mail service just starting to be able to handle email for a few people at Microsoft. A big and differentiating feature of EMS was going to be Public Folders, or essentially shared email boxes that looked a lot like the USENET experience, and, like Marvel, EMS was also trying to figure out the relationship of its feature to USENET. The EMS design point was enterprise IT and a highly managed environment for intense email usage in the workplace, not the mass-scale lightweight consumer mail Marvel envisioned. Some things took decades to resolve and the email strategy was one of them. Blackbird, Marvel, and EMS, overlapped with each other and also with the internet. It was both stunning and kind of ridiculous. These products didn’t yet exist, and the internet did. It is impossible to catch up to something growing exponentially. That doesn’t stop debates at a big company, though, as I was learning.

Considering the Internet within the halls of Microsoft and for most attendees was months old, there was a broad consensus that change was in the air. The closer a group’s products were to the internet the more the discussion was about schedules and constraints. The further away from shipping a team was, the more the internet seemed like a great idea. That’s the opposite of what we needed, though.

The critical exception to this observation was Systems, as the first team to use the day to validate and expand plans already in place and to express a strategy. Systems intended to ensure both OS projects underway were the best client and server for the internet. The details mattered, though.

At the base level the forethought from the networking group on NT Daytona, the code name of the next release of Windows NT, was paying off. They were well down the path of implementing the required networking infrastructure. These were the essential ingredients to “get on the internet” with a Daytona computer. There were many implementation challenges to reuse this work on Chicago, which was still debating how fully 32-bit the operating system was, and also how much low-level compatibility existed between Chicago and Daytona for code like networking drivers.

The group concluded that implementing applications that made the internet interesting was critical. Those responsible decided building news, mail, Gopher, and a WWW browser, were goals.

In early 1994, the internet was not just the WWW. The internet was made up of many different services, each a combination of server code, client code, and then ultimately one or more viewers. For example, Gopher had a server that maintained the hierarchy for the site, a Gopher client that navigated that site, and then any number of viewers that could be launched to view the “leaf” of the Gopher tree. For example, there might be a Gopher site that eventually led to photos, or a bunch of Word documents, which launched an image editor, or Word to view them. The WWW had rich text, links, and images all in one “viewer,” and a simple server setup. But as I was showing off in my demos, many WWW sites were simply navigations to content that the browsers did not understand, such as music or video files.

As the debate and discussion of solutions continued, my feeling at the time was there was a lot of wheel spinning considering the galactic shift that the internet appeared to be. Perhaps because I was relatively early to the space, I had become a zealot? Or maybe I was so down on such inward-facing debates given what I had seen firsthand. It was a challenge to relay the experience I had on Cornell’s campus to teams—I sounded like a crazy person, like a junior person back from his or her first customer visit or conference. I sounded like I sounded when I came back from USENIX with a changed view on C++, though that worked out pretty well.

Looking back, by the end of the offsite, some converted to internet zealots. In many ways the zealots, myself included, left that day with the feeling that Marvel was going to either happen or it wasn’t, but that there wasn’t much that could really be done since it seemed so different than the direction we should have been going in. Marvel felt like taillights, competing from behind and not vision-setting. It is certainly easier to say that today seeing where things went.

One of the most difficult challenges to understand, until you have lived through it, is the pressure to keep moving forward even in the face of disruption. The biggest lesson I learned in just the short time between getting trapped in the snow and this first week of April 1994 was just how much of what happens in a company is a result of the momentum of a product (or technology) and the structure of the organization in place. Make no mistake, as a manager I would have my very own challenges in this regard even though I lived through this very experience.

The offsite did not come to a dramatic end with the key developer quitting as the bet on graphical interface, but it was an incredible day. There’s no doubt it was very important to urgently bring everyone together and for Bill to make it abundantly clear just how much we were betting on the Internet, and he did so without hesitation. Many would look to the Internet Tidal Wave memo years later as the clarion call when in every respect this was the pivotal day in the journey to an internet-centric company.

On to 029. Telling the Untold Story

I’m about to get my first lesson in disruption. It wasn’t called that yet, the first HBR article is a year a way and the book and phrase “innovator’s dilemma” more than three years away. Trapped in the snow seeing the power of the loosely connected, mostly University-created, software almost immediately turned me into a zealot. I don’t use that term lightly. I had seamlessly transitioned from character to graphical interface, even from mainframe to PC, without suffering the pains of disruption. I had no business to run or customers to keep happy. I was just a kid, a technologist. I was now facing an entirely new challenge—not only did I feel compelled to evangelize the internet to people, but I had to wonder with every question, with every push back if I was even right. Smart, very smart, and successful, very successful, leaders at Microsoft and giants in the industry didn’t seem to get it. Who was I to be so certain? What did I know? It turns out, not knowing what I did not know was an asset.. And so begins my intense few weeks evangelizing the internet to anyone who would stop by my office and experience my dedicated internet “DTAP” connection.

Please consider subscribing. Thank you.

Back to 026. Blue Suede Pumas

The Securities Exchange Commission (SEC) made public company filings available on the WWW. This was interesting because the information had been previously difficult to obtain and was only available with a subscription fee.

That would get BillG’s attention.

In the early stages of a technology, users are also the builders. As a result, there was a lot of easily accessed material about the WWW itself, a sign of a healthy movement. Many individuals tracked metrics such as number of servers, connectivity speed, and volume of major protocols. Part of my research was building up a data set to explain the growth and diffusion of the WWW and associated technologies.

I went to the Kinko’s on Broadway on Seattle’s Capitol Hill and once again used their crazy copy machine to make a big poster of the NSFNet internet backbone map of the United States. This would often become a main talking point for business-oriented discussions.

For technology discussions, I also started building my own library of important internet technical documents. These were called requests for comments (RFCs) and were the specifications for how different internet technologies worked. RFCs began with the research network itself in 1969 and continue today. While many other standards bodies started contributing to internet and networking (IEEE, ISO, W3C, etc.), much of the important work for the internet still takes place via this process. These documents are as important culturally as they are technically. When you read about email, domain names, network address translation (NAT, this was brand new at the time) you not only understand the implementation but gain a whole appreciation for the culture of openness and collaboration. These were the exact opposite of the rigid specifications from IBM or the NT team.

After meeting with JAllard and hearing his excitement and also concerns, I scheduled a few more meetings. I met with people on the Chicago networking protocol team and the team working on higher level user features for networking. I also got an earful from my new friends in the Microsoft Information Services group about security concerns and also risks of leaking intellectual property, at the same time they were anxious to find ways to offer secure connectivity as a service to employees.

My first demo was with Bill. It was very intense and probably lasted two hours. As fast as I could click on the screen, Bill had deep questions about technology, business models, ownership, intellectual property, and more. I jotted down notes of questions I knew nothing about and kept the demos moving. I was less than a week into learning the internet. Bill was two hours in.

What kind of questions did Bill ask? Though I was able to show BillG a lot, he stumped me asking to explain the difference between WinHelp, Microsoft’s relatively new online help engine, and the WWW. They were both formatted text with hyperlinks and the user experience was similar. The formats even looked the same. WinHelp used Word’s Rich Text Format (RTF) which was also a tagged text format. In fact, WinHelp looked world’s ahead of HTML because it was richer and compressed, so it took fewer bytes. On the face of it, distinguishing between WinHelp looking at Visual C++ help and Cello looking at the Novell site was not easy. Bill immediately saw WinHelp as Microsoft’s “competitive response” or counter to the new WWW.

It took a few minutes for both of us to converge toward a shared understanding, but this was important learning. WinHelp at the time could not access links between different files, let alone different computers on different networks. This was a key innovation in HTTP and the invention of URIs (Uniform Resource Identifier, then often called the more specific URLs, uniform resource locators, referring to web addresses).

There were challenges that we discussed. It was going to be difficult to add more features to WinHelp. There was no WinHelp server. In fact, there were no servers anywhere. Microsoft was just starting to build servers. If someone working on WWW (HTML and HTTP) had stumbled into the conversation, they would have laughed at us thinking WinHelp was anything at all like the WWW. Just because there were links did not make them similar—the technology implementation mattered, and this theme kept emerging.

Navigating a Gopher site looked like the developing Chicago Explorer (or Windows File Manager). At least that included networking sites. But in this case Windows even lacked the basics of long file names (except on Windows NT). The similarity to directory browsing took on a more nuanced differentiation because the Windows servers were “connection based” and Gopher servers were stateless/connectionless like everything on the internet. This was a key discussion and differentiating point that, while sounding a bit esoteric, represented the challenges Microsoft faced technically in working with internet technologies.

One of the things I concluded was that as I showed different aspects of the internet to Bill (gopher, WWW, ftp, telnet, HTML, etc.) he was quick to map those to existing or envisioned capabilities in Windows or in Information At Your Fingertips. I was struck by this because, well, I did not see that at all. I saw everything on the internet as totally new and different. I saw everything we had as kind of clunky and unrelated, or at least different. As I reflect on this and now have the benefit of the vocabulary of disruptive technologies, I can see how I had an insurgent view of the technology whereas Bill had the incumbent view. As the insurgent I had nothing to lose and everything to gain by embracing the new and seeing it as different. As the incumbent, the natural inclination is to see new things from the perspective of the existing work.

To emphasize this point I found myself making printouts of screenshots of some internet technologies as well as their comparable Windows technologies (again, back to Kinkos for their color printer since we did not yet have those in the copy room). For example, I made a screen shot of WinHelp and compared it to a screen shot of WWW. I had a sample of HTML and a sample of RTF from Word.  I did the same for the envisioned File Explorer in Windows and Gopher, and so on. I had these handy because as I spoke with different people I routinely found myself needing to explain what was new grounded in the reality of Microsoft’s technology platform.

The excitement around this first “new” internet demo was tangible. I repeated the demo later and we exchanged questions and answers over email. Bill had seen various bits and pieces of the earliest (pre-WWW) internet demonstrations at ThinkWeeks. Then, the internet still seemed like a competing mechanism for accessing proprietary information services—using TCP/IP packet switching instead of X.25 dial-up connections. These new demos quickly changed his view. The internet was changing faster than twice a year ThinkWeeks.

I reminded Bill we agreed to have an offsite—that was a good thing to do I figured. I wasn’t sure what we would accomplish but needed to get a bunch of people in the same place thinking about this at the same time, importantly, with the same inputs, which would be our goal for the offsite. We had set a date for April 5, which gave me about 6 weeks to pull together the right people, meet and pre-brief attendees, and prepare pre-reading materials.

While offsite preparation was going on, I dragged anyone I could into my office to demonstrate the WWW and discuss the internet. The program manager in me put together a standard demo script that was flashy but also explained what was going on. If you’ve ever seen the TODAY Show clip in which the anchors asked, “What’s the internet?” and then debate how to say the @ symbol (about? at? around?) and internet addresses, that almost exactly sums up what it was like to demonstrate the internet even at a leading tech company. Most Microsoft people weren’t even using AOL because most of our work activities were on CompuServe, with its clunky text interface and overpriced access to interesting information sources. There was a uniform interest and even excitement.

In big companies, however, everyone is busy. At Microsoft (and with software companies in general) every project was already late. That meant it was always the wrong time to show people something new, and most times my attempts were met with skepticism and concern.

“Will this impact our schedule?”

“Is it really a big deal?”

“We have something similar.”

J and I needed to up-level the conversation while we balanced schedules, the understanding of the technology, and the reluctance to take on new work. It wasn’t pushback; everyone understood the technology. There was a lot happening at Microsoft already between Windows Chicago, Windows NT, a new version of Office, and every other product building on those.

Every person and team, from Chicago to Cairo, reacted differently. Was the internet an app or a platform? What exactly were we worried about from a competitive perspective? Did we care about formats, protocols, or implementations? These abstract questions became fundamental to how Microsoft evolved its perspective.

Chicago was already late (originally Windows 93, we were well into 1994 and still 15 months from finishing). Most everyone on that team said of the demo, “We have the plumbing,” but apps would come from third parties.

Cairo reacted differently. The skepticism mirrored that of corporate customers who viewed a body of free, university-developed software as risky and unreliable at best, or toylike at worst. The Cairo project was aimed at commercial implementations. The internet was difficult for the Cairo project to wrap itself around as it was a direct “competitor.”

NathanM and CraigMu embraced the technologies. Nathan and Craig were leading the idea of partnering with the large telecom and cable carriers to deliver home services for the information superhighway. How the internet as I was showing it related to these became interesting. As an example, AT&T viewed the internet as a “home endpoint,” like a phone. A big project they had underway was to think about how everyone could have an email address and then list that in a big directory. If that sounds like the email version of a phone number plus 411 that’s exactly how a carrier like AT&T thought of new technologies—through the lens of proprietary services and protocols.

RussS had already transitioned to work full time on the online service Marvel. Russ set out to build an entirely new network, a new dial-up service, to ship with Chicago. He went from researching an opportunity to critical path for the release of Chicago in the span of a few weeks. He saw the potential of the internet but was going to need time to absorb what impact, if any, it had.

Rob Glaser (formerly RobG) left Microsoft to form an exciting new company called Progressive Networks. It was going to be a distribution channel for politically progressive content. Rob had spearheaded Microsoft’s multimedia strategy and collaborated with Bill on many projects during his time at Microsoft. Rob was the first to ask me a lot of questions I did not know the answers to. Rob wanted to understand who paid for the internet and how it was going to be a viable model. Part of my demo “kit” was a map of major nodes on the internet and the connectivity speed. Rob wanted to understand much more about the journey of bits over the network and how that worked. He had a lot of interesting questions. Rob later renamed his company RealNetworks, which became content streaming pioneers. In September 1995, RealNetworks livestreamed a Seattle Mariners game. Rob was well ahead of almost everyone.

SteveB was overseeing (and building!) the global sales and support organization, the “field.” He was in Japan working at MSKK, but he still managed to catch a demo on a trip back. He was immersed in the growing needs of enterprise customers—Microsoft was still overwhelmingly an OEM and Retail business. He was well versed in and played back many of the typical concerns voiced by corporate customers regarding the maturity and readiness of “free” software from universities. One WWW site I showed him was the Novell Networking site, which was already far ahead of any Microsoft presence (well, we had no presence at all except the FTP server outside HenrySa’s office). The availability of Netware documentation in a WWW browser made an impression immediately and riled up SteveB’s competitive spirit (as if that needed any help).

Living in Japan and traveling all the time, Steve was acutely aware of the difficulties connecting to Redmond HQ for resources. Microsoft’s products, collateral, and demos were growing exponentially, and downloading all these over paltry connections was a hot button. The field created a monthly CD-ROM, which was DHLed to the subsidiary offices around the world. Maybe the internet could speed this up. Steve also wanted me to connect with someone in Product Support Services, which was managed by PattyS, to see how we should use the internet for providing product support.

I also offered demonstrations to any guests that were in the office to meet with BillG or NathanM. They were meeting all the time with people from the telecommunications industry, Hollywood, and cable television. In spirit these were a lot like the Microsoft meetings in that people were quick to try to map new technologies or experiences into the world they knew, but unlike the Microsoft technology stack I was ill-equipped to explain how NSFNet related to leased X.25 lines or how HTML might evolve to be good enough for Hollywood productions. One well-known director was thankful for the demonstration and sent a 6 foot Jurassic Park cardboard cutout that remained in my office for my tenure.

Perhaps the most fun I had were the demonstrations for my friends and peers. Erin Cullen (ErinCu) worked in corporate communications and had been poking around all the new stuff. She soon made a case to the larger team that Microsoft needed a web presence and helped to make Microsoft’s first WWW home page.

Soon, I was getting mail from all over the company requesting demonstrations. I wish I kept a list of how many times I went through my expanding and improving demos or how many times I had to explain who pays for the internet or who wrote the software we were looking at. While everyone to a person was intrigued and excited, what exactly should come next was totally unclear. I was incredibly happy that there was so much excitement. I was equally nervous that people did not “get it” like JAllard insisted needed to happen. I did not quite understand it at the time, but I was facing that ever-present corporate force that just wants to keep doing what it was doing. I had an over-abundance of misplaced confidence and a cool demo script.

I also had an offsite to prepare for and what was beginning to sink in was the opportunity to use the ability to convene the leaders who could really embrace (and extend) Internet technologies.

On to 028. Pivotal Offsite

Microsoft was now big enough in early 1994 that it was easy to know the really old-timers (10 years was really old, 5 years was the period of doubling year over year), but anyone hired after you outside of your immediate group (or school) became more difficult to know. Working as Technical Assistant gave me a chance to meet people at every level in every product and technology group. By far, the strongest bonds I built were with people who were more peers than anything else. James “J” Allard (JAllard) just authored the memo Windows: The Next Killer Application on the Internet and after my Cornell is WIRED! exchange I was immediately connected to him as “he’s a guy who has been working in this area”. As soon as I returned from being snowed in I headed over to meet J in one of the original single-X buildings, steps from the side door of Building 8.

Head over to the comments and share your first experiences with the Internet if you were there when it was new.

Back to 025. Trapped

Back home, I went to J’s office in one of the single X buildings just across the walkway from Building 8. He had a typical Microsoft interior office for a junior program manager, but his had an aquarium with some reptile in it. Yuck. We were both wearing blue suede retro Puma Clydes. Because of our footwear, I was able to forgive the reptile which even after showing up at his office 100 times made me uncomfortable.

J graduated from Boston University in 1991 and Microsoft was his first job. At BU he worked in the computing facilities the way I did at Cornell and we bonded over that. He described the job he was given by SteveB as “make this TCP problem go away.” He joined the networking group at a time SteveB was still running Systems, which included the always struggling LanMan product. TCP referred to the customer problem Steve was seeing where Microsoft did not support the technology that was rapidly becoming the preferred protocol in business networks, TCP/IP. This was a time when the choice of a network protocol was a strategic business decision guided by IBM, DEC, and hopefully Microsoft someday, and few would think of using what was generally considered a research platform.

This was one of my first lessons in Microsoft challenges in developing an internet-centric strategy. It was new to me, but for J, it was the daily “battle” he already faced. Microsoft thought it would develop a connected PC by also developing the networking protocols that connected the PCs. There was a great deal of work that had gone into many “layers” of the networking software. Microsoft could do a better job if all the parts of the network were running Microsoft software. Microsoft was not unique in thinking this, but it was late to the party.

The internet didn’t work that way, though. The protocols themselves were openly developed. Vendors developed their own implementations of those protocols, but they needed to interoperate with all the other parts of the network. J’s job was to make sure Microsoft had great support for TCP/IP, the base networking layer for the internet. Some big commercial and government customers were early in adopting TCP/IP, including money center banking and defense departments which were very large Microsoft customers.

To the Windows and NT teams, TCP/IP was one of several ways of connecting. Windows NT was designed from the start to be networking agnostic but solidly favored and made a bet on TCP/IP, which was a significant departure for a Microsoft product, and also evidence of the difference between NT and LanMan. Chicago was working hard to support Netware’s protocols, which were the current business leader, with TCP/IP support coming from NT in an evolving partnership JAllard described to me. The speed at which networking switched to TCP/IP was stunning. The reality was that it was vastly superior to any other solution for running corporate networks. As I recalled from my first day at Microsoft, the beeping death due to network failure was still all too common and not something I experienced in graduate school where TCP/IP dominated. TCP/IP addressed that with a much more robust approach. J re-explained all of this to me.

He was tracking the public sources of data and was seeing the exponential growth in the use of the internet. This is really what got everyone’s attention, including, and especially, BillG’s. BillG gravitated toward the exponential.

The internet was over two million connected “nodes” at the time. Today, a node might be a house with dozens of devices on the internet or a business with tens of thousands. Then, a node was a single computer (a Mac like at Cornell or a Gopher server). It was estimated that 25 million people were using the internet and it was growing at a rate of more than 5 percent per month, 70 percent per year. Importantly all the companies that offered networking over phone lines and leased lines were starting to offer internet (or packet switched) connectivity to businesses.

The numbers were breathtaking.

By way of comparison, about 37 million PCs were sold in 1994. But growth was slowing to about 12 percent per year. Given the lack of internet capabilities of Windows, there was a clear challenge in that Macintosh might become the preferred internet PC and, with the internet growing much faster from a similar base, the numbers could be substantial. Simply by growth metrics, the internet was going to swallow PCs.

During our discussion, J offered more technical details on the services Windows required in order to be a first-tier internet device, on both the desktop and the nascent Windows server market. The largest volume by bytes was email, but the newest service, the one used by Mosaic, was growing at an astronomical rate. At the time there were just over 600 web servers (or sites) worldwide and estimates that over one million people were using Mosaic, which users downloaded from the university site by FTP, a geeky and wonky tool if there ever was one.

That wasn’t a lot on the internet compared to what AOL or CompuServe offered, and like so many things that ended up being disruptive shifts, it had a toylike feeling. The WWW server that concerned J and team the most was that their biggest competitor, Novell, had already put all their networking documentation on the internet on novell.com.

J showed me a larger tower PC with a network cable going up through the ceiling where a tile had been pushed aside. J introduced me to two members of the team, David Treadwell (DavidTr), a developer on networking, and Henry Sanders (HenrySa), a more senior dev manager. I already knew David from common connections in college recruiting. Henry went to Cornell and was a terminal operator at the same time as me, though he graduated a year ahead. I remembered him. He did not remember me at all. Henry had a good deal of fun in college.

The three of them formed the bulk of the TCP/IP networking team. They were building out Microsoft’s TCP/IP layer and additional services required for the internet, such as FTP, for transferring files and TELNET for connecting to other computers—the bare minimum required to claim any entrée into the internet world compared to the Mac or especially Unix (there was no Linux yet).

The large tower computer was an important demo. The team had created an FTP server so people could download Microsoft software. Microsoft made a version of MS-DOS freely available but did not have distribution beyond the private services like CompuServe. J said that with no “marketing,” tens of thousands of people were downloading free MS-DOS from this one computer sitting in a hallway running pre-released Windows NT and one of the earliest and most arcane internet apps, FTP. Software patches and updates were also placed there. Over 50,000 people per week visited ftp.microsoft.com, essentially as customer support, in lieu of getting the same materials at CompuServe (for a connection fee). A local company provided internet connectivity for Microsoft HQ and we were nearly all of their volume and Microsoft’s traffic was the equivalent of 25 percent of the largest provider on the internet.

It was crazy.

In a big company, the first step of solving a cross-company problem was to make sure there was someone working on it. Usually, a bunch of people say they are, but they really aren’t—big companies love to stake a claim on an area, but digging in reveals little more than a hobby or side project. On a good day, only one person was working on the problem.

Systems had a phrase for this, cookie licking, or laying claim to a technology area without actually working on it.

J really was working on Microsoft’s internet strategy.

His only challenge was that he was in the networking group and working on the low-level plumbing, not on the consumer experience that was on display at Cornell. That’s where my role as TA came in. It was to bring together the right people with the right level of both technical understanding and management responsibility to create a coherent strategy. That was all.

Jumping to a conclusion and the main tool I had as a TA, the power of convening, we needed to have a big emergency offsite. I told J, after hearing about the opportunities and challenges, that I would push BillG for one. Bill loved offsites. At the end of an unrelated meeting, I told him we needed to do an offsite on the internet. He grabbed his pad and felt tip and sketched out the calendar, an actual calendar, for what remained of March and April, identifying travel dates, important meetings, and the like—he was always obsessed with his use of time and calendar constraints. A few scratches and arrows and we had a date.

Before I could begin my adventure, though, I had one problem. I could not get “on the internet.” J fixed that by connecting (a pun) me with Dave Leinweber (DaveL), an old-timer in Microsoft Information Services (MIS), the IT organization that ran the company network. I emailed DaveL right away, subject line “DTAP,” which was how one described a direct access to the internet.

DaveL arrived at my office having not really been summoned before. Before connecting me, he talked at great length about how risky the internet was for network security and what a big problem this could be. He also talked about how much it cost in internal billing. After some negotiating, and me explaining I understood the company’s concerns, we agreed I received authorization for my DTAP, a bright red network cable in a separate jack with a warning label. The rule was that I could not connect a machine to both networks at the same time, and any machine that was connected to the red plug could never be connected to the regular corporate network ever again without first erasing the hard drive.

I needed a new computer for my new setup, fortunately just as Apple released the PowerBook Duo laptop. It was a slick portable with a fancy motorized docking station that inhaled and exhaled the computer with a lovely whirr. It had a trackpad! The bulky Compaq LTE with a goofy trackball mounted vertically on the screen was an embarrassing contrast. Plus, most of the internet software I’d seen to date was Mac first or Mac exclusively.

I set up the Mac with an IP address as per DaveL—my Mac became one of the two million nodes directly on the internet. On the front of the Mac was a sticker with the IP address that was assigned to both me and the jack in the wall. I immediately began to download software. I first had to find an FTP client, which I did via transferring a floppy from my Windows PC after downloading the client from CompuServe on Windows. From there, I connected dots.

I felt like I was in graduate school again. Back then my DEC workstation was assigned an IP address and I went and added that to the university’s HOSTS table which then communicated that to all the other computers on the network at the university and everywhere. The current mechanism of having a private internet address (those 192.168.*.* addresses) was still a year or so away from general deployment.

Using Gopher from the University of Minnesota, I located programs for IRC (Internet Relay Chat, which was the successor to the Talk a program I used in college) and reading USENET News. Then I finally got to Cello and eventually Mosaic. Soon, I had a folder full of internet applications, which I labeled Information Superhighway. I also learned that AOL could use an internet connection if it existed (instead of a dial-up connection), so I was experiencing AOL, except it was extremely fast. How fast? Well that DTAP running on a shared T1 line I had was about the speed of a 3G mobile phone, or less than 1 megabit per second but substantially faster than dial-up’s maximum of 56 kilobits per second.

That first day with the internet stretched well into the early hours of the morning. I was downing Diet Cokes and making notes in a text file of cool “places” to visit on the internet. “Surfing the web” was not yet a term, but that’s what I was doing. I built a list of favorite links in a text file, which was precisely what every early user did. I felt like I was back in my high school TV room exploring FIDONet all over again, but everything was faster, in color, and much more fun.

The biggest, peaceful world event happening at that time was the Lillehammer 1994 Winter Olympics and it had an internet presence (!). I was able to find a page that had a camera pointed at the main Olympic stadium. Every minute a tiny still black and white image, like CU-SeeMe, refreshed. I downloaded a separate program that made it possible to watch the live “feed.” Unbelievable.

I found MTV.com, which was a rogue and unofficial page maintained by legendary VJ Adam Curry. It became a favorite of mine, given that I tuned in to MTV constantly in high school when we first obtained Cable TV. Curry set up the site a few months earlier without getting permission, including taking the domain name. It was all about music and musicians, but also had audio clips that could be downloaded. These required a separate audio player for the format that was common at the time (Apple was still charging for QuickTime and Windows formats had yet to be developed; MP3 was still a year away). I found several sites with song lyrics and routinely showed people R.E.M.’s “It’s the End of the World As We Know It (And I Feel Fine),” comparing different interpretations of a song with rather fluid lyrics. MTV sued Curry and eventually he surrendered MTV.com to the corporate masters.

A few years later, streaming arrived, but at the time what we were seeing was mind-blowing.

Think of the most mind-blowing product experience you ever had. The product experience that left you speechless, almost hyperventilating, with a million questions and a million ideas. I had already experienced that with so many of the firsts in my own computing life: Atari, dial up BBS, IBM PC, Sun workstation, Xerox Star, Macintosh, Windows 1.0, and on and on, but none of those compared to the Internet in 1994. Talk about the luck of timing. I experienced all those things when they were firsts, so at the very least I could calibrate my own reaction to the Internet.

While it was swell that I could see this stuff, I needed to get more people excited and soon. I felt Microsoft was behind and as soon as people saw this stuff, they would see the same level of urgency I did. I quickly became an internet evangelist. First stop was BillG.

I was about to begin a huge lesson in how to change a large company. I was excited, and scared.

On to 027. Internet Evangelist

Imagine having all the confidence of an early twenty-something at an incredibly successful technology company leading the industry and lucky enough to be in a job giving you access to the leaders that made that happen. Now imagine getting trapped in the snow at a university and experiencing a software experience cobbled together by a tiny number of people using free code from other universities. That would be one thing. But what if that experience collided head-on with the grand vision the company was working towards.

Back to 024. Discovering Cornell is “WIRED!” [Chapter IV]

Feeling nostalgic, and trapped, I decided to go visit old lecture halls and campus sites. Cornell was used to the snow and even with all the warnings of a big storm, most students were going about their evening. From the career center in Hollister Hall I made my way over to the Upson Hall basement where I had worked the terminals and the mini-computer room for computer science majors.

It was still early enough in the PC revolution and connectivity that most students were still doing their work in these shared facilities.

The layout of Upson had changed dramatically from my time there. Walled cubicles of VT-100s with a shared line printer were replaced with long tables of Macs. There were new NeXT cubes that were getting a lot of use. There were even laser printers that had magnetic Vend-a-Card readers that stored cash to pay $0.20 a page for printing. When I worked in the Uris Hall computer room, I was lucky enough to have the only public laser printer on campus, but alas it was only connected to the IBM mainframe.

It was the end of the day. The room was buzzing. People were racing in, spending a few minutes at a Macintosh, and racing out. At first, I couldn’t tell what they were doing, and with no student ID I wasn’t able to use a machine. After watching a few students, I realized they were all following the same flow.

Each quickly sat down at a Mac and pulled out a floppy disk from a backpack (slung over one shoulder, none of this both-shoulder thing the kids do these days). Shaking the mouse to wake the machine up, the Macs were set to launch only one program called Bear Access (Cornell’s mascot is a bear). Students typed in some ID, inserted a floppy disk, and then quickly navigated to mail. I later learned the students were storing their mail on the floppy because the Cornell mail servers were running the POP protocol and were not storing it after the initial download (for cost).

As dinner approached, Upson vacated, and a quick look outside made it obvious that everyone was hunkered down in dorms and apartments for the evening. I asked the operator if they were closing due to weather (we would never have done that) and he assured me he would be around because he needed to get the hours in that week. I was staying across the quad at the Statler Hotel, so I headed into Collegetown to eat.

After a quick stop at Souvlaki House I went back to Upson. It was completely empty. The operator was reading from Foley & van Dam, the standard text on computer graphics.

“I know this will sound strange, but I used to work here about 10 years ago,” I said. He looked annoyed.

“I see you are taking Graphics. . .is it Professor Greenberg?”

While I had not taken the class, all my friends did and I was also friends and classmates with Professor Greenberg’s son, which I was quick to mention. He remained bothered.

“Well, I work at Microsoft and I am here interviewing students for internships next summer . . .”

He interrupted me, grabbed his backpack, and pulled out a resume.

After a few minutes of typical discussion about opportunities and how to interview and more, I asked, “Can you maybe show me how Bear Access works and tell me how you are using computers these days?”

We pulled up chairs at a Mac. He logged on. I stopped him and asked where and how students got an ID, thinking back to the punch card with [email protected] I received orientation week freshman year. Cornell IT (CIT) had built an identity system such that it maintained the canonical mail address for students and faculty and routed mail to the appropriate mail server. The email system in use at the time, as was typical in most organizations (academic or otherwise), was distributed and heterogenous. Different departments each ran their own mail servers of different types along with different ways of assigning email IDs. CIT created login IDs so students could always be referred to by a single @cornell.edu mail address no matter where their mail went. Every single member of the university community had a login ID.

This was the first example of a solution to a problem that was a product under development at Microsoft, Windows NT.

The business or enterprise version of this problem was known as directory service and was a rather heated battle between Netware and the new entrant, Windows Server along with the EMS project described previously. But at Cornell, this was already working. Most companies in the early ’90s were not yet using email and definitely did not have a directory.

Launching Bear Access, I was immediately struck by the similarity to AOL or Prodigy. Here was a Mac running graphical software (and TCP/IP networking, another technology that PCs did not routinely run) where the icons were all information sources. The resources available, all a click away, included email, library, the university bursar, chat, access to the directory for finding people, campus store, and something I was totally familiar with, CUINFO.

I got excited. “Tell me about CUINFO!” Ten years earlier CUINFO was a magical behemoth. It was thousands of lines of IBM 360 assembly language (among archaic languages such as REXX to massage the data feeds) running on the mainframe out at the airport accessed via VT100 kiosks throughout campus (no logon required). With CUINFO, text-based information, such as the weather forecast, course roster, and campus events, were available. It was years ahead of its time.

Instead of accessing it via a terminal, clicking on the Bear Access icon I launched something called Gopher. Then right before me was something vaguely familiar. Instead of typing menu numbers like a phone tree, I was navigating an information service with double-clicks. And there was the same NOAA weather forecast I remember being coded by my fellow operator a decade earlier.

But what was Gopher?

A few months earlier, Cornell migrated the entire CUINFO system from the mainframe to running on the open source project Gopher, developed at the University of Minnesota. The IT effort involved took the CUINFO information and organized it into a Gopher hierarchy: Academic Life, Administration, Dialogs, Library, Student Life, Campus, Ithaca, and so on. And within each of these there were further hierarchical topics, such as under Library there was schedule, information, electronic books, and the online catalog. I learned that the CUINFO hierarchy itself was over 800 pages—that’s the outline of the information not the information itself. Gopher looked a lot like the early builds of the new Explorer in Chicago.

From my Microsoft vantage point, adding insult to injury, the CUINFO Gopher server was connected to a slew of other like-minded Gopher servers around the world. In other words, it wasn’t only that Cornell was doing this or even that other places were, but there was a network. That network on the internet was growing at a rate of 3 percent per week.

Information was searchable using WAIS, an early internet, open source content indexing and search platform. Search was a key, but theoretical, part of IAYF in Cairo, but this was an area where literally no one at Microsoft was working on a product.

While hardly today’s Facebook, I was treated to demonstrations of search across the Who Am I service. What used to be entirely impossible was routine. “Find the person Pat in Arts [and Sciences] school, class of ’96, who lives on College Ave.” Using the information students voluntarily put into the directory, the results appeared. There was an ongoing debate on campus about privacy and soon thereafter searching was curtailed.

The early internet was rather quaint that way.

Chat was another service accessed from Bear Access, using the newly familiar (in tech circles) Internet Relay Chat, or IRC protocol. Later that evening in my old dorm, Founders Hall, I watched as a group of about 10 students in one computer room chatting all together with other people around the world. Chat wasn’t for fun, as I learned; TAs were using it for study and course-maintained IRC rooms as well.

This was all incredibly exciting. But it was also humbling. And scary.

My baseline experience was AOL (a walled garden with a monthly fee) or the barren enterprise network, which best case was fairly heavy email running on clunky shared file servers, as Exchange was still years away. A revolution had taken place.

Back at Microsoft, RussS and others were working to define an online service for Windows, and yet here was one that was already rivaling AOL, built entirely on free software at a university and growing much faster than AOL.

This snowstorm was turning into the biggest surprise learning experience of my early career. More importantly, it was opening my eyes to speed of change. I had been at Cornell less than a year ago and yet everything I was seeing was new. It wasn’t only the software but the students and faculty and how they interacted with computers and information.

My new operator friend was on the ball. We went through how difficult it was for them to keep the Macs running. Like many places, after each use the Macs were “reset” and all the files and programs deleted and restored to a new state. This happened dozens of times a day. This hack was clearly an opportunity for Windows. At least it should have been.

After almost three hours, it was getting late—close to 11 p.m.—but before I left we looked up my old boss who ran CUINFO and IT, Steve Worona, in the directory. I sent him a “Hey, I am in town” note. We set up a meeting the next day at Day Hall.

Late that night I went to the Hot Truck on west campus. I ordered a “double PMP Pep” (Poor Man’s Pizza—Johnny’s Hot Truck invented French bread pizza, so the lore goes) and waited in the blizzard. Two students in line were busy talking about the new Visual C++ that had recently come out. It was surreal.

I said, “Hey, I know a bit about Visual C++,” trying but failing to remain composed and with some hint of modesty. The students seemed excited. One told me about writing his first Windows program. It was like an advertisement. After some back and forth I told them what I did. He asked if he could run back to his dorm and get his copy of the product so I could sign it.

I was not sure who was more excited by this conversation. This was the strangest thing that ever happened to me.

The excitement of the moment was soon awash in the nausea that comes from eating Hot Truck at midnight as an adult.

The next day, the school was knee deep in snow and mostly shut down. I wasn’t getting out. I headed over to Day Hall to see Steve Worona, who was then the assistant to the CIO of the university. Steve was the original programmer for CUINFO with an office right inside the small computer terminal room in G20 Uris Hall where I worked freshman year.

For about an hour we talked about how far things had come since he originally wrote CUINFO. Hearing Steve’s acknowledgment of the many challenges that lay ahead was super interesting. The university was wrestling with privacy, independent organizations had different ideas about information sharing, and even labor unions were concerned about how access to information might impact employment.

Steve then set up a small camera to show me a demo using, as I recall, one of the earliest pre-release Connectix Quickcams, which was a Macintosh-only peripheral (super frustrating that it did not run on Windows). I had only seen the camera in the press. Interestingly an Excel product manager had just moved there so I was able to secure one at the time back in Redmond. It was an amazing technology in search of a use. Then it met the Internet.

He launched a program on his Mac called CU-SeeMe, fiddled with it a bit, and then a window opened. This was a small black and white moving image of a classroom in North Carolina. A few minutes later more windows opened up of other classrooms, two in New York and one in Washington, DC.

Suddenly, I was looking at a five-way video conference made up of tiny postage stamp black and white windows at about 10 frames per second. Live. From around the country. Everyone dialed into the same traditional voice conference line. For half an hour, students did what students do in a learning environment as teachers asked questions of each other. Watching them share information was incredible. For Steve it was new but becoming routine. The project was called Global Schoolhouse, supported by NSF and the Department of Education.

After the classroom, Steve spent a good hour explaining the technology they developed. The project created a video protocol, a multicast network server, and the client software. They were already doing “student exchange” programs with Europe even. IBM was even helping to make a Windows version. Everything was on Macintosh.

It was almost more than I could take.

Video conferencing built on the PC, as we showed in IAYF, seemed forever away and for sure no one was really working on it at Microsoft. Microsoft NetMeeting was still yet to be conceived and would not include video conferencing for years.

Steve showed me one more demo. Switching to his Windows 3.1 computer, he launched a program called Cello. Cello was developed by the Law School at Cornell and was the first “world-wide-web browser,” or just browser, for Windows. A web browser looked like Gopher and CUINFO but used a different protocol and different format for information. Where Gopher looked like a file explorer or Mac Finder, Cello used hypertext and links to pages with nice formatting and looked more like Windows Help or HyperCard. Because of Cornell’s mixed computing environment, Steve explained they also used Mosaic on Macintosh. Steve was super clear that he expected the browser to supplant Gopher even though he loved the information hierarchy; the browser’s use of images was too good.

Cello and Mosaic were the world wide web, WWW.

At the time, Marc Andreessen and Eric Bina were developing Mosaic at the University of Illinois, which was the first graphical HTML browser. By the end of 1993, it was running on all the major platforms in early beta form. On the internet, it seemed not only was everything free, but everything was in beta and was developed by students at a university somewhere. That was something I had to get everyone back in Redmond comfortable with, along with the reality that everything ran on every operating system.

That afternoon, February 13, 1994, I went back to my room at Statler and wrote a fairly breathless memo entitled Computing at Cornell and the Internet. After apologizing for being a Cornell cheerleader, I detailed my personal history of computing at the school and the evolution of what I had seen.

Along with the memo, I shared series of recommendations—specific things we could be doing to improve Windows (and servers) and Desktop Apps to make them internet-friendly and even great for the internet. Most of them were directed toward Chicago, the Windows 95 project that was under development.

I sent the memo as a Word attachment in email to BillG with the subject line “Cornell is WIRED!” to get his attention. WIRED was the new magazine at the time and “wired” was synonymous with cool. I also backchanneled the memo to BradSi and John Ludwig (JohnLu), who was one of the two lead Windows executives. I did this to make sure no one was blindsided by my report since it could easily be seen as me saying, “Add even more stuff to Chicago that is already late.”

Bill, doing what he always did, immediately forwarded the email to a set of key execs working on Chicago and platforms (proving it was a good idea to backchannel people). The thread was sent to PaulMa, who sent it to the email exec, TomEv, and even to the Windows evangelists in hopes of getting them to drive an engagement with developers to use Windows. Pretty soon I was getting emails from university relations, Microsoft’s connection to schools and colleges. And they told two friends . . .

I was comfortable with my emails being forwarded around, but this one had taken on a life of its own.

It clearly touched a nerve.

The most actionable response I received was from JohnLu, who told me I should talk to a “guy over in NT” who was working on this “stuff.” He copied J Allard (JAllard). J sent me a note saying something along the lines of “Where you been?” and attached a memo he had just started circulating called Windows: The Next Killer Application on the Internet.

I read J’s memo while still trapped at Cornell. It was everything I could have hoped it would be after getting so amped up over the internet for 48 hours. Even the title of the memo was so subtly clever—it said that Windows would be part of the internet, decidedly not the other way around. While too many came to remember this memo for the use of “embrace, extend, innovate,” the reality was always the other way around for J (and I agree). The internet was larger than Windows and could not be contained by an operating system—Cornell was already proving this. Windows was an application on the internet.

Also misunderstood was the use of “killer.” “Killer app” was a phrase used broadly to lend legitimacy to a new platform. A necessity for a platform to gain traction was that it have a so-called killer application. VisiCalc was the killer application for Apple. Lotus 1-2-3 was the killer application for MS-DOS. Excel was for Windows, and so on. The turn of the phrase was that Windows would be what could accelerate the internet.

There would be much truth in that.

On to 026. Blue Suede Pumas

Welcome to Chapter IV. The next series of sections detail one of the most interesting, exciting, and to many, troubling eras in the history of Microsoft. While Microsoft was busy developing Chicago (Windows 95) and rallying the entire company around that massive project and opportunity, an unprecedented and unstoppable force was taking root, the modern internet (back then it was called the Internet). Today we would refer to this as a disruptive technology change—a less capable, cheaper, alternative to all the things we were building, but the notion of a disruptive technology change was still years away from becoming business canon. This is the story of how the Internet happened to Microsoft—a story that has many participants and at least as many perspectives.

As Technical Assistant at the time I found myself in the middle as a facilitator but also an activist and champion. The personal growth that I experienced during this time would prove to be an incredible blessing that led to enduring friendships and amazing memories. At the same time, this was a period of remarkable turmoil and angst, mixed in with an unrelenting corporate urgency.

Let’s start with the online landscape of 1994?

Back to 023. ThinkWeek

The pending storm was all anyone was talking about as I completed the last few interviews at the end of my annual (or more) recruiting trip to Cornell in February 1994. As snow, and more snow, piled up, I knew I was not getting out that day as planned. This happened every other year or so.

What I did not know was that getting stuck would turn into a lesson on what it takes for a large and successful organization to change course and rally around something new.

Microsoft, and BillG in particular, were thinking about the opportunities online, as it was called. Russ Siegelman (RussS) focused on the opportunity. As a recently-hired fellow TA, he was exclusively looking at the existing world of online information services and connectivity.

The biggest online service by far was America Online (AOL); the dial-up service had membership of over two million households, and notably was equally accessible from both Windows and Macintosh. AOL along with CompuServe and Prodigy were collectively a sort of big three of online services and gave a bit of a feel that they were like TV networks and in some sense they operated that way with various forms of channels. In 1992, AOL released a Windows version of the software, which previously ran on MS-DOS, putting it at parity with Macintosh (I used it in graduate school with the screen name SHNOWZ, it’s still mine but that’s another story). Apple even had a deal with AOL that offered online services for Macintosh users on the AOL platform, and that in turn gave them leverage to develop exclusive online content deals with major media brands. That’s the kind of thing that would concern Microsoft.

Millions of people sent email to each other on AOL, participated in communities, and explored deep information services on finance, sports, entertainment, and more. All of this was done from within the AOL application.

Few, if any, at the time thought this approach, a so-called walled garden, was bad. In fact, most people thought it was the only way to “package up” a variety services and information sources. AOL uniquely combined services with an application that handled the complexities of connecting a computer modem to the service over a landline. It was slick. To attract customers, AOL was spreading floppy disks everywhere, through magazine inserts, cash register checkouts, and direct mail. It was growing fast, approaching $100 million in revenue.

AOL was so exciting that Microsoft cofounder PaulA became a major investor, much to the chagrin of the Microsoft competitive spirit. He even tried unsuccessfully to acquire controlling interest of the entire company. Paul correctly recused himself for several Board meetings during this time because of the ownership stake.

BillG was spending a great deal of time on the earliest stages of working with the “carriers,” or the phone companies, trying to navigate the right partnership model. Dial-up made these companies essential to the online world. Household high-speed connectivity was still years away with many predictions of timelines and technologies, but no approach seemed like it would take hold any time soon. In Europe, somewhat faster ISDN was useful to business customers, but globally connectivity was rooted in the traditional phone companies over dedicated connection-based lines, and slow.

The phone companies, and later the cable companies, were motivated to achieve more than their pipeline or carrier status. Both wanted to play in the world of content and services and own more of customer experience, especially for consumers. This led to a long series of discussion and eventually pilot projects between various players including Microsoft. The spectacle of giant companies navigating a new space while simultaneously partnering and competing (frenemies, or coopetition, terms that became popular in the increasingly intertwined PC industry) was a sight to be seen.

AT&T created a series of television commercials known as the “[Someday] You Will. . .” ads. These were slick visions of the future directed by David Fincher (Fight Club) and starring Jenna Elfman (Dharma & Greg), and narrated by Tom Selleck (Magnum, P.I.). They pitched a world in which one might borrow a book from thousands of miles away, watch any movie on demand, or even send a fax from the beach (that’s AT&T for you!).

Bill loved to talk about these exact concepts when meeting with various digital highway partners, so when I showed him the commercials I had taped at home, he seemed irked at the feeling of having his concepts “stolen.” The truth is everyone was talking about these broad ideas. AT&T happened to do a great job visualizing them. As we would learn, the part of the company that created these videos had nothing at all to do with the part of the company delivering products and services. It was pure vision marketing. There was a lot of that going on.

Microsoft was investing heavily in creating CD-ROM content and was in the early stages of a robust line of multimedia titles including Encarta encyclopedia and a whole series of interactive versions of beautiful books by Dorling Kindersley, from Dinosaurs to Dogs and Musical Instruments. We talked a great deal during ThinkWeek about how this experience could translate into a programmed online experience, though the limitations of bandwidth were obvious, especially after the compromises faced to get these to work on PCs.

Broadly, Bill’s Information at Your Fingertips (IAYF) vision loomed large. Unveiled at COMDEX, the massive computer industry tradeshow (COMDEX is a portmanteau of Computer Dealer Exchange), in November of 1990, IAYF presented a vision for computing years in the future that put important information in an integrated and seamless fashion a click away. To articulate IAYF, Microsoft made its first visionary video based on the fictional coffee company Twin Hills with an oddly familiar green logo (Twin Peaks filmed east of Seattle was as big a Northwest hit as our local coffee). Many of us, myself included, made it over to the library to watch it or secured one of the video tapes that were widely distributed.

There was also a very fancy brochure which I kept at the time as a reminder of our vision. I was definitely giddy about the future. It was a future where we moved seamlessly between applications, just pointing and clicking, editing rich documents filled with charts and graphs, connecting to rich information, and more. It was graphical. It was easy. It was what we loved to call a North Star.

The company would update to IAYF to be shown at the November 1994 COMDEX more than a year away. Recall those demonstrations from ThinkWeek about devices like General Magic, that would become the focus of the updated vision.

The roots of IAYF brought together two famous visions from the history of computing. In the July 1945 issue of The Atlantic, Director of the Office of Scientific Research and Development Dr. Vannevar Bush authored “As We May Think,” in which he described a futuristic information tool for the workplace:

Consider a future device for individual use, which is a sort of mechanized private file and library. It needs a name, and, to coin one at random, "memex" will do. A memex is a device in which an individual stores all his books, records, and communications, and which is mechanized so that it may be consulted with exceeding speed and flexibility. It is an enlarged intimate supplement to his memory.

The idea of having access to the world’s information was a key part of IAYF. Bush took it a step further and connected aspects of the information together:

All this is conventional, except for the projection forward of present-day mechanisms and gadgetry. It affords an immediate step, however, to associative indexing, the basic idea of which is a provision whereby any item may be caused at will to select immediately and automatically another. This is the essential feature of the memex. The process of tying two items together is the important thing.

This notion of tying two items together was widely present in the multimedia titles. This action became known as hypertext as originally described two decades after Bush’s essay in a seminal work by information theory pioneer Ted Nelson published in 1965 as Project Xanadu, the second major technology brought into IAYF. On the subsequent project Hypertext Editing System, Nelson worked closely with legendary computer science professor and founder of the computer science department at Brown University, Andries “Andy” van Dam, who later became among the first advisers to Microsoft Research.

Hypertext formed the foundation of multimedia titles and the training and help materials in Windows and Office, known as WinHelp, similar to the most mainstream use of hypertext, which was about to become incredibly interesting to Microsoft. It’s notable that Apple HyperCard for the Macintosh, released in 1987, made extensive use of hypertext and was a widely used modern commercial system that influenced a generation.

AOL was the reference point for online services and defined the experience we collectively believed was relevant. The idea of an online service that had the feel of a television network for the information superhighway while also working as a PC application seemed to check all the boxes.

The snow kept falling as I looked out the window of Cornell’s Statler Hotel. I was about to have my whole understanding of online services turned upside down.

On to 025. Trapped

People always seem to want to know the habits or techniques used by CEOs for managing the company. I’m not sure if that helps or not, but at the very least it can be interesting. Before I became Technical Assistant, Bill started on his own process of organizing time to get away and “think” which eventually became ThinkWeek. I put a good deal of energy into making ThinkWeek a more structured and productive time as the rise of email had a way of substituting email activity with the kind of deep learning Bill intended. Over the years, ThinkWeek achieved some sort of mythical qualities for some. While the process evolved to be rather different over later years, the early days were definitely something to look back on and reflect.

Back to 022. Injecting New Ideas and IQ: The Information Superhighway

Microsoft’s overall rhythm, the “rhythm of the company”, as SteveB later called it, was still in the formative stages. In the early 1990s, the company fiscal year budget drove most of the rhythm for executives. The performance review process tended to set a yearly rhythm for product groups, though the product schedule was the real master often trumping work on reviews. For BillG, who was always obsessive about planning out a calendar for himself, the rhythm that seemed to matter most to him was the twice-yearly ThinkWeek times he set aside (they weren’t a full week, but close). ThinkWeek had been mostly an informal time for Bill to catch up and to get away from the day-to-day of the CEO job and Redmond. Given the scope of thinking, it seemed an opportune time to up-level the process.

Bill’s family vacation house, Gateaway, was located on the Hood Canal, about two hours by car or by ferry from Redmond. The Canal was a favorite place for Bill and his family, and where he vacationed with his grandparents when he was young. It was peaceful and isolated.

Learning about ThinkWeek from AaronG, the previous TA, I decided to make it a much bigger deal than simply gathering materials from teams for Bill to read. ThinkWeek was a fascinating way to immerse Bill in the details of what was going on, not just at Microsoft but across the industry. I spent a month preparing (overachieving) for each of the three ThinkWeeks we had together. Bill offered some guidance each time, such as the topic of a memo(s) he wanted to write, or if there was a theme he wanted to explore. He would suggest I speak with specific people for ideas. I discretely pinged people 1:1 who I knew would not start big email chains with subject lines like “BILLG THINKWEEK!!!” The frontline leaders in program management offered the best suggestions that came without agendas.

I created a spreadsheet (of course) to track ideas for content across a wide range of formats: product plans, books, magazine articles, memos, and demonstrations. I had a field day at an office supply store buying filing boxes, color-coded folders, and labels to create banker’s boxes of ThinkWeek materials.

One of the ground rules I established was that I tried to avoid the use of ThinkWeek as a deadline or forcing function to rush to get something written just for the week. I generally insisted on memos and product plans that were already written for the normal course of work, and not special ThinkWeek pieces. I always felt these would confuse more than enlighten since there was no way of knowing if something was or would ever get connected to ongoing product development. Interestingly this is something that would completely reverse in a few years, when ThinkWeek would become more of a wide-open all-company brainstorming event.

The demos presented the most difficulty. In the early 1990s before software was released, it was almost always the case that a given product required a bunch of random hacks to work, and those hacks meant nothing else would run on that PC. Preparing a demo of something like a new version of Excel meant preparing an entire PC to demo only that version of Excel. This was also before laptops, so each ThinkWeek also meant there were a half dozen or more PCs that I had packed into my Jeep Cherokee (I was in my Northwest phase) along with reading material, all of which I delivered after he’d had one full day on his own.

Our first ThinkWeek together was in April of 1993, a few months after I started the job. The contents skewed toward the present, with the whole company immersed in the development of Chicago, Cairo, and finishing the first major release of Windows Office with new versions of Word, Excel, PowerPoint, and the Access database. Microsoft Research was getting started as well.

Bill was fixated on the need to gain more alignment and synergy across the product lines with respect to 32-bits, the shell, and more were still being settled. Execution plans were being put in place. Bill used ThinkWeek as a chance to delineate all the places where Microsoft could have a stronger strategy and leverage shared code more, to be more efficient in engineering effort, use less memory on running systems, and provide a more consistent experience for customers. He made a lot of lists. There were many core technologies to be developed and for each group to contribute to and use, rather than create more suboptimal redundancies.

An example of combining the high-altitude view with the ground-level perspective was demonstrated when we walked through many of the products under development and considered all the ways text was used and used inefficiently. Each product, Word, Excel, Publisher, Visual C++, Windows (itself had many places where text was used), and then all the CD-ROM products required what was called rich text—text with formatting, bullets, colors, numbering, alignment, fonts, and more. Each of those products built their own text capabilities, limited to what they believed they needed in the moment. Over time, each had many customer requests to improve that—examples, such as how Excel customers wanted to use multiple fonts within a single cell or how Publisher wanted to use bullets and numbering like Word. It was early enough in PCs that each product also had a different strategy for displaying text in languages with characters beyond the basics used in English and European languages. Some could handle Asian, some right-to-left, some vertical, but none could yet handle complex scripts like Arabic. We spent a few hours making a list of all the text inefficiencies while firing off mail to lots of people who then scrambled trying to figure out how best to say they were just doing what customers demanded or schedule permitted.

Andy Abbar (AndyAb) posted this to Facebook including the clip of the meeting: It was 1994! Microsoft Company meeting (Kingdome arena) in front of some 6,000 employees standing next to Mike Maples showcasing to the company, for the first time, Arabic text on Microsoft Word. My few seconds of fame Microsoft Old-timersThe nostalgia of the good old and fun day! #MEPD Alex Morcos (AlexMo), Ayman Aldahleh, Makarand Gadre, Jeff Gross, Mike Jaber, Bishara Kharoufeh, Wassef Haroun, David Yalovsky, Yaniv Feinberg, Samuel Abramovitz, Assem Abdullah Hijazi, Samer Karawi, and many others...”

A little back story is that the 1994 film True Lies was to feature not-yet-shipping Arabic Windows and Word in the opening scene and had just contacted Microsoft for help in making that happen—for the company meeting that year I helped get a copy of the ¾ inch video tape to use at the meeting to highlight worldwide innovation. The clip was the opening scene of the film when Arnold Schwarzenegger uses a rendering of Arabic Windows and Word. It was very exciting.

It was easy to look at such small details and ask, “Doesn’t a CEO have better things to do?” The company was maturing operationally and technologically, and the combination of the pace of change and the empowerment across teams meant topics like cross-product architecture were not yet part of the fabric of the company beyond Bill. Even within just one group, Desktop Apps (where I would work next), there was almost no code-sharing to facilitate the scenarios we experienced, just for text. If architecture didn’t matter to a CEO, problems like this could go on for years and no one would notice or even be rewarded for thinking them through. It was a key differentiator of Microsoft that the company was thinking across the broad product line at such a level of granularity, even if not everything was acted upon it served to reinforce a culture of alignment and synergy while maintaining a level of empowerment. All of this was contrasted with the absurd cross-company process IBM used, whose disenfranchisement was all too familiar to Microsoft—the Management Committee(s) or the crazy Common User Access interface standards that burdened (crushed) OS/2 before it even started.

This first ThinkWeek was also the first time Bill looked deeply at infrastructure for the information superhighway. The nascent internet would prove to be a time for very important memos from many people. In the next chapter I will cover the internet and the impact on Microsoft, including Bill’s first ThinkWeek impressions in late 1993.

I collected materials on all the ways the telco and cable companies believed consumers would connect to “the net” including X.25 dial-up, Asynchronous Transfer Mode, ISDN, and so on. I set up accounts on AOL and CompuServe, and we even dialed up to the original multiplayer game network Sierra Online, which Bill found intriguing (AT&T also found it intriguing and acquired it and made it even more intriguing). The email threads that followed these demos dug deep into the ways consumers would get high-speed connectivity to the home that was not cost-prohibitive or whether consumers got stuck at dial-up speeds. These challenges became important as the ideas for Marvel, the code name for the new Microsoft Network online service to be released with Chicago, were solidified, work that was newly under investigation and a big part of these discussions.

Product demos contrasted with deep technical reading and strategic discussions and offered a bit of a respite. The demos were extremely important to me as I felt I was representing the teams and wanted their work to shine. Normally a demo for pre-release products was a nail-biting experience even for those working on the product. They were using the product day in and day out and knew the landmines. I was given a script and told not to veer at all from the script. Good luck doing that with Bill.

One demo was for the forthcoming release of Microsoft Word for Windows, version 6.0, code name T3 (a nod to the film Terminator 2 that had been released when the project started). Word built a sort-of sophisticated rules engine into the product (eventually marketed as machine learning) to implement features that would automatically format a document, such as look for headings or numbered lists. I followed the demo script, but the feature did not seem to work, so we typed a basic letter including “Dear Bill” and “Sincerely” and then selected the Auto Format command from the Tools menu. A second or so later, nothing seemed to happen. Then Dear Bill turned into Dear Bill and Sincerely became Sincerely. That was it. Bill fired off mail and a scramble on the Word team ensued. Additional demo steps were provided later in the day.

The Chicago product was making progress. Pre-release builds leaked over the summer. Without the internet, leaks did not go far, but the trade press picked up on screenshots and extrapolated from there. The core question moved from synergy and alignment to whether Chicago was going to be competitive with Macintosh.

In subsequent ThinkWeeks, I structured most of the reading and materials and demonstrations around operating systems or applications taking advantage of the latest operating system capabilities like networking, storage, and multimedia.

The ACT (Advanced Consumer Technology) group was in the early stages of one of the earliest tablet computers Microsoft considered, code named WinPad, running on the Windows CE operating system, which was under development. Windows CE was the precursor to Windows Phone and was an implementation of parts of Windows for low-powered ARM chips (instead of Intel) and designed for stylus input. This was before the Palm Pilot that debuted in 1996, giving new life to the category of personal digital assistants, or PDAs (pioneered a decade earlier by devices such as the Psion). The primary competitor that was much more intriguing was from a company named General Magic with a product spun out of Apple by some of the original Macintosh developers. As General Magic was developing its product, Apple released the Newton, which while ultimately a failure, seemed competitively scary during ThinkWeek.

The external focus on indirect competitors was a hallmark of Bill’s approach to competition. The ACT team was thinking about the Newton and General Magic, but no one else at Microsoft was. For example, General Magic had invented a programming language called TeleScript, core to the way the platform could be extended. Historically, PDAs were more purpose-built devices and not rich platforms, and certainly not platforms with their own programming languages. From Bill’s perspective, BASIC was a key part of the early PC era, and it followed that a new platform with a pioneering new language would be a powerful combination. In poring over the documentation for TeleScript, it became clear that Microsoft would need to up its game in creating applications for a more connected world as envisioned by both Newton and General Magic.

The more traditional PC competition was much more focused on the direction Apple was taking Macintosh. Apple, under CEO John Scully, had repurposed a faltering project started years earlier called Taligent. The project had become the punchline for jokes about vaporware, but Apple sorely needed a more modern operating system. Chicago would be vastly superior to the current Macintosh in how modern it was relative to running more than one program at a time. Apple seemed stuck. Strangely, Taligent morphed into a partnership with IBM. In some ways, that made it difficult for Bill to take seriously the Taligent materials I provided for reading (there was no software)—he knew well the risks of a deep partnership with IBM (as did BradSi and the Chicago team). Bill did his best, though in classic style, to make the most of the risks that could come from Taligent executing. They had a much broader vision than Chicago that would never materialize. That did not stop Bill from using it as a competitive threat or risk when talking to the Chicago or Cairo teams.

Sometimes things didn’t always go as planned and one topic ended up taking up a big chunk of time. One ThinkWeek, we spent a good deal of time on the competition with Lotus Notes. The EMS project was starting to gain engineering traction and had sent over product specifications. The memo I previously wrote on using Visual Basic and Access with EMS was the topic of many email threads. Evenings were often spent watching videos. We watched a videotape of a keynote from Lotus CEO Jim Manzi with a demo of Lotus Notes that was definitely something that pushed those competitive buttons.

Bill wrote a detailed memo on competing with Lotus Notes, sharing his views of what he had learned, again using his perspective to stitch together the Microsoft organization. Up until that point, the field sales organization had only been raising the competitive risks of Notes but had nothing to respond with. Bill provided some guidance but mostly motivation to get our collective act together. He pointed out that selling email and workgroup software was a long process and required partners, industry analysts, demonstrations, and more. It was a good and specific motivator.

ThinkWeek would come and go. Emails would get responded to. Some people priding themselves on pulling together what was needed (and then some) in super short order and replying. Other replies would trickle in a week later. Memos would always fly around campus email even if they were only moderately interesting, they were still BillG memos. A few times a memo would be critically important to a group or the company.

The April 1994 ThinkWeek was my third and last. Bill devoted a good deal of time to writing his first strategic internet memo, which set the tone for the strategy the company would take going forward. We were fresh from the offsite on internet strategy and the memo was a chance to reflect on the important initiatives coming out of the gathering.

Bill was keenly aware of the ability for groups to craft unique strategies around a technology shift. He set out to make sure that teams across the company would not slow down the transition to an internet-centric strategy. Over the next couple of years, many would document Microsoft’s transformation from a desktop company to an internet company—this April 1994 memo was the moment that happened.

We spent a good deal of time going back and forth over what I saw as the risks that each group would “interpret” the internet differently and try to absorb different parts into their plans at different times and in different ways. Many groups were skeptical about the internet, including the new online service, multimedia and consumer, and the enterprise teams. The memo crafted a great line to open: “Product groups do not have to spend time studying the future of the Internet, or researching this phenomenon. We want to, and will, invest resources to be a leader Internet support, fully understanding that if we are wrong about this it will have been a mistake.”

About a year later, Bill repeated and amplified much of this memo in a loftier and more intentionally external missive that would receive wider distribution and wide acclaim, Internet Tidal Wave. While the April 1994 memo was a more standard list of technologies and owners (in other words, a memo to get work done), Tidal Wave a year later was an exciting narrative and combined with the imminent Windows 95 release, served as a much more dramatic moment in time.

There was more that year though. In fact, the company-changing products for 1995 were on the way. Chicago builds complete with the Start Menu, as we would come to know it, began to work well-enough to at least demonstrate, along with the 32-bit version of Office and a slate of soon to be Designed for Windows 95 products. The press visibility of Chicago energized the whole of Microsoft, still more than a year before shipping. We spent a good deal of time using the most recent Chicago builds, which was hugely motivating for Bill.

Given the rise of the internet and discussions fresh on our mind, ThinkWeek dove deeply into consumer and home computing, in particular content. The industry view at the time was content is king, an expression driving consolidations, mergers, partnerships, and more across the telephone carriers, cable companies, Hollywood, and online services, especially AOL. The idea that the internet would be used to operate businesses was not mainstream at all, with the focus on the internet as a potential consumer information superhighway technology.

The Consumer division invested heavily in creating CD-ROM titles—applications that required a CD-ROM on a PC along with capabilities to play video and audio, which were relatively new—having these titles was an important differentiator for Windows. Chicago promised to make using multimedia even easier and more reliable with better hardware support and less of a need for consumers to struggle just to get sound to play on a PC. I assembled a portable multimedia computer, a suitcase-size PC weighing 20 pounds, and loaded up over 40 multimedia titles. We spent hours exploring a wide variety of topics from Autos to Strauss, from the JFK Assassination to Earthquake Preparedness, as well as a variety of games for all ages.

Bill wrote detailed feedback on these titles, not from a user review perspective but from a strategic perspective. Could these titles be repurposed on the Marvel online service? Shouldn’t titles have more quizzes, reference materials such as maps, and always more videos (tiny little postage stamp sized videos!)? Many of the titles would transition to be part of Marvel in some form or another, and all would be important parts of articulating the broader internet message beyond simply protocols and formats.

ThinkWeek was intense, but it was also fun. We would sit upstairs in the loft of the vacation house drinking endless Diet Coke (Bill was just starting his Cherry Coke phase under the influence of Warren Buffett, whom he’d met two years earlier at Hood Canal). We had a great time hacking away at all the pre-release software, making lists, diagramming on the whiteboard, and keeping an eye on email threads (even for Bill, connectivity was dial up). There was no pretense and truly no distractions other than the weather, which I had to keep an eye on because of the ferry ride. We spent perhaps 12-15 hours each day with breaks when mostly we’d just do our own email.

Sometimes the “thinking” would be interrupted by some Microsoft issue of urgency (like the FTC or DOJ) or even something outside of work. There was always something to distract and I had to do my best to help focus on the memo writing goals or making it through demos (the disappointment from teams who put together demos only to find out that we didn’t have time sometimes forced me to stretch the truth a bit about going through the demo).

One unique distraction was ultimately documented in a January 1994 article in The New Yorker, “E-Mail From Bill” in which John Seabrook chronicled his ongoing conversation over email with Bill on topics ranging from personal job satisfaction to innovation. There were a lot of highbrow conversations about the information superhighway. Mostly the article is a time capsule trying to explain the Microsoft culture and even the culture of email to readers of The New Yorker, most of whom were years away from email.

At the end of each week, I’d pack up all the desktop and laptop PCs, boxes, and books and come back to the office to return everything. The folders of photocopied articles and memos organized by topic would travel around with Bill in one of his two carry-on bags, sometimes for months. Then one day an email out of the blue would reference that lone article on ATM or micro-payments or something.

The real legwork was going back and thanking all the people that put together demos and materials and doing my best to give them a play-by-play of any interactions while being careful not to have that influence anything other than morale.

On to 024. Discovering “Cornell is WIRED!” [Chapter IV]

In 1993, it would have been difficult to overstate the hype surrounding the “Information Superhighway”. Whatever definition or capabilities it might have, it consumed the imaginations of everyone from Wall Street to Main Street with magazine covers, morning news show pieces, investor conferences, and more. Microsoft had risen with the juggernauts of MS-DOS, Windows, and soon Office and found itself, surprisingly, at the nexus of Hollywood, newspapers, cable TV companies, and telephone companies each believing they would come to dominate the highway. Only one thing was missing and that was some software to power it. Could Microsoft be that “vendor” or would software be so central that Microsoft would come to dominate the very nature of information delivered to the home as some felt it already dominated computing. Fear of Microsoft, and fear of Bill Gates, began to dominate. Gone were the wonders of the programming nerds in the Pacific Northwest.

Back to 021. Expanding Breadth versus Coherency: The EMS Project

Whenever I was feeling caught between shipping products and big vision or hearing about a product that was deep in bugs and had an unpredictable ship date, I could be rescued from my supply closet of an office by a demonstration from Microsoft Research (MSR) or the Advanced Consumer Technology group (ACT).

Bill viewed the gathering of the level of “IQ” and experience in these groups with great pride and a good deal of personal effort, as he often personally recruited them. Icons filled the rosters of the two teams over the years: Jim Gray, pioneer in databases; Chuck Thacker, coinventor of ethernet networking; Gary Starkweather, inventor of the laser printer; Alvy Ray Smith, Academy Award winner, cofounder of Pixar, and inventor of alpha channel in graphics; and Butler Lampson, founding member of Xerox PARC and inventor of the personal computer—and those were just the people hired in the early 1990s. I sometimes had to pinch myself that I even got to meet these legends. When Butler Lampson (BLampson) was being recruited I was asked to take him to lunch, but I was mostly starstruck.

NathanM and Craig Mundie  (CraigMu, who at the time reported to Nathan) were a yin and yang. NathanM and Craig Mundie (CraigMu, who at the time reported to Nathan) were a yin and yang. Nathan brought an eclectic background in physics and science, though he founded a PC software company acquired by Microsoft that brought him to the company, among others including DavidW the pioneering Windows engineer. CraigMu was an industry veteran, having seen the entire arc of computing. He got his start at legendary Data General then ultimately started a well-known supercomputer company, Alliant. The company fell victim to the advances of Moore’s law, which brought him to Microsoft, “having seen failure,” as BillG used to say. Officially Craig was leading the Windows CE project, Microsoft’s first efforts in mobile, but he often managed, formally or informally, advanced projects and an ever-expanding portfolio. Part of the yin to Nathan’s yang was that Craig was a former CEO of a larger company and a technology industry veteran.

The information superhighway, as it was called, was front and center of all the future discussions BillG and NathanM were involved in. The internet, as we think of it today, was more than a year away when I first started as TA, though the first version of the Mosaic browser was released in the summer of 1993. The highway was how the phone companies and cable television companies described accessing information over their respective networks. Bill’s first book, which he began writing around this time, was titled The Road Ahead (1995) and spoke quite a bit about this metaphorical highway. The cover photo by Annie Leibovitz even featured Bill on a lone stretch of highway. In public, Bill was a bit of a realist about the timeline and who would “win”. The highway was the first time as a public company that Microsoft faced a huge mainstream hype cycle. Part of this cycle were alternating predictions about how Microsoft with come to dominate the superhighway or how Microsoft was missing out.

Prior to the internet, much of the discussion in BillG meetings looked like the internet, only it used proprietary software and required dedicated hardware devices from Microsoft, phone companies, or cable companies, and mostly worked only over private networks of leased lines running proprietary protocols or archaic phone company standards. The Information at Your Fingertips vision (more on this in a future post), first articulated in 1990, looked a lot like the internet would come to be in a very short time, but with an entirely different implementation.

While there was no single definition of the Superhighway, the common articulation was the idea that a wide variety of consumer services would be available directly to home computers using a new type of data connectivity offered by phone or cable companies (the obvious incumbents with wires to the house). Common examples offered were news, weather, sports, stock market, movie listings, shopping (like at a mall), along with communication services over voice and video. So basically, not unlike a local newspaper.

Cable companies were extremely interested in offering one of the most forward-looking services one could imagine at the time, video on demand. Imagine watching any show anywhere, anytime. Most of us were still kicking ourselves if we forgot to put a blank tape in the VCR to record Seinfeld or if we had to go to Blockbuster in the rain in the hopes of finding a movie to rent. The early time shifting digital recorder from ReplayTV was not yet released. In fact, there was not even an electronic program guide to know what was on television (some cable systems had a guide on a separate channel that scrolled by continuously).

No one really had any idea how to deliver video on demand, especially in a world where there was intense fear that a movie could be recorded, or stolen, and copied on to videotapes and sold on the street corner. The technology required to digitally encode a video was enormous. It had to store a massive amount of information (CD-ROMs held about 700 megabytes, which was about seven minutes of TV-quality uncompressed video), transmit the video to households reliably, provide program listings and remote control, such as pause for breaks, and so on. In 1994 we were a long way away from home DVRs or DVD movies. Even HDTV remained years off.

Yet, somehow, one day I walked into a conference room with BillG and we saw a demonstration of all of those pieces working. A program guide of movies to choose from, select a movie, instantly begin to watch it. It was one of the more impressive demonstrations I had seen—it wasn’t a fake demo made with Director or AuthorWare but real code from Microsoft Research. NathanM called the product Tiger, which was a code name for an MSR lab project developing a file server that could reliably move files around in real time. For this demo, the Tiger file system was used to deliver compressed video streams to a PC. The demo showed many PCs receiving different movies, each with their own pause/rewind/fast-forward controls. Mind blown.

Nathan detailed how this system worked, using a dozen or more Windows NT Servers connected to large collections of high-speed disk drives, connected together with the highest speed networking available. The architecture he spoke poetically about was the biggest problem they could foresee. Storing thousands of movies required a lot of disk drives, and unfortunately disk drives on PC servers were not particularly reliable. Nathan walked through the math for us—computing the mean-time-between-failure of drives, number of drives, and number of movies. His eyes got bigger and bigger as he got to the punchline, which was that a system like this would see failing disk drives as the bottleneck and “we’ll need people on roller skates—like in the old days when computers had vacuum tubes—replacing disks as they failed.” It was a colorful metaphor for a system decades ahead of its time.

Tiger generated a huge amount of interest from cable companies. Many wanted to immediately deploy it, but while they had been counting on networking capabilities into homes, there were none yet. Tiger also represented the collective view of Microsoft’s immense industry power—if it could conjure a remarkable system like this and extend the control of the PC to the living room, what could Microsoft not accomplish? The press reports of Tiger simply stated as fact that Microsoft would control of the information superhighway, too.

Tiger, which really was a research project and had no product team structure around it at the time, became somewhat of a lynchpin in multi-way discussions Bill, Nathan, and Craig found themselves involved in. On the one hand, there was an industry that made cable TV tuner boxes each of them jockeying for a role in making the device that would sell millions to the cable companies to replace low tech CATV tuners. On the other hand, were the carriers, cable and telephone, who were trying to out-maneuver each other to gain the upper hand in being the pipeline to the home, and with that the ability to control the flow of information, the services offered, and to earn incremental revenue for everything on the system. There were also the content providers who owned everything interesting. For months, Bill, Nathan, and Craig met with CEOs across these industries. At one point Microsoft entered into a pilot project with Time Warner that garnered ongoing national news about the rollout of the superhighway.

Microsoft found itself in a new position. By some accounts it was poised to dominate the future of information services to the home. By other accounts it was going to provide plumbing to the massive companies already providing cable and voice services. But with announcements from all those companies almost constantly about pilots, prototypes, partnerships and more, many thought Microsoft was behind because it wasn’t in all the announcements. Microsoft was at the same time in the early days of being one of the most dominant US companies, including early investigations by the Federal Trade Commission. Microsoft the nerdy tech company found itself front and center in entirely new industries. It was crazy. And all we had was Tiger and Windows PCs. What product would Microsoft even make?

Like so many of the innovation-oriented projects, Tiger was so far ahead as to be unable to connect to the here and now. Customers were not prepared to deploy and manage thousands of Windows Servers, consumers did not have high-speed networking, and even Hollywood was not ready to distribute video this way. The path from Tiger to today’s streaming services (that Microsoft is not part of) does not represent a series of missteps by Microsoft but rather a series of additional technologies and marketplace expectations that completely discounted how Tiger approached the difference with streaming as we came to know it. It is fun to think about how early the vision was, but as is so often the case when you dive in you realize all the assumptions made were the wrong ones and all the technologies needed were generations away from being ready to solve the problem.

Fumbling the Future: How Xerox Invented, then Ignored, the First Personal Computer, a book detailing how Xerox invented the PC but failed to capitalize on it, was top of mind for BillG. It was a tragic story, and one Microsoft did not want to repeat. Being aware of the challenge and avoiding falling victim to it are different things. Nobody wants to be wildly underestimated or misunderstood when history is presented.

The technology world eventually solved Nathan’s disk drive problem, but it wasn’t Microsoft’s answer.

Microsoft and the world around Windows NT followed the path of IBM mainframes and continued to work to make disk drives and the software more reliable—redundancy, quality control, and more increased the costs per megabyte and made it even more difficult to scale to huge data volumes. A new company came along to solve this problem, taking the exact opposite approach. Google, not even a company for another five years, would invent what came to be known as GFS, which stood for the Google File System early in the millennium. It used cheap commodity disks (like the kind in a home PC, not those used for data centers) and designed a system that assumed the disks would fail. As such, the idea of replacing them quickly like vacuum tubes was unnecessary. Coincidently, the lead inventor of GFS was a classmate of mine from Cornell who also worked on the Cornell Synthesizer project—that revolutionary programming tool that influenced many of our ideas in Visual C++. Small world.

In hindsight, it was easy, especially during the down times of Microsoft, to become cynical over the company’s inability to commercialize legitimate inventions such as Tiger. Beyond Bill’s expansive vision for the role software and computing could play, it was also a management and organization approach that allowed projects to incubate. In particular, the very experience that influenced both Apple Macintosh and Microsoft Windows, visits to Xerox PARC, the birthplace of the PC and graphical operating system, was front and center of Bill’s efforts to develop innovative projects and to commercialize them.

What I learned, and only in hindsight, is that visualizing the future and even providing working prototypes of it cannot account for the ability of the marketplace, customers, or even the most cost-effective technology approaches to make something a reality. The technology industry is littered with ideas before their time, and to find fault in those companies or leaders for not capitalizing is almost always in error. Tiger was not on a path to be a commercial streaming service. Deploying it, as we saw it in 1994, wasn’t remotely possible.

Years later, as Microsoft hit rough patches in innovation and leadership, people pointed to many of the projects from the 1990s and asked what happened. BillG led and empowered visions across nearly every computing domain, but the under-pinning of them was the assumptions that built Microsoft—PCs, Windows, Win32, and then Windows Server held together with a client-server architecture. If those weren’t the right ingredients, then building with them didn’t create a path to some future. At the time, however, those were the only ingredients, so it made total sense to be using them. Faulting Microsoft for building with Windows in the 1990s would have been as crazy as faulting IBM for using mainframes in the 1970s or criticizing Detroit for building cars with internal combustion engines in the 1990s. What is impossible to see is when those ingredients cease to become assets and turn into liabilities. What really does happen is that those new entrants seeking to invent a new future deliberately take different approaches to solving problems and in doing so intentionally avoid following in the footsteps of the incumbent. They too often fail, but the world hardly notices…until one succeeds.

The pattern of Microsoft being early to so many innovative spaces often omits the challenges that existed at the time. When you’re early many of the ingredients required—like the internet, high-speed networking, faster processors, long battery life, touch screens, pen digitizers, and so on—are simply not there. That means the products aren’t ready to be built. When a new generation of product takes off it is rarely an invention; rather, it builds on the many early failures that came before.

In my role I was supposed to be eyes and ears, but I struggled with how to overcome what I saw as potential blind spots. It was never difficult to show new technologies to Bill and he was ready, willing, and able to absorb new information and incorporate it (or not) into his world view. At the same time, he seemed to over-index on the complex or sophisticated, seeing those as a moat or strategic advantage. Simple solutions did not have the appeal that a complex solution did, one that required the IQ of MSR or “deep architectural thinking”.  The researchers also valued complexity. The product teams tended to avoid complexity, seeing edge cases and boundary conditions as the enemy of shipping. This aversion to complexity looked almost lazy, as though there was a fear of taking on the hard problems and solving them. Worse, simplicity looked expeditious as though there was an attempt to get full credit for a solution by doing only part of the work. Seriously though, who was I to raise these questions? What did I know?

Bill saw products as built out of components of technology and each of those components needed to be the most sophisticated and singular across the company. The best text control, the best forms package, the best directory, and the best database each were ingredients that allowed him to take a product like the information superhighway or Lotus Notes and break it down and assign those components to the very best people to build the parts. There was a blind spot there.

Who would stitch those pieces together to make a product? Was Lotus Notes really a database, forms package, and a programming language? Was video on demand really Tiger plus some user-interface code? The hands-on experience on MS-DOS and Windows seemed to have enshrined the lesson that building components was the winning strategy and developers would provide the rest of technology to create a full product experience. The Applications teams were learning the exact opposite lesson—that winning was about the complete experience and having the most advanced high-tech pieces without stitching them into a product was not all that useful.

The two cultures at Microsoft (MikeMap’s two gardens) yielded different results for different reasons, and they both worked.

What I did have a handle on was shipping and products. In my (only) five years and innumerable stories about shipping I had heard, I definitely believed I could tell the difference between something that was real and something that was mostly slides. Bill did not always see things this way. He gravitated towards the technology view and was less interested in the process and mechanics of shipping. When a project like Cairo or Tiger needed him to push on shipping he was more comfortable continuing the technology discussion. The NT and EMS teams were happy to engage on the technology discussion, but in a sense kept those at arm’s length while they dedicated themselves to making the tradeoffs for shipping.

Most any leader setting this tone would have had far more projects ultimately end like Tiger, but Bill had one enormous strength that made the company what it was. He did not hire only people in his image. Rather he balanced his technology leadership with product (and sales, marketing, operations, etc.) leadership and also empowered those people to get their jobs done. They just had to put up with those deep technology discussions and have good answers to them. MikeMap, PaulMa, PeteH, BradSi, ChrisP, JonDe, and on and on filled out the product building ranks and were given the latitude to execute. I soon found myself spending my time as a TA trying to amplify those voices, while (too) often showing the effort required to go from technology to product.

On to 023. ThinkWeek

Back to 020. Innovation versus Shipping: The Cairo Project

Through Microsoft Office, even the first versions, Microsoft sold a primitive form of email that worked for small groups of people in the same physical offices. Delivering enterprise email that worked for a company the size of Microsoft, and many times larger (though it would be years before companies would use email the way Microsoft did) was a massive undertaking. The product would become known as Microsoft Exchange and formed the cornerstone of the entire Microsoft enterprise strategy. If you’re looking for an analogy, Exchange was to Windows Server and enterprise computing as Excel was to Windows and the PC desktop. At least I think so. This is a look at the early days from the perspective of BillG strategy and management.

Nearly all of my job as TA involved email—long, detailed, memos written as email. BillG routinely emailed weekend or late-night missives prompting response chains that would go on for hours. Not missing a “thread” was part of the culture.

Microsoft did not use its own product for email. Well, it sort of did. Microsoft’s email ran on Xenix, a precursor to the Linux operating system, and typically a mail PC was issued that was a dumb terminal connected directly to Xenix computers. Mail was simple plain text with no formatting. Using attachments could be awkward. To alleviate the annoyance of using command lines for email, product team developers wrote mail programs to use in MS-DOS and later Windows that copied mail from Xenix and made it easy to use mail in character mode (WzMail) or GUI mode (WinMail). Given how much time we spent in email, there was no shortage of efforts to build mail programs as side projects. I was a hold out and continued to use my Xenix terminal for as long as they were supported. The big disadvantage to these tools was that all your mail was copied down from the Xenix server to a PC—if your PC hard drive crashed you also lost your mail. Clever people figured out all sorts of ways to avoid this failure point, only pointing out just how important email was and how much time and effort typical employees put into just keeping it working. Windows hanging in the middle of drafting a long message or reply was the sort of thing that ruined your day and happened all too frequently. Everyone had email horror stories.

The rest of the corporate world was light years behind Microsoft and almost never used email outside of the technology teams or other companies in the software and technology industries. IBM was the leader in corporate email, using an arcane mainframe system, Professional Office Systems (PROFS), made famous by Oliver North in the Iran-Contra hearings. Since nobody in the PC industry had mainframes, email was a collection of ad hoc tools and systems that worked well only for relatively small companies, like the one mail product Microsoft had called Microsoft Mail. Microsoft Mail competed with a Lotus-acquired product called cc:Mail, which dominated the email category to the degree it existed. Microsoft Mail was based first on a licensed Macintosh product and then subsequent versions were based on technology acquired from a Canadian company called Network Courier held by Consumers Software.

There were many other products. I installed and used several of them during my summer internships when simply connecting the computers together was difficult. These early products were built on basic infrastructure of sharing files over dedicated networks—a mailbox was simply a file on another computer and sending mail was for all practical purposes reading data from one file and copying it to another. I’m simplifying for effect.

Because email relied on connecting one set of mail products to another, there was a time when the big telephone companies believed they would provide email service much the same way that they provided voice connectivity, especially since mail between companies involved phone lines. This led to attempts to standardize email using Byzantine standards that only phone companies could love.

While all this was going on, one of the first substantial Windows programs, designed by Ray Ozzie at a company called Iris, owned by Lotus but kept independent in a nod to the difficulty of developing innovative products within an established leader, increasingly gained momentum. The product, Lotus Notes, was a platform for building custom applications that could run on several different operating systems as well as being a rich graphical application. It was also an email program. Notes created a new category called workgroup computing. Even though Notes competed with Microsoft, Ray Ozzie and the team received a Windows Pioneer Award in 1994 at a ceremony honoring the most significant third-party contributions to the creation of Windows.

Notes had an architectural appeal that cut right to the core of everything Microsoft valued. It ran on PC hardware. It was designed for Windows. It worked whether connected to the network or temporarily offline. Most of all, it was a platform with a database and a programming language, a flagship product for the PC era. The capabilities of Notes touched on every group in the company—effectively competing required Microsoft to marshal teams, and, more importantly, to change plans, for most every division. There’s a great lesson in big companies competing—the best way to compete is to build a product that spans business units or divisions as Lotus had managed to do. Ideally the core of the product would land squarely between two business units, creating a standoff of sorts between those groups as they decided how to compete.

Microsoft needed to compete. Microsoft, however, had nothing. That’s an overstatement in sense. We were selling Microsoft Mail, but we weren’t even using it internally. To complicate our internal mail architecture, we actually used the companion product for scheduling meetings called Schedule+ even though we did not use the mail product. In Microspeak, when scheduling a meeting people would often say “send me an S plus” or “Schedule plus me” – lingo that would stick around years after that product was no longer used.

A new team under MikeMap was created to build email for corporations with the acquisition of Network Courier in 1991. The importance of email was certain, though it would be five or even ten years until corporations saw email as a workplace standard. More important than email itself was building email to take advantage of the new Windows Server platform. Windows Server was still very new and part of the dual mission of NT in addition to Workstation. Version 1.0 (officially version 3.1) did not ship until mid-1993, and it would be 1996 before the first broadly used release was completed, NT 4.0. BillG’s strategy for a platform was to build the platform strength by also building apps and create strength in apps by making a singular bet on a new platform—deliberately creating the virtuous cycle. This was especially important in the early days of the platform when it was difficult to get existing companies to bet on something that might not be commercial for years. That was exactly the goal of the new EMS team—Enterprise Mail System (or sometimes Messaging, with an early code name Mercury, as in messaging).

No one had ever built email on Windows Server using the new architecture approach called client-server that Windows was designed to support. Significant internet standards for email did not yet exist reliably (the familiar @ sign was decades old, but routing email around, use of anything more than plain text in messages, attachments, and more were still flaky). Windows Server did not yet exist. Tom Evslin (TomEv) was brought to Microsoft via an acquisition (Solutions, Inc. which made Mail software used in Mac Office in 1990) ultimately to lead EMS engineering. He brought with him detailed knowledge and experience in email and experience with the challenges of scaling email to hundreds or thousands of people. Microsoft, with its history of personal computing, had yet to internalize how different computing and data storage would be when running on servers or meeting the needs of thousands of simultaneous users using PC servers, and how different it would be to sell and deploy mission critical data center software.

There was a lot for me to dive into as TA. I had to figure out how to frame the challenges the team faced so that BillG was effective in driving his strategy. Given how much the team needed to do—and I was empathetic—it would have been easier and more straightforward to minimize the reliance or dependency on other parts of Microsoft. As Bill reiterated on many occasions, that was not the sort of strategic approach Microsoft benefited from—in fact, Lotus Notes was already succeeding by not relying on Microsoft all that much, even emphasizing its cross-platform capabilities.

Just as word processing and spreadsheets were the anchors of the Windows ecosystem flywheel, Bill decided that email and database were the anchors of the server flywheel under development. The database efforts were spearheaded by David Vaskevitch (DavidV), a longtime enterprise advocate within Microsoft and database expert. The database under development was Microsoft’s variant of an industry standard known as SQL, a category dominated by giants like IBM and Oracle (Oracle in 1993 had $1.5 billion in revenue, growing 30 percent or more per year). SQL was designed to handle highly structured information like inventory or financial transactions, which was different than the relatively arbitrary information in email. In other words, SQL was not designed to handle email. SQL had become so dominant that there was not a data storage problem that advocates of its core technology were not working hard to solve using SQL.

The third triad of the server ecosystem was the directory—or, basically, the list of all the users and computers that were part of the network. The directory, from the earliest days of NT, was an integral part of the system known as simply as NT Directory (the name Active Directory would come later). The key competitor to Windows NT was Novell and they sold a separate product as a directory, so Microsoft’s strategy would be to integrate it with its new server product as was typically done in technology. The NT directory was, however, not designed to handle all the capabilities required for email. In practical terms, Microsoft was in the earliest days of deploying NT Directory, which was proving to be enormously complex and extremely difficult to operate.

In the ideal, EMS would be architected to use SQL to store email and the Windows NT directory to keep track of all the user email addresses. To compete with Lotus Notes, EMS should use Visual Basic to create the user interface for customer-developed applications. Discussion along these lines happened almost continuously. Every time the EMS team mentioned some product feature or engineering challenge, it seemed like they received feedback over how much easier it would be if they would just use SQL and NT Directory. When those were not the answer, then building on the enhanced capabilities of Cairo would serve as a placeholder for solving problems in the best architectural manner. The easiest way to characterize this is that every time EMS showed something that looked like a hierarchy of folders with items (mail messages), they would get feedback about how they should be representing that in SQL the way business applications routinely do for sales by region, country, district, etc. And failing that, they would then be told to “go talk to Cairo” who was building a way to view folders and files using SQL, so they were solving the problem. Predictably, every time the EMS team came back saying it would be better to implement something on their own, it was received as a justification for failing to think strategically.  It was messy and uncomfortable, and slowing progress to compete with Notes (which did not use SQL or the file system).

At some level of abstraction such a technology approach made sense. Building the product this way, however, amounted to crazy talk. That is what I heard as I practiced reconnaissance and shuttle diplomacy across teams. I found myself between two entirely different cross-team debates. Cairo debates seemed somewhat academic compared to EMS debates, which were rooted in getting a more practical product to work at scale.

For storage, EMS had no intention of using a commercial SQL database. Attempting to represent mail in such a structured manner had been tried before (Oracle was famously trying and not delivering). The allure was great—the industry rallied around SQL and was investing heavily in tools and infrastructure to standardize on SQL as data moved off mainframes. At the same time, the SQL team was lobbying hard for reusing all of this effort knowing that building for scale and reliability was a full-time job and they were certain that EMS would end up duplicating their work, while also trying to build email. In a sense they were correct in that any storage technology EMS used would also require them to build capabilities to scale to huge storage requirements across many computers, tools to manage all those computers and disks, as well as backup and restore should anything go wrong.

This dynamic happened so many times. A team building something new appeared determined to rebuild something that already existed because the requirements for what they needed could not be met by the existing product. At the same time, the existing product team was busy trying to win in their market and didn’t have time to take on the special requests from the new product team that had never shipped anything. As a result, Microsoft dev teams got very good at articulating reasons why some piece of code was not good for what they needed and at the same time product teams got very good at explaining why their schedule did not permit them to add special features. We never seemed to master having a rational discussion. Over many talks, BillG would admit to me that part of his reason for staking such extremes was his hope of making some progress. He knew realistically teams would end up somewhere less than he hoped, but if he started there they would end up with even less. Hearing this kind of bugged me because it sounded like everyone was playing a game of some sort. It did not sound like JeffH “promise and deliver” that I had been schooled in.

I wrote endless late-night emails summarizing the pros and cons of different data storage approaches for BillG, and there were many meetings and discussions that followed. This topic came up at almost every meeting where developing applications for NT was discussed. I was in a database group in graduate school and sympathetic to the realities outlined by SQL. But I was also part of a team looking beyond the 1970s SQL model to a new object-oriented data model (there’s that buzzword again) and was sympathetic to the new styles of usage. EMS opted for being in control of its own destiny, a decision that was not difficult for them to defend on technical grounds. EMS spent the better part of the next decade scaling the product, officially named Exchange, and working on scale and reliability, exactly as the SQL team predicted. Likewise, every limitation that Exchange faced when it came to building applications on top of the platform were exactly like the SQL team predicted. To the credit of the Exchange team, SQL did not end up being the right solution for email. In fact, huge email systems today were built using something called NoSQL, decidedly not SQL (my intent is not to start a database war as I am sure some will argue semantics over what constitutes SQL versus NoSQL).

The debate over the directory was quite different. In this case BillG had two groups, each on a path to ship and each deeply strategic. The sales proposition to customers could not be that there was one place to store all the employee names for when they signed on to the network to print or share files and an entirely different place for when employees used email. The entire purpose of a directory was to have a single source of truth for security and identity within an organization.

Windows NT was on a mission to ship, with the RTM months away and the beta already out there. The product was still quite early for customers and the directory worked in specific ways but was not yet all it had promised to be, as was typical with a 1.0 product of the era. Microsoft IT was in the process of architecting and deploying the directory for the company and wrote a huge white paper in collaboration with the NT team on how that would work. I showed this to BillG and we both marveled at the complexity—not in the positive way, but more like yikes. It was page after page of graphs showing servers in different countries required with backups, redundancy, and overnight processes to keep everything in sync so there was one master copy of the directory. It was a massive undertaking.

That proved to be a defining moment because deploying a directory was hugely complex and there was no way EMS could do it twice. In one of the rare times an architectural choice was pushed to a team, using the directory from NT became a requirement for EMS. Many others supported this, including the Server leadership. It was to them as natural as pushing Excel to use Windows—the directory was that core to NT Server—while sharing files and printers was the baseline scenario, it was the directory that brought deep enterprise value to customers. For the better part of the following year or more, EMS would not speak well of using the NT Directory, and conversely the NT team felt that EMS was trying to use the Directory in ways it was not designed to be used. This sounded to me a lot like getting Excel to work on Windows, and it played out exactly that way. Had EMS not used NT Directory, it is likely Directory never would have achieved critical mass as the defining app for the client-server era (and remained the cloud anchor for today’s Office 365). And conversely, had the NT team not met the needs of EMS, then the NT Directory would have likely been sidelined by the rising importance of the email directory in EMS. Forcing this issue, while it might be an exception, only proved the strength of a strategic bet when it is made and executed. Still, it was painful.

Developing applications for EMS turned out to be an endless series of missteps in strategy. Notes had risen to popularity as a platform for building applications. Customers buying Notes were building incredibly cool applications for tracking all sorts of line of business processes and corporate knowledge management, which also happened to be key buzzwords in business at the time. Everywhere our sales teams engaged, they saw customers piloting applications they had written internally or with help from the giant consulting firms. These applications were often the highlight of Chief Information Officers and used to show how cutting edge a large enterprise was. While they ran on Windows, they did not use any strategic (and new) Microsoft software except maybe Word and Excel files. They did not use SQL Server, NT Server, and Notes was a substitute for EMS. Even worse, Notes had its own programming tools so Visual Basic was not even part of these applications. It was a nightmare!

My contribution to the mess was a long memo outlining how to “package up” EMS, Visual Basic, and Microsoft Access (the database in Office) to compete with Notes. It was the kind of memo I wrote knowing that it was exceedingly tactical and would never win in a competitive review. Importantly, none of the teams thought doing a project like I described was their job. Everyone was busy with their own category. I worked super hard, creating screenshots, architecture diagrams, and more. Bill really wanted a team to run with this. No one was interested. I felt this left us totally exposed to compete with Notes, and Bill agreed.

What neither of us saw was that the market for custom applications built on top of email was not nearly as interesting to customers as simply getting email to all employees. In a sense, Notes had made the same miscalculation. To Notes, email was one kind of application to be built with Notes (that happened to be built by the Notes team). With EMS, email was the application, and the only one (until the Outlook email program came along to add integrated scheduling). The grander vision for the category fell victim to the near-term needs of customers. Microsoft’s sales teams would use the techniques I outlined in my memo over the coming years to sell against Notes, but few customers built and deployed applications that way. Email was the killer application for Windows NT Server and the Directory, at least until the internet came along. Importantly, email was the killer application that every company needed to roll out to every employee. It didn’t hurt that NT Directory was itself a killer application just for rolling out shared folders and printers. The virtuous cycle between these products was unlike anything, perhaps even greater than Excel and Windows.

Perhaps the biggest (and in many ways most painful) experience in building out EMS was Microsoft’s own transition to using the product internally. Email was the most mission critical software at Microsoft, probably even more important than any billing and accounting software. Every single employee used email. Part of building EMS was figuring out how to get it deployed to all of Microsoft, and by SteveB goal to do so before the product shipped to customers. In other words, Microsoft needed to be self-hosted on EMS before paying customers. Makes sense.

The EMS team (and of course the NT team because everything ran on NT Server) were pioneers in the idea of dogfooding products and created a whole new infrastructure where the team itself ran on the very latest builds, then a large set of partners and friends ran on slightly older but more stable servers, and then ultimately Microsoft’s IT department supported the rest of the company through a migration from the old Xenix system to EMS. The team was incredible at keeping servers running and keeping mail delivered. While there was downtime, when that happened pagers went off and people ran to the office to fix bugs. The team put these same skills to work with a small set of first external customers which received the highest level in support so they too could be part of the initial launch of the product, validating how it worked reliably and seamlessly for hundreds of thousands of mailboxes. When people ask me the true start of Microsoft’s enterprise approach to building and selling products, this dogfood process was absolutely ground zero and key to Microsoft’s long-term success.  The process was heavy-handed and brutal on the partner teams (as I would learn building Outlook) but it is not clear there was another way. Running Exchange email turned out to be one of the most complex asks of our enterprise customers and something that was by all accounts nearly impossible to get right (secure, reliable, etc.) unless you were the dogfood team. At the same time, there were no alternatives. The reality of software hardly working at all moved from the desktop to the data center. EMS dogfood before shipping the first time went on for about two years until the product finally shipped in 1996, long after I left my role as Technical Assistant.

Ultimately, BillG was entirely correct about the architecture required for email. Microsoft Exchange continued to struggle as a platform beyond email for decades. The lack of structured storage like SQL and programmable forms like those in Visual Basic made it difficult or even impossible to build additional applications. Microsoft would produce tools and languages for Exchange for the next 15 years, none of which gained critical mass or long-term adoption. On the other hand, Exchange dominated email without question—it arrived with global scale email at the right time and even transitioned that email capability to the cloud, forming the cloud portion of today’s Microsoft 365.

Where most executives in charge and accountable for results would have kept pushing knowing they were right (and he was), what Bill routinely did was make his point of view clear while giving room for teams to execute and deliver, when it was clearly the right thing to do. Cairo had a backup plan (actually, two) so it was the right call to keep pushing on innovation. EMS did not have a backup plan. If EMS did not become a product, then Lotus Notes had too much opportunity. The bet on NT Directory proved to be critical to the entire product line and server initiative. Bill had the foresight to believe and operate as though email would become the anchor of enterprise computing for knowledge work, and it certainly did.

On to 022. New Ideas and IQ for the Information Superhighway

Back to 019. BillG the Manager

As technical assistant I spent most of my time navigating our operating system strategy and progress during late-1992 to mid-1994. There were three main OS development projects going on at the time. Chicago was the code name of the successor to Windows 3.1 (shipped April 1992), rooted in the MS-DOS architecture and trying to build up from there. Windows NT building a portable, secure, and robust operating system from scratch aiming for the workstation and server market (version 3.5 to ship September 1994). These were both products under development unified by the Win32 API strategy announced at the professional developer conference. Cairo was a new project built on the core parts of NT but innovating (and inventing) in most every possible dimension. An entire book could be written about any one of these projects, but all were happening at once. This post is about what that was like. I don’t take this lightly when I say this, even after all these years many people I know still have emotional reactions to this period of time and the traumatic experiences of this project and how played out.

It wasn’t like Microsoft’s operating system strategy was ever simple, at least to me. Perhaps it was asking too much for a cleaner or more straight forward strategy to emerge with the move away from OS/2 and the early success of Windows 3.0, and now 3.1. Being complacent or content was not in Microsoft’s DNA—a bold vision for Windows was, however, and with that came even greater product complexity.

Microsoft had a simple external message of “Win32.” The problem was the product had not yet caught up to that message. Windows NT was just shipping its first version while the market was predicting NT would soon dominate the desktop. Microsoft was also anxious for that, first almost always talking about Windows NT after selling Windows 3.1. The “real” 32-bits, advanced networking. client-server developer strategy were all great selling points, but Windows NT was a new code base and lacked compatibility with huge numbers of applications and devices that represented the richness and key strategic value of the 16-bit Windows (and MS-DOS) ecosystem. Beyond that, Windows NT had the capability to run on non-Intel microprocessors which only fueled more punditry over the future of the PC. This left many believing the operating system market still seemed up for grabs and buying a PC remained a complex decision.

In the meantime, Microsoft had fallen woefully behind Apple Macintosh when it came to ease of use and the day-to-day effort required to keep a PC working—not behind in sales, but that was not what counted for currency with BillG. Microsoft had yet to release a simple files and folders experience that matched Macintosh and was still mired in the vestiges of MS-DOS, such as file names restricted to “8.3” (eight characters plus three for the file type). It is a cliché even today, but Macintosh just seemed to work, and PCs always seemed to be crashing, hanging, or flaking out, or just much more difficult to use. Just as PCs became common in schools and the workplace, “the dog ate my homework” was replaced with “my PC crashed and ate my work” or something like that.

Microsoft’s core Windows project for consumers was Chicago (eventually Windows 95). Chicago would bring the compatibility and ecosystem support enjoyed by Windows 3.1 together with the new Win32 API, while at the same time addressing ease of use shortcomings of Windows compared to Macintosh. Chicago had the goal of being a PC that was better than Macintosh plus bringing with it all the benefits of Windows that had cemented leadership in the market. The project was still early enough that most attention was on the just released and bolder Windows NT, primarily because so many believed that the 16-bit heritage of Chicago was a fragile legacy code base ill-suited for the modern 32-bit world. Microsoft’s own efforts around marketing NT only emphasized this point.

For any company that would be enough of a big bet, not for Microsoft or BillG though. Chicago was just one part of an all-out assault on the operating system market, one Microsoft already dominated: Chicago for consumers, Windows NT Workstation for professionals, Windows NT Server for the back office, along with numerous early-stage efforts on both living room and handheld computing devices going on in NathanM’s advanced technology group. These all came about as a direct reflection of BillG’s scalable Windows strategy best expressed by a slide from the Win32 Professional Developers Conference showing one Windows scaling from the smallest devices to the biggest computers—a slide that would in some form carry Microsoft’s vision for the remainder of Bill’s leadership.

Then there was Cairo. Whereas the major axis that defined everything along the scalable strategy was simply how much computer horsepower a device had, Cairo set out to redefine how people interacted with computers and how developers wrote programs. Cairo was to be a new paradigm from user-interface, to data storage, to networking computers together.

In an era where computers hardly worked and every developer at Microsoft was struggling to figure out how to write reliable code, ship that code, and meet a schedule, Cairo was by any measure an audacious bet, and that is probably an understatement.

Exactly where Cairo fit in and how, and even if that was possible, would occupy a huge amount of Bill’s time and thus my time. Given how I had just navigated the operating system strategy to do my little part to ship tools, I was fortunate to be well-versed in the technology and the teams. But where I found myself was in the awkward and impossible spot of having to help evaluate the practical realities of shipping for a CEO who wasn’t generally focused on those aspects of projects.

Landing on my desk early in 1993 was the first of many drafts of Cairo plans and documents. Cairo took the maturity of the NT product process—heavy on documentation and architectural planning—and amped it up. Like a well-oiled machine, the Cairo team was in short order producing reams of documents assembled into three-inch binders detailing all the initiatives of the product.  Whenever I would meet with people from Cairo, they would exude confidence in planning and their processes. The confidence took on such a level that people began to refer to Cairo unofficially as the updated version 4.0 of Windows NT.

At a college recruiting trip at Cornell, I remember spending an evening at the Statler Hotel bar with one member of the NT team and one member of the Cairo team (both fellow Cornell graduates) debating over schedules. Would Cairo be NT 4.0? Would NT 4 beat Chicago to market? Would Chicago be dead on arrival because of Cairo or its MS-DOS legacy? Or would “real” NT 4.0 beat Cairo to market?  This was engineer bravado at its best. It was also Microsoft’s operating system roadmap at its worst.

While any observer should have rightfully taken the abundance of documentation and confidence of the team as a positive sign, the lack of working code and ever-expanding product definition seemed to set off some minor alarms, especially with the Apps person in me. While the Cairo product had the appearance of the NT project in documentation, it seemed to lack the daily rigorous builds, ongoing performance and benchmarking, and quality and compatibility testing. There was a more insidious dynamic, and one that would prove a caution to many future products across the company but operating systems in particular.

Technology was moving very fast and new products were appearing across the industry at a rapid pace. As a brand-new product under development, it was tempting to look at every new development and wonder how it might be part of what is being built. This is especially true for an operating system which tends to lack any traditional product boundary like one might see in a word processor or spreadsheet. What is an operating system after all? Purists might say it is a kernel, but then what about the graphical components? Others would be quick to point out that networking or storage are not always considered part of an OS except at some basic level.

Cairo tended to take this as a challenge to incorporate more and more capabilities. New things that would come along would be quickly added to the list of potential features in the product. Worse, something that BillG might see conceptually related, like an application from a third party for searching across all the files on your hard disk, might become a competitive feature to Cairo. Or more commonly “Can’t Cairo just do this with a little extra work?” and then that little extra work was part of the revised product plans.

Along with this BillG reinforcing function of feature additions, there was the internal dynamic between the three major operating systems teams. Each team navigating the external competitive landscape, the ongoing BillG input, and a desire internally to be seen as both the leading OS and the one that will ship first and ultimately “win”. The idea of being first to market turns out to be a compelling way to measure success. This was especially interesting in a world of fluid or even non-deterministic ship dates where there were few absolute dates for shipping but a plethora of relative milestones. Who had a beta first? Who had a preview before that? Which product would get sent to OEMs for review before that? When was the next PDC and what code would be distributed there?

This led to a rise in one of the more classic Microspeak expressions, as we called them, or jargon as it is called elsewhere. In our little Seattle area bubble, disconnected from most of the world and not yet connected by the internet, Microsoft developed a vocabulary that to this day dominates discussions between alumni. Cookie licking is when one group would lay claim to innovate in an area by simply pre-emptively announcing (via slides in some deck at some meeting) ownership of an initiative. Like so many expressions this one seemed rooted in something long lost, but the basic idea is that teams wanted to keep features to themselves by declaration or fiat, almost always independent of a schedule, resources, design, or any concrete steps. Cairo by its own efforts and, frankly, by Bill doing his share of pushing features to them, licked a lot of cookies. Even calling Cairo NT 4.0 out of the gate was cookie licking as a high art form. The team was hardly alone. Other parts of the OS landscape would take the grand ideas of Cairo and lay claim to much more pedestrian implementations and state they would deliver the innovation sooner and more practically, with the caveat there were future plans (slides) to deliver the rest of the vision.

I was often caught in the middle of these debates. Who was going to deliver what and when were the questions of the day for nearly everything that came up in every discussion about Microsoft’s next operating system. The larger than life leaders of these projects intimidated me, at least early on. I decided on a very practical approach which was I just bought a lot of hardware and installed a lot of daily builds and let the code speak. It was what JeffH had taught me about shipping and it was the easiest way to prove or disprove what was going on. Windows NT was by this point very solid and building out on the promises of the workstation and data center, with many developers running it as their primary work computers. Chicago was just starting to deliver builds and you could experience significant changes in the user interface – files, folders, long file names, and earliest form of what would become the Start menu. Chicago followed a series of scheduled milestones M1, M2, M3, and then M4 which was the first build that made it to the outside world and was also usable on a daily basis for the incredibly brave (like me). I remember showing it to BillG when he commented on how “Chicago seems to be marching along like a British highway system, M1, M2, M3, M4”.  I’m not sure why that comment stuck with me. Maybe he thought it was super funny.

Cairo was a different story.

Cairo was announced and demonstrated at the December 1993 PDC, but no code was provided. With that came almost impossible to describe internal tensions and angst. While there was always tension between OS/2 and Windows, the skunkworks nature of Windows and the outside forces of IBM proved ample outlets for frustration. With Cairo, everything going on internally was self-inflicted. At every level of the organization and across the product teams, the constant back-and-forth between Chicago, Cairo, and the next NT (NT did not lack for codenames at this point, going by the moniker Daytona, a nod to the efforts to improve speed and the affinity for fast cars among the leaders of the team). Pick any two and there was an ongoing knock-down, drag out battle over schedules, performance, architecture, or user-interface. The Apps group, third party software developers, and the hardware ecosystem were all caught in the middle.

Chicago was a big team. NT was an even bigger team. Cairo quickly grew to be even larger. For those looking for reasons to see the potential for failure, ever-increasing team size was a good proxy. Frankly, the divergence of documentation and slides from the daily builds was an even bigger indicator. That was the factor I focused on. I often had to pull Bill back from reading about what was being developed to see what was actually in code and at what pace that was changing.

The only saving grace was the steadfast and relentless evangelism of the Windows API and the Win32 vision. That held the company together as a practical matter for the time and the next decade.

In my own small way, I lived through a variant of this vicariously through my lunchroom friends working on Word years earlier. After the debacle that was Windows Word 1.0 (if you can call winning a debacle), a project was started to build a new more robust and refined, a modern, code base for word processing. The Pyramid project went on for a couple of years before the realization that the existing code could be made to work fine and new code brought with it new problems. It was quietly and quickly shelved. The tension and confusion were real and ongoing.

IBM was famous for having competing projects and many in technology thought companies should build new products with multiple efforts, in some sort of coding Darwinism. Maybe it had worked before, but the human and customer costs seem out of proportion. It is one of those business school ideas that looks great on paper. I probably did not need more proof that I was living through a case study in the making.

If meetings and my TA efforts with Chicago were focused on the relatively narrow or mundane topics of performance and the number of bits in use in the kernel (should Chicago be 16 or 32-bits and in which subsystems was a major ongoing point of consternation), Cairo was expansive. Cairo, like Chicago, had a new shell (Microsoft’s favorite word for the user interface for launching programs and managing files) and a new file system, but the innovations were to be radically different. Where Chicago aimed to commercialize broadly the graphical operating system, a concept understood by most, the goal of Cairo was to commercialize two of the biggest buzzwords in computing: object-oriented and distributed networking.

Cairo aimed to advance personal computing with dramatic changes in how we thought of files—rather than single files and folders, Cairo intended for files to have the capabilities of a database. Everything on your PC was to be stored in a database to easily search, find, and show relationships between items: files, email, contacts, photos, documents and more. Advancing storage was a long arc of innovation Bill favored.

The graphical interface for manipulating these objects had elements of traditional files and folders but enabled more operations. A folder, for example, might not have anything in it until a user indicated the folder should contain “all objects from 1992.” The folder would be filled as though everything matching that description had been copied to that folder, but it did so without making copies of the files. It seemed slick at the time.

The object-oriented nature of Cairo was not just dreamed up but paralleled several efforts across the industry (some even going as far back as Xerox PARC research work). Specifically, Apple was building a system called OpenDoc that promised to bring object-oriented files to Macintosh. It would never make it to market though. IBM had a project known as system object model (SOM), which aimed to bring objects to every size IBM computer, from PCs to mainframes. It too would fail to materialize. All this object-oriented stuff was developing a pattern.

Object-oriented storage would have been impressive if it all happened on a single PC. The true magic of the promise of Cairo was that everything that took place on one PC could work across networked PCs. The notion of a network was still new, and the first web browser was just being released while we were busy building what some might call a web-like system. JimAll (leading Cairo) was a pioneer in distributed computing, inventing a system called Clouds for his PhD dissertation.

The Windows NT team was also steeped in distributed computing, having seen the Digital Equipment VMS operating system gain distributed capabilities a few years earlier. Similarly, the distributed capabilities of Sun computers running Unix and NeXT from Steve Jobs, were gaining popularity on Wall Street and in academia.

The biggest impact Cairo had on Microsoft’s technology direction was in the adoption of a technology called component object model (COM). COM started in part of my original team, Apps Tools, as a way for productivity applications to talk to each other, the earliest work invented by the PowerPoint team to make it easy for PowerPoint to include charts from Excel or pictures from other apps. The Cairo architecture used COM for every aspect of the system—it was object-oriented at every layer of the system. In fairness, I am intentionally glossing over a good deal of complex technology history about COM and technologies included under this umbrella including Object Linking and Embedding (OLE), Automation, and DocFiles.

This seemed like a good bet, but then as the system started to mature it became clear that being so object-oriented had downsides when it came to performance and even managing all the code in the system. As it turned out, those building operating systems were equally susceptible to oopaholism.

At one point, things became so fragile that JimAll asked for a meeting with BillG to discuss the future use of COM, questioning even moving forward to perhaps reset and find a more robust approach.

I quickly pulled together all the background and made a list of pros and cons. My own history on C++ came in handy as we had gone through our own education and reform as oopaholics. I asked my old manager, ScottRa, to attend this small meeting to detail his experience with COM and objects. I was definitely on the side of abandoning COM, having seen the cost of being excessively object-oriented.

The meeting took place during the Software Development Conference when we were launching Visual C++. I booked a flight for a day trip, something not usually done, and arrived at the meeting just in time (Bill questioned my judgement of a one-day turnaround). The meeting was a first and one of the few times I saw a clear choice and decision being made. I mean this in a good way because most often meetings that claim to decide things, really don’t. Bill was well aware of that and used meetings to arrive at consensus rather than force choices that would need to be revisited at some later date.

There was a good discussion for quite a long meeting, and ultimately JimAll decided to stick with COM, but there was a commitment to be sure to use it at higher levels of the system and to avoid oopaholism. In other words, the OS itself would limit using COM and objects while pushing the use of that technology to developers. This seemed practical but the “do as we say, not as we do” aspect of this proved to be problematic for a long time.

COM went on to become an architectural anchor, like on a boat, for nearly everything else Microsoft did for decades. I often think about this particular meeting—the stakes seemed so high, though had an alternate decision been made, things may not have ended up all that differently. COM was an anchor, that was true, but the value was so much higher level and in so many other parts of the system. COM had all the architecture, complexity, and proprietary elements that the company seemed to be craving at the time.

The number of companies with projects potentially competing with Cairo continued to increase, which only caused the scope of Cairo to broaden. At the same time, the value that Cairo provided to other teams made the effort worthwhile—pushing the Chicago shell to have a leading-edge design, encouraging the Database team to think more about storing different types of data, and creating the precursors to networking advances that drove the client-server computing revolution. Some would say the influence of Cairo is less reality and more putting a shine on the ultimate failure of the project. Perhaps that was the case at the time. Does it matter?

Ultimately, the human toll of Cairo was high in the sense that so many people spent so much time early in career working on a project that not only didn’t ship but was viewed as squandering resources, at best, and misguided at worst. It was a bit of a black eye for Microsoft among the press and analysts who believed Microsoft would deliver on the idea of object-oriented the way that NeXT had done but at scale. The magnitude of the project would leave many people with Cairo war stories for years to come. I wish I could say that the lessons learned would prevent another experience like this from happening, but that isn’t the case as we shall see.

The success Microsoft was having with Windows and the failure of competitors to do better in the market created an environment where even mistakes as significant as this seemed not to slow things down. Importantly, and I think this is a good thing, it did not cause Microsoft to back off audacious goals and big visions for technology. It is easy to see a world where a setback like this would force Microsoft to reconsider big bets and to aim for less lofty goals. I am glad that did not happen, as difficult as the next years would be.

The entire time I worked to amplify Bill’s efforts at steering Cairo, I felt caught in the middle between innovation and shipping, not that those were mutually exclusive. To the contrary, I naturally tilted toward shipping and believing that was innovation. The dichotomy between shipping groups and non-shipping groups was too often portrayed as a dichotomy between execution or innovation. That proved to be the root of the feeling that every group was screwed up—the innovative groups weren’t shipping enough, and the shipping groups weren’t innovating enough. Sometimes I felt that groups that were shipping were almost never given the benefit of the innovation moniker, and groups that were innovating seemed to be unburdened by shipping. Perhaps this was the Microsoft way of having competing groups.  

On to 021. Expanding Breadth versus Coherency: The EMS Project

The breadth of the Microsoft product line and the rapid turnover of core technologies all but precluded BillG from micro-managing the company in spite of the perceptions and lore around that topic. In less than 10 years the technology base of the business changed from the 8-bit BASIC era to the 16-bit MS-DOS era and to now the tail end of the 16-bit Windows era, on the verge of the Win32 decade. How did Bill manage this — where and how did he engage? This post introduces the topic and along with the next several posts we will explore some specific projects.

Please feel free to share this and subscribers, please join in the discussion.

Back to 018. Microsoft’s Two Bountiful Gardens

At 38, having grown Microsoft as CEO from the start, Bill was leading Microsoft at a global scale that in 1993 was comparable to an industrial-era CEO. Even the legendary Thomas Watson Jr., son of the IBM founder, did not lead IBM until his 40s. Microsoft could never have scaled the way it did had BillG managed via a centralized hub-and-spoke system, with everything bottlenecked through him. In many ways, this was BillG’s product leadership gift to Microsoft—a deeply empowered organization that also had deep product conversations at the top and across the whole organization.

This video from the early 1980’s is a great introduction to the breadth of Microsoft’s product offerings, even at a very early stage of the company. It also features some vintage BillG voiceover and early sales executive Vern Raburn. (Source: Microsoft videotape)

Bill honed a set of undocumented principles that defined interactions with product groups. The times of legendary BillG reviews characterized by hardcore challenges and even insults had become, mostly, a thing of the past excepting the occasional sentimental outburst. More generally, they were a collective memory of hyper-growth moments any start-up experiences, only before the modern era when such stories were more commonly understood.

Much later in 2006, when BillG announced his intent to transition from full time Microsoft and part time philanthropy to full time philanthropy, many reporters surprised him by asking how Microsoft would continue without his coordination of technical strategy and oversight. But even in the early ’90s, at the height of the deepest and most challenging technology strategy questions, he never devoted the bulk of his time to micromanaging product development. He spent a good deal of time engaged with products, but there were far too many at too many stages of development to micro-manage them. In many ways this was the opposite of the approach Steve Jobs took, even if both were known for their own forms of challenging interactions. The most obvious contrast between the two was the breadth of the product line and the different market touchpoints.

Having grown up through Development Tools and Languages, I was familiar with Microsoft’s product line, but only as TA did it become clear how comparatively broad Microsoft had so quickly become. The software world was thought of through a lens of major categories: operating systems, tools and languages, networking, and applications, roughly mirroring Microsoft’s org chart. The latter was thought of as word processing, spreadsheets, graphics, databases, as well as assorted smaller categories. It was easy to identify leaders in each of those areas—names that were tip of the tongue at the time and most of which are no longer in the PC software space (IBM, Borland, Novell, WordPerfect, Lotus, Aldus, Ashton Tate, and many more). The ah-ha moment in the early 1990s was the realization that no company on that list was competing in more than one category. Microsoft was hardly winning in every category. In fact, in most categories it was new entry, a distant second, or even third place, but the company was in every space. Bill was committed and patient. Microsoft was relentless. And Microsoft was focused on Windows.

BillG had fostered Microsoft with a grand vision to compete in every category of PC software, from some of the earliest days. With rare exceptions, no other company set out to do that. BillG led a deep technology strategy. It started with the operating system, supported by tools and languages, and then using those to build applications. This seemed simple enough. In fact, it is what IBM built for mainframes and DEC built for minicomputers.

There was a crucial difference. Microsoft did not build hardware and was not vertically integrated to reduce competition. Microsoft built an operating system on an openly architected PC (the same Intel-based architecture that came to power both Macintosh and Linux years later) and published APIs so that anyone could build tools and applications for the operating system—an open hardware platform and open operating system APIs. This approach simply addressed all the early challenges Microsoft itself faced trying to figure out how to build winning applications—it was so busy dealing with dozens of proprietary computing platforms, each with their own tools and APIs just different enough to make things difficult, but not so different as to be valuable. Bill saw the value in software and in openness at key points in the overall architecture. At the formation of the company, he and PaulA saw the immense and expansive value of software and, essentially, the liability that being in the hardware business carried. Building Microsoft’s software-only business on an open hardware platform where many players competed to drive prices down while maintaining compatibility with the operating system was one of the all-time great strategy choices. The idea of building hardware seemed like a sucker’s bet, with low margins, manufacturing, and inventory—the baggage of the physical world. While Microsoft would dabble in peripherals or hardware that could bootstrap new PC scenarios, building whole computers was a headache better left to others.

Expanding the impact of that breadth software strategy was BillG’s day-to-day operating model, not micromanaging the specifics of any given project. I am painting this with a broad brush, intentionally so. Part of the difference between the then dominant cultures of Systems and Apps was that during the MikeMap era (and arguably during the earlier JeffH era), Apps weaned itself from Bill’s intense and constant scrutiny whereas the Systems culture more clearly embraced that dynamic. That was largely true until PaulMa took a more hands-off (or walled-off) approach to the nurturing of the NT project.

In his May 1991 email, “Challenges and Strategy,” BillG set the company on the Windows strategy, clarifying the foundations for every product and group, solidifying what had been complex platform choices every team faced. Regardless of whether Bill was a savant when it came to the technical details of projects or he simply remembered everything each group sent or told him, he operated the company at a higher level of abstraction than reporters believed to be the case in 2008 when he ultimately reduced his full-time commitment to Microsoft.

I had a glimpse of this when our AFX team had our pivotal review. Later as TA I was there to connect the dots and amplify the Windows strategy. By and large the company was still wrapping itself around the details of what it really meant to embrace Windows, exclusively. That, and coping with the myriad of choices and decisions that come from the tension between aligning with a Windows strategy and having some control over your own destiny as a product. Which version of Windows? When is that shipping? Will the APIs our product needs be in Windows? Will those APIs work on older versions of Windows? What about Windows NT? On, which microprocessors? What about the other parts of Microsoft? The questions were endless. This was truly big company stuff—the strategy at a high level is one thing, but execution across a $600M (1994) research and development budget was another. The fascinating thing was how products so quickly scaled beyond what Bill personally experienced as a programmer, both in size and technology specifics. This was to be expected—by any measure the company was huge—but people and Bill himself still expected to interact on product details as though he was a member of the product team. I often found myself looking for ways to help Bill engage at that level, even if just for show.

In addition to the Windows strategy, with the late 1993 launch of Office 4, Microsoft also declared 1994 “Year of Office”. It was the biggest launch for Apps and represented a major pivot of the organization to the opportunity of selling a suite of products. This too was in the earliest days of a strategy, one that I would end up spending significant time on as TA and then later as a member of the team.

Just because Bill operated at a level of abstraction across products groups did not preclude product groups from engaging on what might seem like relatively small, non-technical matters. One of the more entertaining meetings I attended was preparing for the launch of Office 4, which was a worldwide event complete with a reporter given permission to shadow the team. A key differentiator would be how the user would experience “intelligence” in the product, so that it understood what was intended and how to achieve it in the new Office software. The development team built a series of features along the lines of what was termed “basic use” such as AutoCorrect in Word, AutoFilter in Excel tables, and a host of Wizards (guided step-by-step flows such as for creating charts), and more. To bring them together and actually communicate with the market and on retail packaging, the marketing team came up with an umbrella term. Pete Higgins (PeteH) came over to brief BillG on that choice in a small meeting in Bill’s office.

PeteH was by then the spiritual leader of the business side of Apps. He rose through the ranks of Excel and was clearly MikeMap’s lead executive. Pete was the kind of calm and in control leader that everyone enjoyed working for—he was at once clearly the boss, but also a member of the team. Pete was a native of the Seattle area, high school football star, and Stanford graduate. He was a new generation of Microsoft product executive, coming from the business and not the coding side. For me in my TA role, Pete was one of my biggest supporters and mentors and made connecting with Apps super easy.

Sitting at the little couch under the Intel chip poster, after going through the details of the launch, Pete said the proverbial “there’s one more thing.” Bill rocking in his chair shook his head, given that the meeting was mostly an uneventful recap of the upcoming press tour. Pete went on to explain the problem of communicating all the features and how Microsoft needed a term to market and describe them. Pete was dancing around this because he knew well enough that Bill was not a fan of “marketing”.  Ever so delicately Pete said, “this is your chance…we want to go with this term but if you don’t like it…”

Pete then said, “IntelliSense. Microsoft Office introduces IntelliSense.”

Bill’s reply, “Intelli…what?”

Pete again tried to position the positioning, his instinct about resistance proving correct. “It is IntelliSense…it means that Office has built-in intelligence, and it understands what you need and how to do it.”

Bill still not warming up, went full pedantic, “what intelligence…is there a Prolog rules engine, a neural network, ….” He was also making the scrunched up surprised look that he does, which turns out (once you realize it) to also be a bit sarcastic. It meant he was warming up.

A few more times back and forth, and Pete just made Bill say IntelliSense in a sentence one more time, which he did with kind of a devilish smirk.

Done.

Looking back this all seems absurd. Consternation over a single phrase. Literally seeking approval to use it from the CEO of a billion-dollar company. All on the heels of what was no doubt months of preparation, including getting SteveB’s approval which was actually critical. Finally, the theater that Pete would pull the plug a few weeks before the tour. In some ways this was the Apps way of bringing decisions to Bill—it wasn’t really a choice and it had been broadly vetted and was buttoned-up. Any debate would probably be theater more than anything.

On average, there was one product-focused meeting on most days. Most teams saw Bill once or twice a year. NathanM saw Bill most every day or at least in most every technology context, present day or far out there. Most executives, like PaulMa, PeteH (leading Apps), and Susan Boeschen (SusanB leading consumer), saw Bill in product review contexts several times a month because each had many ongoing projects or, in the case of the big projects (like operating systems), many large components. Everyone was in constant contact over email. Bill was always forwarding emails across the company, adding relevant people from all levels of the organization to the CC line, and never backed off a good reply-all opportunity. Phone or in-person 1:1s were not the typical way of interacting across the product executive team. For the most part, work happened in groups or at least with an audience, with outcomes and flare-ups quickly disseminated by email. I found myself constantly on the move walking around campus from one building to the next to meet people in person, rarely was I in my office (a pattern that continued my entire career).  

I was often asked to meet with teams before they met with Bill. They hoped for insight into how BillG might think about choices and decisions or even the presentation overall. I often disappointed teams in these pre-meetings since I was hardly a stand-in for Bill, and I was hardcore about leaving any such impression. Pre-meetings gave me a chance to better understand the issues the team was struggling with and to make sure those were brought forward in an objective and transparent manner. The fastest path to failure was to structure a conversation so Bill discovered an issue rather than having it revealed to him. To be fair, an equally fast path to failure was a first slide listing a slew of problems and issues in the hopes of inoculating the remainder of the meeting. In that case, I would caution teams that they were exposing themselves to the inevitable “How can this be so difficult?” comments. Getting this balance right was the essence of leading an effective meeting.

For most meetings, I wrote a summary meeting preview. Even though Bill said he did not want this, I could not help myself. While he was always effective, I felt that a little bit of specifics could go a long way in making the meeting more effective and less random. I could tell he had read my mail if he raised a point verbatim from my note, and frequently he would kick off the meeting doing so, never crediting me of course. In these, and all mails talking about other teams, I always tried to separate the facts of the meeting, the team’s analysis, and my own opinion. Bill was transparent with email and thought little of forwarding an entire thread. I learned the ramifications of that the hard way.

As an example of where I failed to follow my own rules about fact versus opinion, I totally offended Jim Allchin (JimAll), leading the Cairo project, on the role of a specific technology in distributed programming. Not only did Jim inform me that my opinions were wrong, but also that I stepped all over his own PhD dissertation as a leading expert. In hindsight, this was terrifying—Jim’s reply was brutal—but it proved a good early learning experience, so to speak.

While the product line was already broad, the expansion to entirely new areas was unstoppable. On most any product area, we were forming an opinion, beginning work, or already in the market. There was not a booth at a tradeshow, a focused conference, or a major company looking to partner that Microsoft was not already connected to or connecting with in some way. While Microsoft was in the earliest days of achieving a PC in every home (about 25 percent of US households in 1993) and on every desktop (about half of US workers in 1993), every day in this job was either furthering that or expanding beyond homes and desktops from data centers to handhelds to airplanes (the first in-flight PC-based system was an early partnership between Microsoft and an airline, including certification for Windows Server).

Product meetings had no set format or structure and usually reflected the culture of the organization. This might be a surprise to some as many CEOs (or perhaps their staff!) might have imposed some more rigor on meetings. Microsoft had two bountiful gardens, but there were micro-cultures throughout out the company. While one group did slick and well-rehearsed presentations, another might present research-heavy deep dives. Bill often pushed a team outside its comfort zone, deliberately pushing the team to discuss places they were less prepared, or even less interested. It was a technique he employed. He once said to me, “Why spend all the time with the Windows team talking about architecture, if that was their predisposition anyway?” This was also a strategy to level the playing field—talking about architecture to Windows or ease of use to Excel was too lopsided and Bill was disadvantaged.  

The reality of BillG Reviews never lived up to lore.

Most meetings progressed without incident—meaning without yelling. Sometimes, though, there were comments such as “That was the stupidest thing I ever heard” or “That is brain-dead.” The worst was “That’s trivial . . . let me show you.” Those were all the clichés that teams anticipated but then wore as a badge of honor. They happened with far less frequency compared to how much they were talked about. Even over the short period of time I worked as TA, Bill became more intentional in his use of meeting dynamics. Still, the first seconds of a meeting remained a bit of a mood thermometer, pity those for whom it was clearly a bad day.

When meetings ended up “bad” it was always because the team was poorly prepared, or they came to talk about the project in a way that diverged from expectations. There were typical capital offenses in the meeting, such as failing to understand a product strategy of competitors or downplaying a competitor’s potential. Worst was coming across as though a product was making mostly tactical decisions driven by schedule or failing to understand the architecture of the product relative to the evolving platform and related teams across Microsoft. PivotTables were just making their way across most teams, so many were still making the common errors of using static charts and graphs that always seemed to have the data oriented or filtered in the least useful way. Those moments always held potential for a lively discussion.

Part of my role was to reduce the potential for such liveliness ahead of time. I tried to alert teams about potential issues without acting as a surrogate for Bill, and to make sure meetings did not save the difficult or bad news for the end. I was also there to throw myself on the grenade, so to speak, and get meetings back on track by helping the team through a tough moment—usually by restating or interpreting what they were saying or by redirecting the topic at hand to a follow-up discussion.

By far the biggest strategic error one could make was knowingly duplicating code outside core expertise, and then compounding that by attempting to explain why in this particular case it is justified. Microsoft Publisher was a new product in the desktop publishing category. It was being built by the Consumer Division under the leadership of Melinda French (MelindaF). The product aimed for the small business and non-professional market, compared to the incumbent Aldus PageMaker. It differentiated itself with ease-of-use features, pioneering Wizards and other user interface innovations. But it also produced printed pages that looked a lot like what one should be able to create with Microsoft Word. This overlap was the source of endless consternation—why can’t they share code, why can’t Word do all these features, and then ultimately why does Publisher even exist. Yet, customers loved it. At one point, a meeting went down a rabbit hole over bullets and numbering and how Publisher was basically writing all the same code Word was and wasting everyone’s resources. There was little actionable in this kind of rant, but it did establish the norm of being called out for redundancy and the need to be prepared to cope with the feedback.

Bill maintained a deep commitment to evaluating a portfolio of efforts, and even within a single product he believed in the portfolio approach of features—not every product nor every feature was a winner or a breakthrough, but on the whole something needed to be working. As much as Bill might give a group a difficult time (as happened with Visual C++), he knew there was always more to the product and more products to the company. It was not just that Bill was building a product portfolio for Microsoft, he was managing the teams as a portfolio of efforts. This portfolio approach created a resiliency in the company—resilient to the unpredictable nature of technology bets and to the ability of the people on the team to execute. Not everything went as planned nor did every planned bet ultimately make sense.

Whether deliberate or not, BillG had three axes that created a constant state of balance, of push and pull, across the hundred teams creating software. Bill’s approach of constantly balancing the tension between innovation and shipping, expanding the portfolio while maintaining coherency, and the injection of new ideas while also executing on existing work proved to be the most interesting “management” lesson. The next three sections are examples of each of these dimensions.

On to 020. Innovation versus Shipping: The Cairo Project