031. Synchronizing Windows and Office (the First Time) [Ch. V]

Welcome to Chapter V. Subscribers, if this were a printed book then you’ve just read through a typical trade press book by word count. Since we’re only in 1994, now you know one good reason why Substack makes for a better approach.

1993 to 1994: The rise of the internet dramatically accelerates the growth of the PC, the Windows PC in particular, as it soon becomes a must-have home appliance and an essential business tool for most every profession around the world. Windows PC unit sales have doubled since 1989 to over 40 million units and the growth rate was increasing.

Microsoft and the industry were in a transition. The world was fired up about the Internet and World-Wide Web, while anxiously awaiting a PC that was really up to the task—that would be Windows 95, code name Chicago. Unfortunately, Chicago was running late. Still, the Internet offered a real break in computing separating the early days of 16-bit computing from what was to come with 32-bit computing.

Inside Microsoft’s hallways the mood was different. Most products were still late and buggy, and importantly the strategy remained confusing internally. “Windows, Windows, Windows” was the top line, but the differences and even rivalries between the two Windows teams, Chicago and Cairo/NT, made for complexity. Applications spent the better part of a year finishing the release of the much-hailed Office 4.2, which was the last 16-bit product. While Windows and Office were the main products, the company was spawning new shiny objects at a feverish pace. Online services was growing incredibly fast and the Consumer Division was becoming the favorite destination for the increasingly experienced workforce.

During this I needed to find a new job and would learn valuable lessons along the way.

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

During a visit to my family in Miami, I was bored with the July heat and endless trips to the mall to avoid the heat, so I went to the local CompUSA to buy the newly released Lotus SmartSuite version 2. Wanting to spend time with it firsthand, I loaded it floppy-by-floppy on to my Compaq LTE laptop running Windows 3.11 and used the better part of the vacation diving deep into the product.

The main messaging for SmartSuite was consistency and the way in which each of the programs worked together. At Spring COMDEX 1994, the booth had been a relentless chorus of a work together jingle. The promotional materials offered up SmartIcons® shared across applications as supporting evidence—basically toolbars with customization. As I began to use the 1-2-3 spreadsheet, Ami Pro word processor, Freelance graphics/slides, Lotus Organizer personal information manager, and Approach database (the latter four were acquisitions), I saw a fairly sophisticated suite of products, but I didn’t see a lot of user experience consistency.

It was weird. It felt like we were being marketed to. We were.

A normal person would have taken screenshots of the user experience and compared them. But I was a developer tools person, so I groveled around in the compiled code looking clues to see how shared SmartIcons were in reality. This was a big deal to my Apps friends because performance was everything and loading Word, Excel, and PowerPoint meant a good deal of duplicated code. Surprisingly, all those buttons took a lot of memory and used scarce graphics resources in Windows. Office was a bundle but not an architected product (yet).

Much to my surprise (but given the acquisition history of the product it should not have been), not only did each Lotus app have its own copy of icons, but each frequently varied across apps.

Busted. We were being marketed to.

I quickly put together a nearly 30-page memo, detailing inconsistencies and inefficiencies in the product. I made a giant table of copy/paste between apps to see how each was handled. In hindsight, decades later, nobody would think this was even a problem, but in the early days of cross-application scenarios, simply moving information between products was hit and miss. It had been an area Office 4.x had worked hard on, especially using the new object linking and embedding (OLE) technology. I also detailed the disk footprint, memory utilization, and even the number of help topics.

Consistency was all the rage in the world of applications. There were two historic drivers of this. First, there was a strong belief, in part encouraged by Microsoft and Apple, that a graphical interface was inherently consistent across applications. Apple relentlessly touted their extensive documentation, Human Interface Guidelines or HIG, as a sort of rules of the road for building graphical apps. The HIG provided specific, almost Talmudic, rules for how to display commands, dialog boxes, and menus. Windows was just beginning to recognize the importance of this kind of effort and with Chicago would release a major set of guidelines, the Windows Application Design Guide or WADG (wad-gee). Unlike MS-DOS where every application made up its own user-interface, graphical products should all be very similar as a result.

