There are two important elements to Bill's management style. He was deeply interested in how things worked in the products, and set the tone that managers needed to know how things worked. That was a huge strength of Microsoft's management team (and a weakness when people lacked the human aspects of managing) and critical to Microsoft being able to do all of the things it did. The company lost this to a degree along the turn of the century and it resulted in several project failures.
Bill also, as Steven wrote, would purposely drive conversations and challenge people in order to find the weak spots. He was sometimes brutal on a personal level when doing so. However, these discussions were often valuable. Bill did not have to know the answer. These discussions often drove substantial follow up that developed valuable insights. In addition he was good about having the discussions not break the delegation barrier. He wasn't telling people what to do, he was telling people he didn't think they had thought something through. Sometimes that was a painful discussion. Sometimes that was a waste of time. But also sometimes it was super valuable (Bill term) and really helped those of us working on the products.
One (obvious) observation from my time at Microsoft is that there was always a strong, top-down push for early (some might say premature ...) dependencies and code re-use. One of many problems with Longhorn.
Interestingly, at Facebook there was never any top-down push for code re-use. Over nearly a decade, I rarely saw a classic Microsoft-style architecture diagram in an exec review (the only exception was new Microsoft hires who were still adapting). No exec ever asked if a team was using the latest-and-greatest internal framework.
But – in my opinion – there was far less code duplication at Facebook than at Microsoft. Code unification/clean-up was a constant, bottoms-up effort from various teams (e.g., the Product Infrastructure team). Projects like GraphQL, React, React Native, etc. were entirely organic, bottoms-up efforts.
I've never been able to fully explain the difference. There was clearly a confluence of factors:
- A single, always up-to-date codebase (easier to reuse code)
- A culture that primarily optimized for speed of execution
- Daily releases (vs. multi-year releases with discrete RTMs)
- A culture that celebrated engineers improving core abstractions
- Etc.
But I can't help but wonder to what extent Bill's constant pushing on this issue actually worsened it, e.g.:
- Bill would detect some area of duplication
- He would push some team to create a framework to unify the thing
- He would push other teams to take a premature dependency on that framework
- Dependent teams would be burned and learn to avoid future dependencies at all costs (real artists ship)
- The cycle would repeat
Certainly one of the unspoken lessons I learned at Microsoft was that you were crazy to take a dependency on any piece of code that hadn't shipped yet.
It feels like a cautionary tale in the exertion of power – the harder you push, the worse you make it.
I'd be curious to get your take on how BillG himself honed his management muscle—both to enable an organization that reached such scales (even in these days and then beyond), but also in spite of it as well. This is pretty remarkable in its own right. Future post?
I see Vern Rayburn in that video. It would be great to hear more about the contributions of others like him who may not be so well known. I met him while I headed the apps group at GO, when he started Slate. I thought he was just a brilliant guy, with one of the reasons being that he didn't drink the KoolAid about the Penpoint OS, and asked questions that we should have been asking ourselves but had too much hubris to ask.
There are two important elements to Bill's management style. He was deeply interested in how things worked in the products, and set the tone that managers needed to know how things worked. That was a huge strength of Microsoft's management team (and a weakness when people lacked the human aspects of managing) and critical to Microsoft being able to do all of the things it did. The company lost this to a degree along the turn of the century and it resulted in several project failures.
Bill also, as Steven wrote, would purposely drive conversations and challenge people in order to find the weak spots. He was sometimes brutal on a personal level when doing so. However, these discussions were often valuable. Bill did not have to know the answer. These discussions often drove substantial follow up that developed valuable insights. In addition he was good about having the discussions not break the delegation barrier. He wasn't telling people what to do, he was telling people he didn't think they had thought something through. Sometimes that was a painful discussion. Sometimes that was a waste of time. But also sometimes it was super valuable (Bill term) and really helped those of us working on the products.
These are a joy to read. Thank you!
One (obvious) observation from my time at Microsoft is that there was always a strong, top-down push for early (some might say premature ...) dependencies and code re-use. One of many problems with Longhorn.
Interestingly, at Facebook there was never any top-down push for code re-use. Over nearly a decade, I rarely saw a classic Microsoft-style architecture diagram in an exec review (the only exception was new Microsoft hires who were still adapting). No exec ever asked if a team was using the latest-and-greatest internal framework.
But – in my opinion – there was far less code duplication at Facebook than at Microsoft. Code unification/clean-up was a constant, bottoms-up effort from various teams (e.g., the Product Infrastructure team). Projects like GraphQL, React, React Native, etc. were entirely organic, bottoms-up efforts.
I've never been able to fully explain the difference. There was clearly a confluence of factors:
- A single, always up-to-date codebase (easier to reuse code)
- A culture that primarily optimized for speed of execution
- Daily releases (vs. multi-year releases with discrete RTMs)
- A culture that celebrated engineers improving core abstractions
- Etc.
But I can't help but wonder to what extent Bill's constant pushing on this issue actually worsened it, e.g.:
- Bill would detect some area of duplication
- He would push some team to create a framework to unify the thing
- He would push other teams to take a premature dependency on that framework
- Dependent teams would be burned and learn to avoid future dependencies at all costs (real artists ship)
- The cycle would repeat
Certainly one of the unspoken lessons I learned at Microsoft was that you were crazy to take a dependency on any piece of code that hadn't shipped yet.
It feels like a cautionary tale in the exertion of power – the harder you push, the worse you make it.
I'd be curious to get your take on how BillG himself honed his management muscle—both to enable an organization that reached such scales (even in these days and then beyond), but also in spite of it as well. This is pretty remarkable in its own right. Future post?
I see Vern Rayburn in that video. It would be great to hear more about the contributions of others like him who may not be so well known. I met him while I headed the apps group at GO, when he started Slate. I thought he was just a brilliant guy, with one of the reasons being that he didn't drink the KoolAid about the Penpoint OS, and asked questions that we should have been asking ourselves but had too much hubris to ask.