A couple of observations derived from my own writing tailored to yours:
Coming to Microsoft, I was incredibly disappointed to find myself in endless discussions about a culturally overused term I would grow to loath - "funding".
The use of the word "funding" was isomorphic to "headcount" in every discussion I had at MSFT. It felt like the company, or at least DevDiv, decided to use the word "funding" to avoid the appearance of being headcount obsessed about "headcount", as if no one would notice the zero delta between the two usages. So, we never talked about customers, or business cases but were happy to talk and argue endlessly about "funding".
At every company I've been a leader for other than Microsoft and Amazon, the normal order of things is to discuss customers, then the business case around providing products and services to those customers, then the sets of more specific things we need to build to attract and retain those customers, and then what features are required in a particular release for those customers, and finally a prioritization of deliverables is created. Then, and only then, did we do the costing analysis and resource allocation discussions required for a release. So, head count discussions always occurred at the end, though to start we might have constraints around them as input to the above, depending on the situation (no new heads this year, etc.).
At MSFT, I quickly noticed that business cases were almost never discussed in the prioritization of these things. So, I injected it, as I had every other company where I had led teams. For example, in working on Win8, we were allocating "funding" to something having to do with what I remember being called the "Modern App model" packaging in VS.
Everything seemed set until a manager from a Windows team who provided one component to us said he couldn't commit to the schedule because he was short "funding" for two "resources" to test his component. This was in a room with ScottGu, JasonZ, and AlesH. No one said anything, so I asked, "Your org (doing a quick HeadTrax check) has 250 people in it. You're saying that your GM will hold up the entire Win8 schedule and Microsoft will miss Christmas of 2012 for our largest revenue business and thousands of people cannot deliver on time because out of your GM's 250 people you can't find two testers?".
Embarrassed, the guy said, "never mind... we'll assign them to this and drop something else". I had many conversations at MSFT where I reduced this tension using the same technique. I came to notice that across the company, there were more conversations about "funding" than about "customers". When I sometimes say to you that customer obsession seemed lacking at MSFT compared to my other companies, this is an example of what I am referring to. But MSFT is not alone on this dynamic.
When I went to AMZN, I encountered the same dynamic again. And again. There, they did not sugar coat it. Discussions about headcount were up front before business case and customer discussions, and never ending throughout the release cycle. In fact, the acronym for it – “HC” – is one of the most-used terms in most of our docs. I know, I liked to create a term index of docs before I read them to get an idea of how HC-focused the docs would be.
Usually, I found that someone had not done a deep enough dive into what needed to be done and why rather than "how many heads" one needed to do something. This was disappointing. At least at AMZN, you could shame people out of their HC focus by saying you wanted to hear more or first about what they were doing for customers rather than what HC they wanted.
At both MSFT and AMZN, I got both of my own orgs to focus less on headcount and more on business case (revenue and OpEx) and customers. This took a bit of training and was a hard habit to break. If I read you correctly, you did this by “simply” (it could not have been if my endless, cross-company discussions at MSFT about “funding” were any indication) removing headcount from the equation after entering release milestones or entire releases, using freezing it at the beginning as an explicit tenet of your process. I like it. That's probably where I landed, but I could have been more explicit about it to everybody's benefit for products like AutoCAD 15, 16, etc.
Your tenet about planning with the resources you start with for version N+1 products like Office and Windows is a pretty great tenet. In our case for Amazon Business and many other new initiatives at Amazon, we were creating version one, which required 200 people, starting with 20 people taken from Amazon Supply which we shut down. There'd be no Echo today if we followed that tenet.
I wonder if this HC obsession at AMZN and "funding" at MSFT is just part of the natural tendency of large companies to become bureaucratic, without the proper leadership principles or tenets to regulate it. The “frugality” LP at AMZN doesn’t help much with this issue, though I gathered from long-time Amazonians on the S-team that it did serve as a regulator for this behavior in the first 15 years there.
Every Sunday, I am eagerly awaiting the next chapter in my email inbox.
Unfortunately, here in Switzerland, this is around 6pm. Basically exactly when my "free weekend reading time slot" is over. Very often, due to busy weeks, I only get around to reading a chapter towards the end of the week, or the next weekend.
If the new chapters were released just 9 hours or so earlier on Sundays, I (and probably a lot of fellow European readers) would have an entire Sunday available to read. :-)
Do you think an earlier release would be possible?
I am so flattered by what you said. It means a great deal that you commit your time to reading and on such a regular basis.
I've played around with publication times and watched the "open rate." Saturday, which is 9 hours earlier on west coast USA does not seem to fit well for US subscribers, most of whom are west coast. Later in the day on Sunday does not work well for east coast US as it is after the midday break.
So I guess I'm sort of stuck with this time. I recognize it is not optimal for the subscribers on GMT and thereabouts, which I am so sorry. Unfortunately there are subscribers all around the world (which isn't unfortunate of course but not ideal for everyone). As with most time zone issues, it is not possible to find an awake time for everyone.
The good news is the posts don't go anywhere and so you can always read at your convenience. Since it is history, things won't change.
Sorry this isn't ideal. My apologies. I do thank you so much for your support.
I understand that it is very difficult to cater for all time zones. There are always compromises to make. And it also makes sense to prioritize the time zones where most of the readers live. And yes, as you say, it's history, and "things won't change". So I will manage. :-)
But to be fully honest, I was not able to follow your arguments as to why releasing 9h earlier (=Sunday around 7am UTC) would be a problem for the US readers. ;)
Fascinating! (A tiny nit: "coincidently" and "coincidentally" are two different words. I believe that you used "coincidently" when you meant "coincidentally", and damn Word didn't catch it.)
Thank you! This wisdom from the trenches is amazing to read, looking forward to the rest of this story... (Just a small typo nit: I think “seems small-ish” should be “seem small-ish”?)
A couple of observations derived from my own writing tailored to yours:
Coming to Microsoft, I was incredibly disappointed to find myself in endless discussions about a culturally overused term I would grow to loath - "funding".
The use of the word "funding" was isomorphic to "headcount" in every discussion I had at MSFT. It felt like the company, or at least DevDiv, decided to use the word "funding" to avoid the appearance of being headcount obsessed about "headcount", as if no one would notice the zero delta between the two usages. So, we never talked about customers, or business cases but were happy to talk and argue endlessly about "funding".
At every company I've been a leader for other than Microsoft and Amazon, the normal order of things is to discuss customers, then the business case around providing products and services to those customers, then the sets of more specific things we need to build to attract and retain those customers, and then what features are required in a particular release for those customers, and finally a prioritization of deliverables is created. Then, and only then, did we do the costing analysis and resource allocation discussions required for a release. So, head count discussions always occurred at the end, though to start we might have constraints around them as input to the above, depending on the situation (no new heads this year, etc.).
At MSFT, I quickly noticed that business cases were almost never discussed in the prioritization of these things. So, I injected it, as I had every other company where I had led teams. For example, in working on Win8, we were allocating "funding" to something having to do with what I remember being called the "Modern App model" packaging in VS.
Everything seemed set until a manager from a Windows team who provided one component to us said he couldn't commit to the schedule because he was short "funding" for two "resources" to test his component. This was in a room with ScottGu, JasonZ, and AlesH. No one said anything, so I asked, "Your org (doing a quick HeadTrax check) has 250 people in it. You're saying that your GM will hold up the entire Win8 schedule and Microsoft will miss Christmas of 2012 for our largest revenue business and thousands of people cannot deliver on time because out of your GM's 250 people you can't find two testers?".
Embarrassed, the guy said, "never mind... we'll assign them to this and drop something else". I had many conversations at MSFT where I reduced this tension using the same technique. I came to notice that across the company, there were more conversations about "funding" than about "customers". When I sometimes say to you that customer obsession seemed lacking at MSFT compared to my other companies, this is an example of what I am referring to. But MSFT is not alone on this dynamic.
When I went to AMZN, I encountered the same dynamic again. And again. There, they did not sugar coat it. Discussions about headcount were up front before business case and customer discussions, and never ending throughout the release cycle. In fact, the acronym for it – “HC” – is one of the most-used terms in most of our docs. I know, I liked to create a term index of docs before I read them to get an idea of how HC-focused the docs would be.
Usually, I found that someone had not done a deep enough dive into what needed to be done and why rather than "how many heads" one needed to do something. This was disappointing. At least at AMZN, you could shame people out of their HC focus by saying you wanted to hear more or first about what they were doing for customers rather than what HC they wanted.
At both MSFT and AMZN, I got both of my own orgs to focus less on headcount and more on business case (revenue and OpEx) and customers. This took a bit of training and was a hard habit to break. If I read you correctly, you did this by “simply” (it could not have been if my endless, cross-company discussions at MSFT about “funding” were any indication) removing headcount from the equation after entering release milestones or entire releases, using freezing it at the beginning as an explicit tenet of your process. I like it. That's probably where I landed, but I could have been more explicit about it to everybody's benefit for products like AutoCAD 15, 16, etc.
Your tenet about planning with the resources you start with for version N+1 products like Office and Windows is a pretty great tenet. In our case for Amazon Business and many other new initiatives at Amazon, we were creating version one, which required 200 people, starting with 20 people taken from Amazon Supply which we shut down. There'd be no Echo today if we followed that tenet.
I wonder if this HC obsession at AMZN and "funding" at MSFT is just part of the natural tendency of large companies to become bureaucratic, without the proper leadership principles or tenets to regulate it. The “frugality” LP at AMZN doesn’t help much with this issue, though I gathered from long-time Amazonians on the S-team that it did serve as a regulator for this behavior in the first 15 years there.
Hi Steven!
Every Sunday, I am eagerly awaiting the next chapter in my email inbox.
Unfortunately, here in Switzerland, this is around 6pm. Basically exactly when my "free weekend reading time slot" is over. Very often, due to busy weeks, I only get around to reading a chapter towards the end of the week, or the next weekend.
If the new chapters were released just 9 hours or so earlier on Sundays, I (and probably a lot of fellow European readers) would have an entire Sunday available to read. :-)
Do you think an earlier release would be possible?
Hello Michael,
I am so flattered by what you said. It means a great deal that you commit your time to reading and on such a regular basis.
I've played around with publication times and watched the "open rate." Saturday, which is 9 hours earlier on west coast USA does not seem to fit well for US subscribers, most of whom are west coast. Later in the day on Sunday does not work well for east coast US as it is after the midday break.
So I guess I'm sort of stuck with this time. I recognize it is not optimal for the subscribers on GMT and thereabouts, which I am so sorry. Unfortunately there are subscribers all around the world (which isn't unfortunate of course but not ideal for everyone). As with most time zone issues, it is not possible to find an awake time for everyone.
The good news is the posts don't go anywhere and so you can always read at your convenience. Since it is history, things won't change.
Sorry this isn't ideal. My apologies. I do thank you so much for your support.
Steven
Hi Steven
Thanks for your reply!
I understand that it is very difficult to cater for all time zones. There are always compromises to make. And it also makes sense to prioritize the time zones where most of the readers live. And yes, as you say, it's history, and "things won't change". So I will manage. :-)
But to be fully honest, I was not able to follow your arguments as to why releasing 9h earlier (=Sunday around 7am UTC) would be a problem for the US readers. ;)
Cheers
Michael
Fascinating! (A tiny nit: "coincidently" and "coincidentally" are two different words. I believe that you used "coincidently" when you meant "coincidentally", and damn Word didn't catch it.)
Thank you! I will fix shortly.
Thank you! This wisdom from the trenches is amazing to read, looking forward to the rest of this story... (Just a small typo nit: I think “seems small-ish” should be “seem small-ish”?)