Second, consistency was supposed to make it easy to move from one application to another without learning an entirely new and equally arcane command system. Most people used only a single application and what easier way to get more out of a PC than if moving from one application to another did not require learning a bunch of new user interface, especially in suites of products that were coming to dominate sales. In reality, developers would be developers and most every application went in its own direction, all justifying that by saying customers had specific needs (a topic we will return to with respect to Office).  

To that end my competitive memo was a source of pride. Whether or not any of my findings were relevant to sales or competitive positioning was unclear. My own lens was not particularly broad at age 27. But, up until that point, reviewers of SmartSuite had been quite impressed with the integration and I was growing increasingly disappointed in the lengthy product reviews that failed to reveal all the details.

While I wielded a great technology buzzsaw, I was also applying Microsoft’s perspective, not necessarily what Lotus was looking to accomplish or what reviewers would see. For example, my focus on shared code came straight from BillG as that was his hot button. The Lotus products clearly hadn’t focused on that at all. I thought they were “wrong” not simply different. This mismatch was something I had seen in the evaluations of Borland C++ versus Microsoft VC++. For example, Borland had a compiler optimization switch “/O” that was, basically, “make this code as fast as possible by enabling all the best optimizations.” To us compiler-heads at Microsoft, we thought of this as technical nonsense because each of the myriad potential optimizations meant something unique to the programmer (literally the entire alphabet of command line switches), but it had captivated reviewers. I came to champion (and push) the addition of “/O” for our complier and it turned out that it worked with reviewers. When Ami Pro, the Lotus SmartSuite word processor, demonstrated its new ease-of-use features under the umbrella of working together, it similarly captured the attention of reviewers, even if deep down in technical details it didn’t make much sense.

This lesson really stuck with me.

In distributing the memo, which as Bill’s TA garnered attention, and talking with the Office team it became clear that we saw things the same way—Lotus was doing a great job marketing—but the Microsoft team needed to do better with Office architecture. It needed to do a version of “/O” but one that was consistent and marketable. My writeup on SmartSuite offered some fuel for that work. Pete Higgins (PeteH) even emailed me to ask about the memo.

PeteH was the leading protégé of MikeMap and the spiritual leader of the newly named Desktop Applications division (DAD). He rose through the ranks, eventually leading Excel and then all of Office. Pete represented the kind of leader, manager, and team member we all aspired to be, representing the very best of the MikeMap value system and intense focus on customers and the business. On my Lotus memo he casually asked me rhetorically, “Why didn’t our team write this up first?” I loved that but also felt badly about it. My intent had not been to make the DAD team look bad. I found myself sending around apologies each time someone asked for the memo. It made me think about the lessons JeffH had imparted, about managing across teams when people perceived me to be in the “power position,” which as TA they certainly did even though I felt like a junior assistant.

The DAD teams were busy finishing Office 4.0 which started in late 1993 with a launch event but lasted until the summer of 1994 when the last product would finally ship. It was crazy—it took almost 9 months to complete a launched product. In fact, the first boxes (the physical boxes with floppy disks) came with a new version of Excel, but the older releases of Word and PowerPoint. Buyers were given coupons for the updates to the other applications which would dribble out over the coming months. Internally, the team referred to this as an “air box” because customers got coupons instead of new software. Finally, the much-promised Office Professional with a new version of the Microsoft Access database shipped in the summer of 1994. Office was the team that shipped on time! It was just that organizationally each of the component applications was a different team operating at a different velocity. Lotus even capitalized on this by running advertisements in the trade press pointing out the IOUs.

Over in Systems, products were also late but the strategy was confusing as well. The industry seemed to be questioning whether the future (there was always just one future, the future) was going to be Windows NT or Chicago.

