029. Telling the Untold Story

A more interesting aspect of being in a staff role is how your perspective changes from day-to-day execution to strategic milestones. From this perspective, one doesn’t see the daily progress as much as the experience of what the starting point was and then results. There are meetings and demos, and (tons of) daily builds in the middle (my favorite), but the experience lacks the context of daily trade-offs or even the realities of product development. It is very easy from a staff role to assume people don’t get it or they are messing up, but it just isn’t the role or even a valid perspective. This would be a valuable lesson I would learn in this job that I was not expecting.

Back to 028. Pivotal Offsite

The clock was ticking, and to get things done for Chicago meant starting immediately. Chicago, originally planned for early 1994 or maybe 1993 depending on who you ask, was not yet in beta and so practically speaking was not going to finish in 1994 given the time required for broad beta testing (recalling my previous Cornell recruiting trip and the debate over whether Cairo would ship before “Windows 4” aka Chicago later in 1993).

Evangelizing tactical work items for the internet strategy and making sure they landed with owners was my job as TA. With regards to the “Internet mania”, our mantra as per BillG was two-tiered: embrace and extend.

Much like killer app, the phrase embrace and extend proved to be far more loaded an expression than intended. Computing evolved by companies constantly finding ways to uniquely extend existing software and hardware, elements viewed as commodities, while at the same time always bowing to the existing investments of customers by claiming an embrace of any standards or winners. That was the view of how value was created—everyone built on all that came before. That was how everything worked. In a sense, each new product somehow related to the product it would supersede while extending it in uniquely valuable ways.

What had changed was the open-source movement that viewed everything as embrace with no advantage bestowed to any party, with any extensions going back to the community. As it would turn out, embrace and extend is precisely how nearly every open-source innovation was commercialized, particularly as software moved to the data center. Not everyone believes that is good, but it is what happened. In 1994, embrace and extend was synonymous with evil. Admittedly, it didn’t help that the phrase was sometimes attributed to Microsoft as “embrace, extend, and extinguish.”

With specific action items outlined, for the next couple of months I made sure the company was embracing the key protocols I had seen at Cornell (and that our brave corporate customers were beginning to demand): TCP/IP, email over SMTP, HTML for online documents, NNTP for discussions and bulletin boards, HTTP and Gopher on the server, and IRC for chat.

In doing so, I found myself in the role of shuttle diplomat or “glue” as we said looping around the cluster of single-X buildings, the location of the Chicago team, and the next version of Windows NT under development, Daytona, and over in building 16 where Peter Pathe (PPathe), the general manager of the Word team, sat. Many days I found myself almost in a constant swirl running between buildings in the misty drizzle of Redmond.

My agenda was to help identify issues and bring teams together to arrive at the common goals outlined at the offsite. I was to help, not do. It is a confusing a difficult spot to be in, especially as a self-described zealot, and particularly as someone with no responsibility for a product schedule.

Chicago was on a mission, a new mission to embrace the WWW. The team quickly came to its own point of view and strategy, which included the get on the internet capabilities, as well as coming up with a viewer and browser strategy. During the offsite the Chicago team affirmed this point of view, but the commitment was for after the initial Chicago release. The realities of the Chicago schedule meant that work that did not impact the product directly had a chance of being delivered simultaneously to customers because of the way OEMs ship new PCs, known as a service release in the OEM process—taking advantage of the ability to add features to Windows on new PCs even after the retail boxes of Windows were manufactured for upgrade customers who would later download those same changes or purchase the same-day add-on for Windows 95 called “Plus!” which in addition to those same internet capabilities including Internet Explorer 1.0, included games, screen savers, and other extras. While much would be made by regulators of these small changes in dates and what the “final product” was, this is what agility looked like in the age of massive software projects, a multi-month manufacturing channel required by ecosystem partners, and a schedule that was always a bit fluid until it wasn’t.

This became the plan of record led by a longtime engineer, Ben Slivka (BenS). In the short term, the strategy was to make sure developers around the world understood the underlying technologies provided by Chicago that made it easier to build viewers and browsers and to evangelize those—if Chicago could not have its own then at least it should have the widest range of choices from third parties. This was a tried-and-true strategy Microsoft had always followed—the best of first and most of third parties. The same type of work, meaning a combination of built-in capabilities as well as evangelizing third party capabilities, was going on with all sorts of extensions to the operating system from networking to USB support to Wi-Fi, but none of those would be contentious down the road.

