Regarding the M.C. Escher painting. The company, newly flush with money, bought art, displayed it throughout the buildings. This was done through the 'art committee', a bunch of people we'd never heard of, doing useless jobs elsewhere. Or so we told each other. ChrisP, one of us, didn't have the right degree, the right credentials, but so what he just bullied himself onto the committee. First thing he proposes is to buy an Escher woodcut print. Oh no the committee says, that's not the sort of thing we're focusing on. He runs right over them, buys it. It immediately becomes the favorite piece in the entire collection, fought over for display rights in this building or that. Of course the committee declares that they were fully on board with it right from the start.
With respect to the “aggressiveness” of what was done, that had to do with how we divided resources between the teams and the quality of the engineering leaders we were able to recruit into the team. Headcount was always a currency at Microsoft. We formed OPU teams by agreeing with the app teams that a certain number of people would move from the app teams to OPU, and those positions would be refillable. (App teams lost people but retained headcount.) This is consistent with an earlier post where the first rule of shipping is deciding on resource levels. People reading this have seen this now at least twice, the number of people working on Office 94/5 and now the number of people working on Office 96/7. (This reorganization philosophy was the start of an HR process between projects that I am sure Steven will talk about soon, where professional growth and organizational need became higher order concerns balanced with the older need to build depth expertise in app categories.)
With the agreed number of feature teams, we divided up the ideas of what new features (i.e. no app had that feature before, like content indexing), what old features would benefit by sharing (mostly UI consistency), and what underlying technology was necessary to get the previous parts to work in the apps. A feature team would then investigate its area and with experienced and high potential up and coming development managers figure out the work that would fit into the milestone structure. This was the planning structure that worked to create Office 4.x and 95 and we had faith in it. From this perspective it was not aggressive at all, although developers are absolutely optimistic when they want to accomplish something.
There has been some discussion about the Office engineering practice being not really a waterfall process and not really an agile process as people understand it today. The Office process had many elements of agile though. Dev leads had weekly equivalents to daily stand ups. Milestones were longer but were essentially sprints. There was a feature burndown list (the milestone schedule) and a quality burndown list (the bug list). These structures helped the team learn as it went along and make the necessary decisions as soon as possible. The waterfall like aspect of trying to predict at the beginning what would be built and when was necessary to make decisions up front about whether to do entire areas of features and allowed for balancing resources between teams at the margins.
It was important to bring in people from the app teams in order to have the right technical judgment on what would and wouldn’t work for an app. It was also important to have experienced people setting the culture and attitudes of the OPU teams. The rule that the shared teams would do the integration into at least one of the apps came from the experiences of previous attempts to make shared code. There was the “Apps Architecture” team and also instances of Windows trying to recreate Office UI elements. Both teams lacked the pragmatic experience of working in the apps and created solutions that were not workable or just weren’t adopted by Office apps. The best example is the Windows 95 attempts at toolbars and standard dialogs like print.
Office 96/7 created the ability to make new apps much faster. PhotoDraw and OneNote are examples. My favorite example is Hagaki Studio, an app sold only in Japan to make the traditional New Year cards. It was a productization of the Lime test code and relied primarily on the Escher drawing code. Code that is designed for reuse gets reused in ways one never thought of originally!
Being on the App side in Excel 97 of this experience, I seem to remember a lot of work trying to "convince" the app team to adopt the shared code and the app teams had devs assigned to do some of that adoption work. In Office 2K more of the work was done by OPU so there was less reliance upon needing to convince the app teams it was the "right" thing to do. Also the OPU team got more freedom to work directly in all the app code bases.
I remember working working with PeteMor about all of those command bar buttons. That was a huge task. 15x15 and 32x32 and making them all consistent and the exact wording of all the commands. Surprised you didn't mention the File Open/Save dialogs as that was also a huge effort where every app seemed to have their own "unique" requirements.
What you describe happened across all of the shared features. Help/Assistant, Command bars, File open/save, drawing (Escher), and on and on. All of these required talking with people from the app teams and OPU to drive consistence. It was quite a dance.
"it also built the foundation for an execution machinery that would become unprecedented and largely responsible for what ultimately became the largest and most secure business at Microsoft."
During the discussions about breaking up the company, my money manager at the time asked me which company I wanted stocks in should the breakup happen - the Office Company or the Windows company". My answer was instantaneous - "The Office Company, hands down"
Steve, the link to the next post in the series redirects me to the website from the app. I’ve been using the Substack app to read the book and have been navigating it as a linked list, and bookmarking the one I’m on. Other software folks might be doing the same things, so I wanted to let you know.
Regarding the M.C. Escher painting. The company, newly flush with money, bought art, displayed it throughout the buildings. This was done through the 'art committee', a bunch of people we'd never heard of, doing useless jobs elsewhere. Or so we told each other. ChrisP, one of us, didn't have the right degree, the right credentials, but so what he just bullied himself onto the committee. First thing he proposes is to buy an Escher woodcut print. Oh no the committee says, that's not the sort of thing we're focusing on. He runs right over them, buys it. It immediately becomes the favorite piece in the entire collection, fought over for display rights in this building or that. Of course the committee declares that they were fully on board with it right from the start.
With respect to the “aggressiveness” of what was done, that had to do with how we divided resources between the teams and the quality of the engineering leaders we were able to recruit into the team. Headcount was always a currency at Microsoft. We formed OPU teams by agreeing with the app teams that a certain number of people would move from the app teams to OPU, and those positions would be refillable. (App teams lost people but retained headcount.) This is consistent with an earlier post where the first rule of shipping is deciding on resource levels. People reading this have seen this now at least twice, the number of people working on Office 94/5 and now the number of people working on Office 96/7. (This reorganization philosophy was the start of an HR process between projects that I am sure Steven will talk about soon, where professional growth and organizational need became higher order concerns balanced with the older need to build depth expertise in app categories.)
With the agreed number of feature teams, we divided up the ideas of what new features (i.e. no app had that feature before, like content indexing), what old features would benefit by sharing (mostly UI consistency), and what underlying technology was necessary to get the previous parts to work in the apps. A feature team would then investigate its area and with experienced and high potential up and coming development managers figure out the work that would fit into the milestone structure. This was the planning structure that worked to create Office 4.x and 95 and we had faith in it. From this perspective it was not aggressive at all, although developers are absolutely optimistic when they want to accomplish something.
There has been some discussion about the Office engineering practice being not really a waterfall process and not really an agile process as people understand it today. The Office process had many elements of agile though. Dev leads had weekly equivalents to daily stand ups. Milestones were longer but were essentially sprints. There was a feature burndown list (the milestone schedule) and a quality burndown list (the bug list). These structures helped the team learn as it went along and make the necessary decisions as soon as possible. The waterfall like aspect of trying to predict at the beginning what would be built and when was necessary to make decisions up front about whether to do entire areas of features and allowed for balancing resources between teams at the margins.
It was important to bring in people from the app teams in order to have the right technical judgment on what would and wouldn’t work for an app. It was also important to have experienced people setting the culture and attitudes of the OPU teams. The rule that the shared teams would do the integration into at least one of the apps came from the experiences of previous attempts to make shared code. There was the “Apps Architecture” team and also instances of Windows trying to recreate Office UI elements. Both teams lacked the pragmatic experience of working in the apps and created solutions that were not workable or just weren’t adopted by Office apps. The best example is the Windows 95 attempts at toolbars and standard dialogs like print.
Office 96/7 created the ability to make new apps much faster. PhotoDraw and OneNote are examples. My favorite example is Hagaki Studio, an app sold only in Japan to make the traditional New Year cards. It was a productization of the Lime test code and relied primarily on the Escher drawing code. Code that is designed for reuse gets reused in ways one never thought of originally!
Being on the App side in Excel 97 of this experience, I seem to remember a lot of work trying to "convince" the app team to adopt the shared code and the app teams had devs assigned to do some of that adoption work. In Office 2K more of the work was done by OPU so there was less reliance upon needing to convince the app teams it was the "right" thing to do. Also the OPU team got more freedom to work directly in all the app code bases.
I remember working working with PeteMor about all of those command bar buttons. That was a huge task. 15x15 and 32x32 and making them all consistent and the exact wording of all the commands. Surprised you didn't mention the File Open/Save dialogs as that was also a huge effort where every app seemed to have their own "unique" requirements.
What you describe happened across all of the shared features. Help/Assistant, Command bars, File open/save, drawing (Escher), and on and on. All of these required talking with people from the app teams and OPU to drive consistence. It was quite a dance.
"it also built the foundation for an execution machinery that would become unprecedented and largely responsible for what ultimately became the largest and most secure business at Microsoft."
During the discussions about breaking up the company, my money manager at the time asked me which company I wanted stocks in should the breakup happen - the Office Company or the Windows company". My answer was instantaneous - "The Office Company, hands down"
Steve, the link to the next post in the series redirects me to the website from the app. I’ve been using the Substack app to read the book and have been navigating it as a linked list, and bookmarking the one I’m on. Other software folks might be doing the same things, so I wanted to let you know.