The organizational split underlying the technology differences was front and center for me as I was looking for a job. I would talk to the Chicago team and hear about how they were the natural evolution of Windows and how Windows NT took way too much memory and was not compatible with all the software and devices that customers used, especially all the new games and multimedia on the Internet. The NT team mostly thought the Chicago product was fragile and toy-like and lacked the architecture to ever achieve the required security and robustness the PC needed. There was also the Cairo team that felt everything was rather pedestrian until they would ship. Meanwhile the industry was just waiting and waiting for Chicago. In many ways, Windows 3.11 was old news. Microsoft had been touting 32-bit computing long enough and now the market wanted a product. In particular, all the new Internet tools really needed the connectivity and multi-tasking capabilities in 32-bit Chicago.

The number of new products under development across Microsoft was stunning. I’d seen them spring up in meetings with BillG. These new teams were attracting seasoned developers and program managers and provided new opportunities for career growth. Though at the same time there was a growing tension between the major teams like Applications and Platforms (or Systems in old terminology) and these new teams, be it Online Services, Consumer, or the new Advanced Consumer Technology groups. The prevailing view was that people were drawn to these new shiny objects teams to “rest and vest” because somehow the work was perceived to be easier than slogging through compatibility bugs and increasingly difficult memory and disk constraints. Such a characterization was decidedly rude, but it was in the air. Microsoft was developing a bit of a cultural pecking order. Increasingly groups began to talk about metrics like revenue per employee as a way of distinguishing the ever-growing list of teams that were in investment mode.

I needed to find a “real job.” There was not much precedent to this transition, but my self-imposed 18 months was almost up. Months after writing the Lotus memo, as Office 4.x was near complete, I started looking. The memo served to discuss the potential of working in DAD. It was not my first choice given my roots in Tools and focus on databases and programming languages in grad school. Plus, Bill had clearly demonstrated that from his perspective Windows was central and where the “hard problems” that required “IQ” existed. Still, my mentor and previous boss, Jeff Harbers, was an original in Apps and built our AFX team around that culture and he insisted and brokered a discussion.

That first stop was with Chris Peters (ChrisP.) At the end of 1993 with the launch of Office 4.0, ChrisP was promoted to vice president of the newly formed Office Product Unit (OPU) reporting to PeteH in DAD, who reported into MikeMap’s expansive WWPG. OPU sounded redundant—why did Applications need an Office Product Unit to make Office? I was confused and intrigued.

When ChrisP introduced himself he always said something like, “I grew up on Bainbridge Island, went to the University of Washington, didn’t have a car when I started at Microsoft in 1981 then worked on DOS 2.0, Windows 1.0, Mouse 1.0, DOS Word 1.0, and then Excel development manager (DM) and Word BUM [Business Unit Manager].”

His Microsoft pedigree was legendary. He was one of the few people to have worked on most of the major products, including hardware and in Apps, holding senior roles on both Word and Excel in development. That was a big deal. In reality, it was only part of ChrisP’s contribution—he was also among the most creative leaders at the company with a true fondness for art (he championed the acquisition of an M.C. Escher work as an original member of the Microsoft Art Committee and went on to become a professional artist) and at any given time he would concurrently and deeply be immersed in a new hobby like rockets, robots, architecture, bowling, or film photography. ChrisP was most well-known for instilling the culture of shipping—the idea that shipping software trumps everything—memorialized with the ever-present quote “shipping is a feature.” This shipping focus was elevated to historic levels with Excel 3.0 shipping a mere 11 days late from its original planned ship date.

For this newly formed group, ChrisP was thinking about picking a key direct report as group program manager (the talented leader the group inherited did not want to manage a large team). I had not managed a big group before, but then again most people had not. He was not as interested in whether I had all the answers myself as he was interested in if I could manage and lead the team. I was, in a sense, interviewing to join the DAD family, as much as to work on Office. Sitting in the courtyard between buildings 16 and 17, a patio with commemorative Ship-It tiles celebrating the release of each Microsoft product, we both started to realize DAD was the right fit.