Originally BenS was planning the features of the follow-on release, but seeing the situation of enormous growth in the internet, the already strong base infrastructure in Chicago, and the Chicago schedule, he devised a plan that involved licensing browser code as a way to kickstart the efforts for higher level viewers, especially WWW. In a series of negotiations (and after looking at some alternatives), the Chicago team ended up licensing the code to build Internet Explorer from Spyglass. In parallel, others looked at whether to expand on offerings for FTP, Gopher, or any number of other viewers/protocols.

With every passing day, it became abundantly clear that the WWW was the only viewer or internet technology that really mattered. The pace of adoption and growth of WWW servers compared to Gopher servers made this obvious.

Coincidently, and unknown to Windows, the Word team had established a contractual relationship with a company called BookLink, which also made a browser. I had seen BookLink at the Spring COMDEX show and it seemed like a reasonable commercial implementation of the current WWW (HTML viewing and HTTP protocol), and I noted such in my trip report. I pointed the Chicago and Word teams toward it. I knew Word needed HTTP protocol work, as Word was busy building HTML authoring (described at the offsite). Part of that required the ability to traverse URLs and fetch the WWW page. To do that, Word licensed the BookLink code, which bugged the Chicago team that thought Word was trying to build a browser (versus just read in an HTML file to edit). There was some combination of cookie licking and “stay in your lane” going in both directions, but also the technical reality that to edit WWW pages (HTML) required the ability to use those protocols, and the Word team had no intention or desire to start from scratch.

Roughly in parallel, the Chicago team was in negotiations with BookLink for their entire browser, but those talks ended when BookLink was acquired by AOL, among other reasons. At least in part my fault, there was a bit of the right hand not knowing what the left hand was doing across the Windows–Apps boundary, which was not uncommon (much to the chagrin of people who believed the relationship was much more orchestrated and sinister). The fact that both teams were moving aggressively was good, though I have to think the BookLink people got a kick out of our org chart.

The tension between Apps and Platforms was not rooted in people or organization like far too many believed. It was rooted in the approach to building products—there was a reason MikeMap’s two gardens description reflected an operational reality. Building a platform meant focusing efforts on creating opportunities for developers by offering abstractions in the form of APIs, application programming interfaces. APIs provide services that programmers use to the build applications. For example, the Windows browsers that were being built did not write their TCP/IP code from scratch. Rather, they used the Windows APIs called WinSock that provided a higher level of abstraction, so it was easier to build the browser. Windows did not, however, have any reusable code for rendering HTML as an example. That was something for later. Success for Windows might look like having many FTP and Gopher applications built using the Windows platform, something JAllard, along with the Chicago team,  and I spoke about quite a bit.

If the Platforms approach could be thought of as bottom-up technology problem solving, then the Apps approach was top-down starting with the user problem. Apps looked at a problem and wrote the code to solve the problem for the end-user, rather than a developer. There was less flexibility in how much to accomplish since, to an end-user, an app either solved the problem or it didn’t. Developers on a platform always had the option of building more code themselves or finding other code to use that helps. On the other hand, app writers did not have to worry about what other programmers thought about how their app is built or structured since that remained relatively opaque. Success for an app was having the most users, and that’s it. A platform saw success as having the most apps in a given category, even if some were not so great or all the apps did the same thing, so long as there were unique apps for the platform. I’m writing this as an either-or, when in practice it is a spectrum. At least it was viewed that way at times, which made any cross-group efforts that much more challenging. Knowing exactly when an app was an application and when a platform was a platform, and not the other, was often only determined in the context of a specific feature at a moment in time. That indeed is the true tension.

It would have been nice if Platforms and Apps teams were as cleanly separate as their description. In practice each took on characteristics of the other. Platforms built apps all the time, such as the Windows Explorer, Reversi, or Write—parts of Windows that to end-users felt like whole solutions and tools, even if under the hood these had APIs for developers. Apps routinely provided platform APIs for developers as well. Many developers used Excel as a platform to build custom financial or data access software, for example.

