Run towards the fire and make sure the team is making the same level of bet on you that you are capable of making on them. —My lessons in searching for a next role
There were a set of actions taken before Steven’s arrival to compete with Lotus SmartSuite. He has foreshadowed this with his choice of graphics in this first chunk.
PCs were evolving quickly into machines with enough RAM, disk space, and CPU power to run more than one program at a time. In parallel, companies were starting to put “a PC on every desk” and IT departments were scrambling to figure out how to contain the cost of training and supporting their users. These were the dynamics driving the move from “best of breed” applications to office suites.
Lotus deserves credit for seeing these dynamics first, even if their implementation was mostly a marketing show. BillG deserves credit for having the foresight to fund the development of a complete family of applications inside Microsoft early on. Both Lotus and Microsoft were dealing with the problem of turning multiple independent engineering and marketing teams into cohesive teams working on suites. Lotus saw the market first but Microsoft had more of the technical assets in house.
In DAD, there was a concept of an Office product, but it was mainly a pricing bundle. (Personal note, my most lovely wife Stephanie was the product manager responsible for Office for Macintosh, the first major product bundle to ship on CD-ROM.) In response to Lotus’ marketing we started to think through how to deliver on application integration. We saw two dimensions to this, integrating data through compound documents, and user experience.
The prime example of a compound document was a Word document containing Excel tables and charts. Another example was a PowerPoint presentation with Excel tables and charts. In the Windows 2.0 days a feature was created to show off data messaging between applications known as Dynamic Data Exchange (DDE). Many developer demonstrations were done showing Excel controlling a submarine hunting fish in a virtual aquarium (shoutout to Ed Fries aka Fast Eddy aka EdF), which later gave way to Excel controlling a t-shirt cannon. DDE was expanded to become Object Linking and Embedding (OLE) which allowed for the compound document (Word) to display a presentation of application data (a picture of an Excel table) and store the application’s private data (the XLS file) behind the scenes. This allowed the user to think they had one Word document with an Excel table in it. When they wanted to edit the table, they simply double clicked the picture of the table to start Excel. When Excel closed it returned the presentation and private data back to Word. Office was ahead of SmartSuite in this area.
Office was woefully behind in the user experience area. In the Office 4.0 timeframe, we attempted to fix that by creating shared specifications of user interface features that would be implemented by each application team. A small group of program managers led by ChrisGr was started to write the specifications. Andrew Kwatinetz (AndrewK) drew the job of specifying the top-level menus (File, Edit, View, Help) to create a veneer of user interface consistency. As a lesson in organizational dynamics, getting buy-in on each specification was a herculean effort and giant argument between the application teams. I remember many arguments over such substantive issues as, “Should toolbars be 13 pixels tall or 14 pixels tall?” In hindsight they were silly arguments and a huge waste of time. But waste time we did. Those arguments were then amplified as the process of writing code to match the spec created opportunity for application teams to create arbitrary differences. I wrote the code for the “Format Font” dialog in Excel according to the new shared Office specification. Then the PowerPoint team implemented theirs. Huh, it was really different, so I re-wrote the Excel dialog to match. Then Word implemented their dialog and it was completely different yet again. I really enjoyed my third implementation of the Format Font dialog!
As Office 4.x was wrapping up, we asked ourselves how we could make Office work better for end users, but also for ourselves. In one of my many visits to MikeMap to help install pre-release builds of Office on his PC, I was clear that if we wanted a feature to look identical and work identically between the applications, we would need to figure out how to write the code once.
Enter the Office Product Unit, the expansion of ChrisGr’s program management team.
On Borland C++ and /O: in one of the benchmark suites of compiled C/C++ code, there was a calculation that multiplied by 13. Borland wrote a hand-optimized 'times13' routine in x86 assembler, had the compiler parse for it, recognize it, plug it in. If your code multiplied by 14, well sucks to be you, you got the slow generic stuff, but 13 ooh that'd cook. This was both totally cheating and totally legit.
Love the "run towards the fire" maxim, particularly early in career. I received similar but less pithy advice early in my career, this is a much better phrasing.
Chrisp's comments on scaling up were probably as much about his own good self as they were about you and your first management job. On the day he was promoted to VP of Office, I walked by his office (an interior office that was likely temporary) and congratulated him on the promo. He looked a bit uncomfortable and then confided that he felt like an absolute fraud and was just sitting there waiting for someone in HR or Legal to come by to strip him of the title and correct that enormous mistake!
I apologize if all my comments seem to revolve around your direct competitors, but most of my career appears to revolve around your direct competitors ....
I bought my first computer with lawn-mowing money in 1994. Because of the local store that sold it to me, it came with Lotus Smartsuite 3.1. I barely remember opening most of the applications, except for Ami Pro (3.1). I still have fonder memories of Ami Pro than of any word processor I have ever used. I still have Ami Pro documents on my hard drive (I really should translate those once and for all ...). It really was excellent in almost every way (embedding images was kind of terrible, but anything with text would let you soar).
I learned two things using Ami Pro that have stayed with me ever since and which I suspect will come up in some form as you keep writing this journey:
1. IBM extensively rewrote Ami Pro as Word Pro for Windows 95 and managed to completely kill the things about it that were any good. The lessons I took from this in hindsight were that if you want to / have to do a huge rewrite on your codebase you had either better understand what people like about the thing you already have or you had better be prepared to explain to customers why the changes are necessary for a next-generation product. I have seen both of these things done successfully -- IBM did not execute either of them in the Word Pro rewrite. Even the feel of letters appearing when you touched the keys was somehow off in Word Pro.
2. A suite of products has to have more than one superstar. Arguably Smartsuite had two -- Lotus 1-2-3 and Ami Pro although the former never mattered to me. WordPerfect office only had one--Word Perfect. Even today in Apple's trio of iWork applications KeyNote is excellent, Pages is good, and Numbers is miserable. But Microsoft Office always had applications that were above average (and today they are all extremely strong). I am certain that was a key part of Office's ultimate success.
Back in the days of one application at a time DOS I was a big user of WordPerfect. It wasn't until Windows 3.1 that I investigated word processors on Windows.
I remember reading multi-page comparisons of Word, Ami Pro, and WordPerfect for Windows in PC Magazine, PC Week, etc. I thought Ami Pro was the way to go at the time, but I wound up getting a new PC before I could purchase it. If I recall correctly, th new PC came with both Microsoft Works and Microsoft Word.
I did a quick search just now and couldn't find any history on that SKU. I know it was a common complaint at the time; people had Works but really wanted Word.
Welcome to OPU Steven!
There were a set of actions taken before Steven’s arrival to compete with Lotus SmartSuite. He has foreshadowed this with his choice of graphics in this first chunk.
PCs were evolving quickly into machines with enough RAM, disk space, and CPU power to run more than one program at a time. In parallel, companies were starting to put “a PC on every desk” and IT departments were scrambling to figure out how to contain the cost of training and supporting their users. These were the dynamics driving the move from “best of breed” applications to office suites.
Lotus deserves credit for seeing these dynamics first, even if their implementation was mostly a marketing show. BillG deserves credit for having the foresight to fund the development of a complete family of applications inside Microsoft early on. Both Lotus and Microsoft were dealing with the problem of turning multiple independent engineering and marketing teams into cohesive teams working on suites. Lotus saw the market first but Microsoft had more of the technical assets in house.
In DAD, there was a concept of an Office product, but it was mainly a pricing bundle. (Personal note, my most lovely wife Stephanie was the product manager responsible for Office for Macintosh, the first major product bundle to ship on CD-ROM.) In response to Lotus’ marketing we started to think through how to deliver on application integration. We saw two dimensions to this, integrating data through compound documents, and user experience.
The prime example of a compound document was a Word document containing Excel tables and charts. Another example was a PowerPoint presentation with Excel tables and charts. In the Windows 2.0 days a feature was created to show off data messaging between applications known as Dynamic Data Exchange (DDE). Many developer demonstrations were done showing Excel controlling a submarine hunting fish in a virtual aquarium (shoutout to Ed Fries aka Fast Eddy aka EdF), which later gave way to Excel controlling a t-shirt cannon. DDE was expanded to become Object Linking and Embedding (OLE) which allowed for the compound document (Word) to display a presentation of application data (a picture of an Excel table) and store the application’s private data (the XLS file) behind the scenes. This allowed the user to think they had one Word document with an Excel table in it. When they wanted to edit the table, they simply double clicked the picture of the table to start Excel. When Excel closed it returned the presentation and private data back to Word. Office was ahead of SmartSuite in this area.
Office was woefully behind in the user experience area. In the Office 4.0 timeframe, we attempted to fix that by creating shared specifications of user interface features that would be implemented by each application team. A small group of program managers led by ChrisGr was started to write the specifications. Andrew Kwatinetz (AndrewK) drew the job of specifying the top-level menus (File, Edit, View, Help) to create a veneer of user interface consistency. As a lesson in organizational dynamics, getting buy-in on each specification was a herculean effort and giant argument between the application teams. I remember many arguments over such substantive issues as, “Should toolbars be 13 pixels tall or 14 pixels tall?” In hindsight they were silly arguments and a huge waste of time. But waste time we did. Those arguments were then amplified as the process of writing code to match the spec created opportunity for application teams to create arbitrary differences. I wrote the code for the “Format Font” dialog in Excel according to the new shared Office specification. Then the PowerPoint team implemented theirs. Huh, it was really different, so I re-wrote the Excel dialog to match. Then Word implemented their dialog and it was completely different yet again. I really enjoyed my third implementation of the Format Font dialog!
As Office 4.x was wrapping up, we asked ourselves how we could make Office work better for end users, but also for ourselves. In one of my many visits to MikeMap to help install pre-release builds of Office on his PC, I was clear that if we wanted a feature to look identical and work identically between the applications, we would need to figure out how to write the code once.
Enter the Office Product Unit, the expansion of ChrisGr’s program management team.
On Borland C++ and /O: in one of the benchmark suites of compiled C/C++ code, there was a calculation that multiplied by 13. Borland wrote a hand-optimized 'times13' routine in x86 assembler, had the compiler parse for it, recognize it, plug it in. If your code multiplied by 14, well sucks to be you, you got the slow generic stuff, but 13 ooh that'd cook. This was both totally cheating and totally legit.
Love the "run towards the fire" maxim, particularly early in career. I received similar but less pithy advice early in my career, this is a much better phrasing.
Chrisp's comments on scaling up were probably as much about his own good self as they were about you and your first management job. On the day he was promoted to VP of Office, I walked by his office (an interior office that was likely temporary) and congratulated him on the promo. He looked a bit uncomfortable and then confided that he felt like an absolute fraud and was just sitting there waiting for someone in HR or Legal to come by to strip him of the title and correct that enormous mistake!
I apologize if all my comments seem to revolve around your direct competitors, but most of my career appears to revolve around your direct competitors ....
I bought my first computer with lawn-mowing money in 1994. Because of the local store that sold it to me, it came with Lotus Smartsuite 3.1. I barely remember opening most of the applications, except for Ami Pro (3.1). I still have fonder memories of Ami Pro than of any word processor I have ever used. I still have Ami Pro documents on my hard drive (I really should translate those once and for all ...). It really was excellent in almost every way (embedding images was kind of terrible, but anything with text would let you soar).
I learned two things using Ami Pro that have stayed with me ever since and which I suspect will come up in some form as you keep writing this journey:
1. IBM extensively rewrote Ami Pro as Word Pro for Windows 95 and managed to completely kill the things about it that were any good. The lessons I took from this in hindsight were that if you want to / have to do a huge rewrite on your codebase you had either better understand what people like about the thing you already have or you had better be prepared to explain to customers why the changes are necessary for a next-generation product. I have seen both of these things done successfully -- IBM did not execute either of them in the Word Pro rewrite. Even the feel of letters appearing when you touched the keys was somehow off in Word Pro.
2. A suite of products has to have more than one superstar. Arguably Smartsuite had two -- Lotus 1-2-3 and Ami Pro although the former never mattered to me. WordPerfect office only had one--Word Perfect. Even today in Apple's trio of iWork applications KeyNote is excellent, Pages is good, and Numbers is miserable. But Microsoft Office always had applications that were above average (and today they are all extremely strong). I am certain that was a key part of Office's ultimate success.
Any thoughts on what “run toward the fire” would mean in present-day Microsoft?
I remember using Ami Pro before Word for Windows came out.
Back in the days of one application at a time DOS I was a big user of WordPerfect. It wasn't until Windows 3.1 that I investigated word processors on Windows.
I remember reading multi-page comparisons of Word, Ami Pro, and WordPerfect for Windows in PC Magazine, PC Week, etc. I thought Ami Pro was the way to go at the time, but I wound up getting a new PC before I could purchase it. If I recall correctly, th new PC came with both Microsoft Works and Microsoft Word.
I did a quick search just now and couldn't find any history on that SKU. I know it was a common complaint at the time; people had Works but really wanted Word.