DAD was organized by business units as a result of MikeMap’s transformative organization in 1988. Each of Word, Excel, and PowerPoint (and also Microsoft Project) were headed by seasoned general managers and had all the resources to plan and develop products. There was a single marketing organization which divided resources across the products, with dedicated leaders for each application. This organization worked spectacularly well and resulted in the leadership of Word and Excel on Macintosh and the increasing success of the new Office bundle.

My first work would be figuring out what “Office” meant—both the product and the newly formed team. Why was there a new organization to build the product people knew about? Or did they? The Office product was not close to as widely known as Excel on Windows or both Word and Excel on Macintosh. PowerPoint was light years behind. The Lotus compete memo gave some clues. All the meetings the Office team had held with BillG were about code sharing and consistency, something that customers wanted to buy but Microsoft was yet to sell.

ChrisP later offered me the role of group program manager (GPM) in the newly formed Office Product Unit. I reported to him. The initial Office PM team, called OFFPM, was 14 people mostly made up of the team that managed the setup and installation program. We would be growing quickly, but deliberately.

Two lessons really stuck with me in what would essentially be my last job search. First, I decided to run towards the fire and joined the relatively large and mature organization rather than join one of the exciting new businesses. Applications in 1994 was $2.9 billion in revenue compared to Platforms revenue of $1.5 billion. The success of Windows 3.x had driven sales of Microsoft’s own Windows applications to account for 85% of revenue by 1994, after years of dominance by Macintosh platform revenue. Joining Desktop Applications meant I was joining a team with a great deal of responsibility to Microsoft on the business side, and at the same time the team was established and had a very strong culture. It was exactly the kind of job many people at Microsoft were not gravitating towards at the time.

Second, the conversations with ChrisP about management were very difficult and had the direct effect of shaking my own confidence. It was entirely true that I had hardly managed anyone prior to this job and stepping up to manage a team of 14 with two levels of management was unheard of in DAD, where people worked their way up (as ChrisP had). The company was being forced to make these leaps because of the explosive growth in headcount, but DAD generally resisted that. In discussing this with Chris he explained what a leap this was for me and how in taking this job I was not signing up for a passive role in learning how to manage. I would need to rely on the strength of the team around me and also recognize the level of trust the organization was placing in me. While it was humbling, it was far more terrifying. Years later I would learn just how much of this was based on the newness of the Office Product Unit and DAD in a sense trying to create a new culture as well. There was no doubt a bet on me.

A note about today as I write this. I rarely ever gave direct career advice even for relatively routine internal moves at Microsoft. This transition for me cemented two things that I always do offer. First, run towards the fire in a big company, especially early in career. This is so much harder than it looks—the seductive roles are always the new technologies and new teams. It always seems like there is more opportunity there but there is also more opportunity to get little done because of the very forces of a big company that tend to draw all things towards the existing and critical businesses. Second, always make sure the team is making the same level of bet on you that you are capable of making on them.

The reason I was offered a such a stretch job was because the team (ChrisP and my peers) were going to support me and essentially train me for the role. It wasn’t that I was unqualified, but that the strategic view and the technology perspectives I brought were only part of the job. Managing people and leading a team at that scale were new to me. ChrisP reminded me with his final words, being a manager of a team this big is always new the first time. One day you’re a lead or not a manager and then the next day people are lined up outside your door asking you what to do. He assured me that he had the confidence I could do the job, but also that he and others were there to support me.

I was very excited to have a real job. In just about every way this would be the last job change I would make where I was worried about fitting in or if the job was right for me. I found a home and a family in DAD as I would quickly learn. For the next ten years and six releases of Office and innumerable service packs and bug fixes I would feel as though I was on a mission and part of something much larger and more important than myself. I felt as though any efforts I made would return so much more because of the strength of the team I was fortunate enough to be part of.

On to 032. Winning With the Suite

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