App creators were developers and they made choices all the time about using APIs from the platform or building their own simpler or faster solutions because they only solved specific problems. Platform developers routinely provide more than APIs, building out the first steps of an experience. When a new, exciting area comes along, the natural tendency for everyone is to adopt the technology, from their perspective. It was at these times of newness that the more standard traits of Apps and Platforms got tossed aside in the zeal to be first adopters.

The introduction of the WWW browser was such a time.

From all outward appearances, WWW browsers were apps. They were installed on Windows. They came from third parties. There were a bunch of end-user features. Even something simple, like printing a web page, seemed like a feature better done on the Apps team, since almost nothing in the platform supported printing. They were even a “category” in that there were several competing apps one could choose from, like word processors or spreadsheets. Most of all, if you wanted one you just went to an FTP site and downloaded that thing. A browser was clearly a thing, an app even.

That’s why many in the Apps group thought it was a good idea for an Apps team to build a browser. Apps were great at working from the end-user down, even if there were some APIs for developers.

The Systems team saw things as a platform. They saw the browser as a platform that Apps would target. The address bar in the browser could be thought of as almost a Start menu. The URLs were like the names of apps. The fact that browsers ran across many platforms and were the same was the kind of thing that platform creators don’t like to see—they want apps to be unique on their platform. The real problem was that the platform was woefully incomplete compared to Windows. They saw parts of the browser from navigating a URL to rendering HTML as reusable components that could potentially be used by others to build other browsers (the way developers built more games using graphics APIs in Windows) or even entirely different apps with browsers built into the app. The browser just needed more APIs.

That’s why many in the Systems group thought it best for a Systems team to build the browser. Systems were great at working from the APIs up, even if there was some user interface for end-users.

While those, like me, who favored the Apps approach thought this was a good discussion, it wasn’t much of one at all. There was little doubt that Microsoft’s browser was going to be a Windows offering, a platform and an app. Microsoft was a Windows company, and Windows was still in the earliest days of trying to win, as strange as that sounds. The superiority of Macintosh for the internet was not lost on anyone, and competing servers from Sun and Oracle were dominating a Windows Server that had not yet made a market impact.

The responsibility of authoring HTML falling to Apps with viewing owned by a new browser in Windows might have made sense to some. It definitely made sense early on when there was little hint that browsers would have editing. Things could not be so clean, however, because of a very strategic rich-content creation tool being developed. Blackbird for the new online service Marvel was being talked about broadly and externally with partners, especially print newspaper and magazine publishers. Blackbird enabled such partners to maintain the fidelity of their physical products online and even enhance the experience. At least that was the strategy. Blackbird cast a long shadow because of the early concerns from some of the country’s largest and most established media companies. Concerns were everywhere. Would Microsoft become a dominant media company? Would Blackbird prove to be a monopoly printing press? How would publishers make money on the WWW and was Microsoft going to be a gatekeeper? This might sound like crazy talk, but this is exactly what I heard at a time when no one questioned Microsoft’s dominance or ability to execute. For many industry insiders, Blackbird was some kind of shorthand for Microsoft’s future expansion into owning all content creation. It was more than crazy talk, it was just crazy.

It is entirely possible for a company to have exactly the right vision for a technology future but, by virtue of market position in a totally different market, be exactly the wrong company at the wrong time to try to realize that vision. This burden or curse of market leaders is a history that repeats. We were experiencing this for the first time.

Apps focused on being viewers at the “edge” of the WWW. For example, a professor with a course web page might post the lecture slides as a PowerPoint file on the page, which you might get to by clicking from the university home page to a department to current courses to a specific course page. This was all incredibly novel at the time when you consider the alternative was to pay cash to a student notetaking service for the notes for a lecture you missed.

Such a strategy left little room for Apps to participate in the WWW. This might have been perfectly fine if the WWW ended up being primarily about navigating to “files” the way Gopher had. The attraction of the WWW experience was being in a browser (an app!) and never leaving. Thus, Apps saw HTML as potentially the way for productivity documents to be rendered simply so they could be seen in the browser with the least amount of friction, almost like a new way to print. The idea that anyone could create web pages by simply using the tools they were already using seemed cool enough—for the time being creating web pages was akin to programming so this seemed like progress.

