The Crabby Office Lady represented a sea change for me. Being the "ineffectual, middle-management suckup" that I was, when I saw and read the first column(s), I was initially alarmed that we had published something with such an unprofessional and sassy tone, so I asked Shelley Benson (who ran the content team) about it. She immediately presented live data and feedback from customers who had read Crabby's column and who were overwhelmingly positive toward it--and toward Microsoft as well. Comments such as "at last, Microsoft puts on its human face" and the like were common. And the satisfaction ratings were unambiguous. Crabby was beloved! So I grew a spine and backed off. Through the years, this became one of my canonical anecdotes for the power of direct customer feedback. And a note on Steven as a manager: throughout this time, I do not recall any drama happening between him and HR over Crabby. That's because he insulated his teams from most of the BS that happens in large orgs. My life at work always seemed so much simpler than my peers in other divisions. I used to wonder what they were doing wrong, when really it was all about what Steven was doing right. Respect!
Something that comes across very clearly by its prominent absence from everything that Steven discusses is the enormous complexity of successfully running teams that are as (very) large as the ones Steven managed. It's so very apparent that he was (is) extremely accomplished at it simply because of his continued rather stratospheric rise throughout the story, yet he never discusses the challenges except as they relate to the story of Microsoft itself. It's such an intrinsic part of shipping anything at this scale that I'd love to read his thoughts on what he did that worked so well. (Perhaps that's discussed in later chapters?) For what it's worth, based in what Steven has written, I have assumed essentially what you have observed regarding Steven explicitly insulating his teams from distracting organisational BS so that they could just get on and do their job. That's my idea of a leader :)
Thank you for reading so closely. I definitely appreciate this observation. I wanted to offer a couple of thoughts.
A quick answer might be "you have no idea!" meaning yes this was a big part of the job and generally most people had no idea how much of the job was that. But I don't like that answer and don't like the way it makes the whole experience sound. While it is true it is also a cultural attribute.
Many people love to talk about the org charts of tech companies (https://www.businessinsider.com/big-tech-org-charts-2011-6). I've written about that elsewhere specifically how much I dislike the way it portrays things. Interference means you are against cross-group collaboration and cross-group is ALWAYS good so to be against it means ALWAYS bad.
The culture at Microsoft that caused so much "interference" that ends up getting depicted as above is precisely because the company did not have a centralized command and control of the product strategy combined with (esp in the 1990-2010 period) any reliable execution for any one group. In other words we didn't have a centralized command and control strategy AND even if we did we lacked execution to deliver on the connections between groups. The first part was by design and the second part caused much of the tension.
Many believe companies should have a single strategy and execute. This works at small scale and it works at large scale for one business. But Microsoft was a portfolio of businesses and although they were related they also served wildly different customers and business models. Only when a subset of products came together at the enterprise customer level did it seem like we had one customer. Even then, however, products like Windows were used in the enterprise but the primary business was to PC makers; a product like Office was used by individuals and teams and almost always purchased by business. These are inherent conflicts of scale. For the first decade of Windows it was exclusively an OEM product. Office was almost exclusively a product purchased by individuals. Those defined the characteristics of the product processes and "who is the customer".
The interference came about in two ways. First, there was always a desire for products to work together. In these stories I talked about Exchange + Outlook/Word, SharePoint + Windows Server, Office VBA + Developer tools, Excel + Databases, and on and on. There are many pointed stories about working across groups. The challenges with these always came down to execution. Who was going to finish first and was that schedule reliable. I told many stories of Exchange server missing dates—there are three posts on trying to add something called the "Local Store" to Outlook. It was messy. These are the stories of efforts we made, but for each one there were probably 10 projects we didn't even attempt which always upset one group and relieved another. The decisions were that "force" that prevented cross group efforts.
Second, while related to execution there was always present a dynamic of "just one more thing". In other words even if groups were working together, perhaps successfully, as the products together came into focus so did the limitations of what was done. An example I shared was how well the developer division and Office worked together on VBA. But just as that was solid and deployed (through Office 2000) it became clear we ALSO needed to support VBA.NET. But that just was well outside the scope of what Office customers needed or wanted. It was far more strategy than it was solving any problem and it came with a lot of downsides, not to mention super impossible problems to solve (like converting code) and that assumed execution which did not ultimately happen. This idea of "one more thing" also came up quite often from the enterprise sales force or marketing. The basic problem was always "thank you that is great but in order to sell/demo/get credit we need this one more feature".
My view was always that one more feature never ever made the difference between something that was successful in the market. Or said another way, if you assume the features of a product are somewhat randomly chosen then simply adding more randomly chosen features when the product is trying to finish can't really move the needle. These were always very tense conversations because a) the product was done and b) the person/team asking really believed that one more thing would really change the whole landscape. One story that did not make it was a huge series of meetings over trying to integrate Windows File Servers and SharePoint. WFS added "UNDELETE" as a server feature and exposed it in an update to the Windows Explorer. SharePoint had its own undelete relying on the underlying implementation in a SQL database. But Windows really wanted it to use the new Server implementation. It was portrayed as SharePoint "undermining" the Server implementation and message. There were hundreds of discussions like that over the years but this one was particularly acrimonious. Office using the Windows file open dialog was another one like this. So many.
So that's some thoughts on insulating teams :-) Thank you!
Thanks for such a thoughtful response. You’ve covered a lot of ground in an amazingly concise way, and everything you've touched on resonates strongly. I find the tension between local and global objectives that are inherent in any organisation greater than a single team interesting, not least because there is no right answer. Local and global objectives frequently conflict, and finding an “optimum” way that considers both is a journey that never ends. It usually comes down to whether teams at the local and global levels are working together to find the best path forward, or doing the opposite (local teams ignoring global imperatives, and global teams ignoring local needs). Like most things that matter, that is ultimately a question of culture, which (ditto) is ultimately a question of leadership. Which brings us full circle :)
[[ BillG expressed frustration at “another release of Office that relies on Windows to make it exciting,” which honestly didn’t make much sense and bordered on insulting. ]]
With respect to Walt making a big deal out of Smart Tages in IE, i.e. "In effect, Microsoft will be able, through the browser, to re-edit anybody’s site, without the owner’s knowledge or permission", I disagreed and emailed him at the time explaining that he had just weeks before promoted software that blocked ads, modifying the site owner's intent.
His answer was, "I can see the inconsistency, but I think my idea of what is good for the user is correct in both these cases".
This, of course, did not answer his stated concern for site owners, who, like the WSJ, present ads as part of their revenue structure. Oh well.
Lots of familiar names and features in this installment. Template Gallery was such a novel idea, so was the Assistance Center then. Great to see JeffO front and center. Thank you.
The Crabby Office Lady represented a sea change for me. Being the "ineffectual, middle-management suckup" that I was, when I saw and read the first column(s), I was initially alarmed that we had published something with such an unprofessional and sassy tone, so I asked Shelley Benson (who ran the content team) about it. She immediately presented live data and feedback from customers who had read Crabby's column and who were overwhelmingly positive toward it--and toward Microsoft as well. Comments such as "at last, Microsoft puts on its human face" and the like were common. And the satisfaction ratings were unambiguous. Crabby was beloved! So I grew a spine and backed off. Through the years, this became one of my canonical anecdotes for the power of direct customer feedback. And a note on Steven as a manager: throughout this time, I do not recall any drama happening between him and HR over Crabby. That's because he insulated his teams from most of the BS that happens in large orgs. My life at work always seemed so much simpler than my peers in other divisions. I used to wonder what they were doing wrong, when really it was all about what Steven was doing right. Respect!
Thank you 🙏
Something that comes across very clearly by its prominent absence from everything that Steven discusses is the enormous complexity of successfully running teams that are as (very) large as the ones Steven managed. It's so very apparent that he was (is) extremely accomplished at it simply because of his continued rather stratospheric rise throughout the story, yet he never discusses the challenges except as they relate to the story of Microsoft itself. It's such an intrinsic part of shipping anything at this scale that I'd love to read his thoughts on what he did that worked so well. (Perhaps that's discussed in later chapters?) For what it's worth, based in what Steven has written, I have assumed essentially what you have observed regarding Steven explicitly insulating his teams from distracting organisational BS so that they could just get on and do their job. That's my idea of a leader :)
Thank you for reading so closely. I definitely appreciate this observation. I wanted to offer a couple of thoughts.
A quick answer might be "you have no idea!" meaning yes this was a big part of the job and generally most people had no idea how much of the job was that. But I don't like that answer and don't like the way it makes the whole experience sound. While it is true it is also a cultural attribute.
Many people love to talk about the org charts of tech companies (https://www.businessinsider.com/big-tech-org-charts-2011-6). I've written about that elsewhere specifically how much I dislike the way it portrays things. Interference means you are against cross-group collaboration and cross-group is ALWAYS good so to be against it means ALWAYS bad.
The culture at Microsoft that caused so much "interference" that ends up getting depicted as above is precisely because the company did not have a centralized command and control of the product strategy combined with (esp in the 1990-2010 period) any reliable execution for any one group. In other words we didn't have a centralized command and control strategy AND even if we did we lacked execution to deliver on the connections between groups. The first part was by design and the second part caused much of the tension.
Many believe companies should have a single strategy and execute. This works at small scale and it works at large scale for one business. But Microsoft was a portfolio of businesses and although they were related they also served wildly different customers and business models. Only when a subset of products came together at the enterprise customer level did it seem like we had one customer. Even then, however, products like Windows were used in the enterprise but the primary business was to PC makers; a product like Office was used by individuals and teams and almost always purchased by business. These are inherent conflicts of scale. For the first decade of Windows it was exclusively an OEM product. Office was almost exclusively a product purchased by individuals. Those defined the characteristics of the product processes and "who is the customer".
The interference came about in two ways. First, there was always a desire for products to work together. In these stories I talked about Exchange + Outlook/Word, SharePoint + Windows Server, Office VBA + Developer tools, Excel + Databases, and on and on. There are many pointed stories about working across groups. The challenges with these always came down to execution. Who was going to finish first and was that schedule reliable. I told many stories of Exchange server missing dates—there are three posts on trying to add something called the "Local Store" to Outlook. It was messy. These are the stories of efforts we made, but for each one there were probably 10 projects we didn't even attempt which always upset one group and relieved another. The decisions were that "force" that prevented cross group efforts.
Second, while related to execution there was always present a dynamic of "just one more thing". In other words even if groups were working together, perhaps successfully, as the products together came into focus so did the limitations of what was done. An example I shared was how well the developer division and Office worked together on VBA. But just as that was solid and deployed (through Office 2000) it became clear we ALSO needed to support VBA.NET. But that just was well outside the scope of what Office customers needed or wanted. It was far more strategy than it was solving any problem and it came with a lot of downsides, not to mention super impossible problems to solve (like converting code) and that assumed execution which did not ultimately happen. This idea of "one more thing" also came up quite often from the enterprise sales force or marketing. The basic problem was always "thank you that is great but in order to sell/demo/get credit we need this one more feature".
My view was always that one more feature never ever made the difference between something that was successful in the market. Or said another way, if you assume the features of a product are somewhat randomly chosen then simply adding more randomly chosen features when the product is trying to finish can't really move the needle. These were always very tense conversations because a) the product was done and b) the person/team asking really believed that one more thing would really change the whole landscape. One story that did not make it was a huge series of meetings over trying to integrate Windows File Servers and SharePoint. WFS added "UNDELETE" as a server feature and exposed it in an update to the Windows Explorer. SharePoint had its own undelete relying on the underlying implementation in a SQL database. But Windows really wanted it to use the new Server implementation. It was portrayed as SharePoint "undermining" the Server implementation and message. There were hundreds of discussions like that over the years but this one was particularly acrimonious. Office using the Windows file open dialog was another one like this. So many.
So that's some thoughts on insulating teams :-) Thank you!
Thanks for such a thoughtful response. You’ve covered a lot of ground in an amazingly concise way, and everything you've touched on resonates strongly. I find the tension between local and global objectives that are inherent in any organisation greater than a single team interesting, not least because there is no right answer. Local and global objectives frequently conflict, and finding an “optimum” way that considers both is a journey that never ends. It usually comes down to whether teams at the local and global levels are working together to find the best path forward, or doing the opposite (local teams ignoring global imperatives, and global teams ignoring local needs). Like most things that matter, that is ultimately a question of culture, which (ditto) is ultimately a question of leadership. Which brings us full circle :)
[[ BillG expressed frustration at “another release of Office that relies on Windows to make it exciting,” which honestly didn’t make much sense and bordered on insulting. ]]
Oh, I think it was well across the border.
That launch video recalls the cringe I winced watching that overly aggressive high-five between you and SteveB. It still looks painful. 😟
Ha!
With respect to Walt making a big deal out of Smart Tages in IE, i.e. "In effect, Microsoft will be able, through the browser, to re-edit anybody’s site, without the owner’s knowledge or permission", I disagreed and emailed him at the time explaining that he had just weeks before promoted software that blocked ads, modifying the site owner's intent.
His answer was, "I can see the inconsistency, but I think my idea of what is good for the user is correct in both these cases".
This, of course, did not answer his stated concern for site owners, who, like the WSJ, present ads as part of their revenue structure. Oh well.
Lots of familiar names and features in this installment. Template Gallery was such a novel idea, so was the Assistance Center then. Great to see JeffO front and center. Thank you.