I think it was when the Chicago team said it would RTM in April that there was a meeting with BillG about Office's RTM date. ChrisP repeated the "Windows + 30 days" ship date and then said, "September." Bill said, "So you're saying April + 30 days is September?" And Chris said, "In Windows date arithmetic, yes."
"Then one day after I joined the OPU team, PPathe, GM of Word, told me what he had started saying to the Word team. Whenever people complained about OPU he reminded the team “[T]he best feature we have for competing with WordPerfect is Excel.” He finally had his messaging that appealed to the Word-first zealots—they would win by having Excel be a great feature of Word. Brilliant"
I always pushed to release products on time, but even using the software developers own time estimates x 2 it would not be enough time. Surprising how software developers kept under estimating the time needed.
It is always a huge challenge to get estimates to line up to reality. The first coping mechanism is to schedule some buffer, and also the full cost of vacation and meetings. Not all of that will happen during coding and essentially is more buffer. Then you track every week with developers giving updates on progress and CURRENT ESTIMATES for their remaining work. This gives the clearest picture of how much work really remains. Then you can realign people or cut features to meet the schedule
Over time as people see there is a positive effect to estimating well, estimates improve.
I’m beginning to wonder whether you chose to write on Substack instead of a book because of trauma from these multi-year release schedules! My company is on a quarterly release cadence and that still seems slow to me.
haha! There's a whole post about "why Substack" at the end. But in all seriousness, as you'll hopefully read the primary reason for the release schedule was twofold. First, making the products work and delivering quality was simply difficult. It took time. Second, the lack of digital distribution meant that simply getting the software physically to customers, installing it on their PCs, and permeating a significant portion of the base of PCs took time. It took years! Many business customers likened deploying Office to "painting the Golden Gate Bridge" in that by the time every PC in an organization had the latest Office and Windows, they had to start the upgrade cycle all over gain. it is why when we were about to get close to disclosing Office 97, the marketing team freaked out about the "rapid pace" and "short time since Office 95". They literally asked us to slow down or customers would have a fit!
the thing about these releases was that even in 3 years at the long end products changed more than the accumulated changes in a typical SaaS app. Even with the ability to release often, most SaaS products see far less significant gain in capabilities over that similar time period. IMO of course :-)
I 100% agree with your points, Microsoft was obviously extremely effective during this time period and the frequency makes sense given the way software was distributed. SaaS people like myself should benefit from the disciplined long term planning like you describe.
This all sounds painful, but I was fairly clued in by friends there and aware of most of this. I saw your pain as industry-wide and was amazed at some of the near sim-ship successes you had.
Being vocally self-critical is great, but I thought you all did a great job, all things considered.
I have been an executive at several companies, and I don't recall a single reorg being done just to "make things better" unless it means dealing with a poor leader situation in a short period of time. Maybe you're saying other parts of MSFT did the latter at times.
Instead, these are typically done to generate movement on new strategies, and in service of Conway's Law to a large degree. Everyone I've ever done or seen at my companies... including MSFT in DevDiv, was done in service of strategy. Then there were the ones we did to achieve "One Strategy" which were not successful, but that's a different topic I'm hoping you get to.
I think it was when the Chicago team said it would RTM in April that there was a meeting with BillG about Office's RTM date. ChrisP repeated the "Windows + 30 days" ship date and then said, "September." Bill said, "So you're saying April + 30 days is September?" And Chris said, "In Windows date arithmetic, yes."
I am certain that is the full version. The specifics I remember were at the "3 year plan" meeting.
I added as footnote because I like this so much.
"Then one day after I joined the OPU team, PPathe, GM of Word, told me what he had started saying to the Word team. Whenever people complained about OPU he reminded the team “[T]he best feature we have for competing with WordPerfect is Excel.” He finally had his messaging that appealed to the Word-first zealots—they would win by having Excel be a great feature of Word. Brilliant"
I love this, and am totally stealing it :)
I always pushed to release products on time, but even using the software developers own time estimates x 2 it would not be enough time. Surprising how software developers kept under estimating the time needed.
It is always a huge challenge to get estimates to line up to reality. The first coping mechanism is to schedule some buffer, and also the full cost of vacation and meetings. Not all of that will happen during coding and essentially is more buffer. Then you track every week with developers giving updates on progress and CURRENT ESTIMATES for their remaining work. This gives the clearest picture of how much work really remains. Then you can realign people or cut features to meet the schedule
Over time as people see there is a positive effect to estimating well, estimates improve.
Wow, the enormous amount of coordination required.
I’m beginning to wonder whether you chose to write on Substack instead of a book because of trauma from these multi-year release schedules! My company is on a quarterly release cadence and that still seems slow to me.
haha! There's a whole post about "why Substack" at the end. But in all seriousness, as you'll hopefully read the primary reason for the release schedule was twofold. First, making the products work and delivering quality was simply difficult. It took time. Second, the lack of digital distribution meant that simply getting the software physically to customers, installing it on their PCs, and permeating a significant portion of the base of PCs took time. It took years! Many business customers likened deploying Office to "painting the Golden Gate Bridge" in that by the time every PC in an organization had the latest Office and Windows, they had to start the upgrade cycle all over gain. it is why when we were about to get close to disclosing Office 97, the marketing team freaked out about the "rapid pace" and "short time since Office 95". They literally asked us to slow down or customers would have a fit!
the thing about these releases was that even in 3 years at the long end products changed more than the accumulated changes in a typical SaaS app. Even with the ability to release often, most SaaS products see far less significant gain in capabilities over that similar time period. IMO of course :-)
I 100% agree with your points, Microsoft was obviously extremely effective during this time period and the frequency makes sense given the way software was distributed. SaaS people like myself should benefit from the disciplined long term planning like you describe.
This all sounds painful, but I was fairly clued in by friends there and aware of most of this. I saw your pain as industry-wide and was amazed at some of the near sim-ship successes you had.
Being vocally self-critical is great, but I thought you all did a great job, all things considered.
I have been an executive at several companies, and I don't recall a single reorg being done just to "make things better" unless it means dealing with a poor leader situation in a short period of time. Maybe you're saying other parts of MSFT did the latter at times.
Instead, these are typically done to generate movement on new strategies, and in service of Conway's Law to a large degree. Everyone I've ever done or seen at my companies... including MSFT in DevDiv, was done in service of strategy. Then there were the ones we did to achieve "One Strategy" which were not successful, but that's a different topic I'm hoping you get to.