The Apps team was almost in the exact opposite position as Windows. Rather than a project that was late and getting later, Apps was on a much more constrained path. Apps was in the final stages of wrapping up the Office 4.x product, the last release of 16-bit Word, Excel, PowerPoint, and Access. The product began shipping many months earlier, but not everything was complete, and the first version of Office 4.0 shipped with older versions of some of the products. Shipping “Office” as one product was a challenge for the next release.

During the relative downtime of the Office products finishing, Word continued to polish the HTML authoring features. Surprisingly, PowerPoint was also at work on HTML. In a visit I made to the PowerPoint team in Cupertino to hear their views on the WWW, I received my first dose of Silicon Valley outside of attending conferences in Santa Clara.

At lunch at a Pizza Hut on Stevens Creek Boulevard in early 1994, surrounded by badge-wearers from Apple, Sun, and other companies, Lucy Peterson (LucyP), the program management leader, shared with me how customers were doing all sorts of crazy things to take slide decks and post them to the WWW. They were taking screenshots of each slide in slideshow view and then adding buttons for next/previous slide to use the minimal capabilities of a browser to show slides. It was crazy. I was caught off guard by how “informed” the distant PowerPoint team was about the internet. I hadn’t thought for a minute that this recent phenomenon originated there. Duh!

To save slides to the WWW, they planned to automate the manual process and make it much better and faster. This came later than the Word feature but proved incredibly popular in the early days of the WWW. If you spend time on the internet wayback machine, you’ll see old presentations with bubbly forward and backward buttons under a slide saved as a single image file, which were output with the PowerPoint Internet Assistant.

As Microsoft was making the transition to an enterprise-focused software company, top of mind was building out the global account management process. Account teams have an insatiable demand for information (translated into 30 or more languages) from Redmond including information sheets, demonstration scripts and tools, technical details, reference documentation, and more. In the early 1990s, a great deal was prepared for print production as well. To distribute this information around the world, a group in the Enterprise Customer Unit (SteveB’s newly formed worldwide HQ team that supported the account teams) collected information on CD-ROMs, which were airlifted by DHL to all the field offices around the world once a month. Using CD-ROM seemed leading edge and consistent with the direction of multimedia computing . . . at least until the WWW.

SteveB wanted me to meet with the team that did all the production and talk to them about using WWW. I did my standard demo but emphasized the distribution of information from tech companies like Novell and Sun. The team remained unconvinced. They raised a series of, in their view, insurmountable challenges, from power of formats to the effort it took to copy all the information to a local server, the lack of bandwidth to even download the materials in a timely manner in most offices. This was my first encounter with WWW meeting someone’s job reality. They didn’t see a path “right now.” Over time, the organization came to embrace the WWW and became some of the largest contributors to Microsoft content. It took time.

My experiences in meeting with Microsoft’s Product Support Service (PSS) faced the same challenges. PSS was tasked with dealing with tens of thousands of customer contacts every day. Most were from individuals calling up Microsoft, wading through a phone tree, and getting help with how to get something done with a product. People called asking how to format documents, install a printer, or, the most dreaded calls, of computers that were slow, crashing, or wouldn’t start. Operating PSS was extremely costly—all of us in product groups tracked call volumes, called generators, and had explicit goals to fix the top issues of the product. It was common knowledge that a call cost Microsoft something like $100, quickly eroding the margins on a sale.

For that reason, meeting with PSS came with the hope of making it cheaper and easier to solve customer problems. PSS loved the idea of distributing software updates over the internet. Taking names and addresses and fulfilling floppy disks was expensive and time consuming. This was already happening with ftp.microsoft.com and CompuServe.

PSS maintained an enormous online system called the knowledge base (KB). PSS engineers were goaled on writing articles that populated the system. These KB articles were the recipes for solving problems. While it seemed natural to just post these on the WWW, the early feedback and challenges showed how difficult it was to search. Beyond that, knowing if an article applied or not was the job of the human agents. Much of the dynamics of a call involved matching what a customer was saying to whether the KB article applied. KB articles are often nice steps preceded by a “do not try this at home” warning or caveat. Throwing these out to the WWW made PSS feel that the presence of the articles was to be call generators not cost reducers. They might have been right.

The use of newsgroups and USENET seemed like another opportunity. PSS was loath to engage with online chat with customers as it was extremely time consuming. On the phone incidents could be resolved in a few minutes. With online messaging or email-based support (already a top customer request) the back and forth could span days. Agents could go off shift or even on vacation and new processes would need to get established. Worse, providing these online contacts probably meant that after an issue was resolved, people returned to the “thread” and used it for other purposes months later.

They were probably right, even though in the moment I thought they were resisting the march of technology. Having been an avid USENET poster for Visual C++, and finding myself caught in many email threads, the concerns were in line with my experience.

When did Microsoft figure out the internet and when did it pivot to be an internet-centric company was the source of much industry chatter. From a Wall Street perspective, Microsoft adapting to, or adopting, internet technologies was generally viewed as one of the most significant corporate strategy changes in recent history. From a regulatory perspective, it is fair to say it was not only viewed with some skepticism, but a more sinister eye. Regardless, it made for an exciting narrative and in a sense a perfect place for a BusinessWeek cover story.

We received word from the most senior public relations people at Waggener Edstrom that a story was in the works, utilizing senior reporter Kathy Rebello. JAllard, BenS, Chris Jones (ChrisJo), and I kicked off a quick email thread and agreed on a timeline—we knew the press loves these kind of timelines. ChrisJo, a new recruit to Windows after working on Microsoft Publisher, was leading program management on the browser. The three of us had become sort of joined at the hip in our efforts and hit it off well. What did we know and when. I was using a predecessor to the Palm Pilot I had purchased in Japan to take notes and had a text file with the timeline that served as our script.

After a series of calls with many executives and participants across Microsoft and a lot of PR handholding, the cover story ran. The story covered exactly what we had experienced in many ways, at least from my perspective. The article had a photo of JAllard, BenS, and I. Ben was in his characteristic Hawaiian shirt. I was clearly in my grunge phase with perhaps the only plaid flannel shirt I ever owned. The story, in the July 15, 1996 issue, and the timeline amounted to an official record of a major corporate turnaround. The BillG memo, Internet Tidal Wave, a year earlier was viewed by many as the start of the turnaround. As we’ve seen here the work began much earlier. It takes time for the work to surface and for a story to come together so a broader community understands it. It also takes time for us to figure out how to tell the story.

The story started with a letter to the editor from the weekly MicroNews newsletter that was still printed and distributed every week:

Oh, our eyes have seen the glory of the coming of the Net,

We are ramping up our market share, objectives will be met.

Soon our browser will be everywhere, you ain’t seen nothin’ yet,

We embrace, and we extend!

Battle Hymn of the Reorg

Anonymous Microsoft Employee in MicroNews

The story went on to say “Microsoft, already the ultimate hardcore company, is entering a new dimension. It’s called Internet time: a pace so frenetic it’s like living dog years—each jammed with the events of seven normal ones.” It also featured thoughts from ever present analysts such as “Until six months ago Gates & Co. appeared lost in cyberspace. It was so far behind…might be sidelined in the new age of Internet computing.” It was all very dramatic and compressed two years into a few pages and some great photos. It was difficult not to feel a sense of accomplishment from my perch, even knowing all I contributed was email and meetings. No matter what all the books and trials might come to say, the company really did a whole bunch of work in a very short time and a lot of it was really good.

Still, it is interesting in hindsight to consider that frequently when facing disruption (still a few years away from existing in business context) incumbents view disruptive forces (products or business models) as additive to what is already being done rather than either orthogonal or full replacements.

On the one hand, we did not abandon any products and start from some notion of “pure internet,” and on the other, most every product that needed to change was a 1.0 product under development or at least early in the classic adoption curve. In fact, the 1.0 internet products such as MSN and Blackbird would come to represent the parts of the strategy that were not at all successful.

Whether or not much of what we ended up doing was too much about adding some internet to things we were already doing was years, maybe decades from revealing itself. Regardless of any product or market realities, the sales force and broader ecosystem around Microsoft fully bought into the dramatic change.

Across the company product, sales, marketing, and more embraced the newness of the internet and WWW. The company went from a small locus of activity to a cross-company buzz of efforts of all kinds. My job as TA was to take Bill’s guidance and evangelize new technology. The internet was an obvious high point for me, though I still believe I received far more from this role than I provided. In that respect, my job was winding down, and it was time for me to go build something.

On to 030. My Performance Review (and An Expense Report)

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit hardcoresoftware.learningbyshipping.com