Imagine a high-dimensional space with a bunch of variables related to organizations (e.g. "move fast and break things" vs. "move slowly with high quality"; "hire quickly, fire quickly" vs. "hire slowly, rarely need to fire"; "top down" vs. "flat hierarchy").
Probably there are some variables where it's relatively clear that it's better to be on one side of the tradeoff than the other. E.g. "setting clear goals" is probably relatively clearly good.
But I think that overall there's not a clear single peak in this space: rather there are particular clusters of traits that go well together and produce success. Because of the last paragraph, these traits might be clustered on a particular side of some dimension. But there will be many dimensions where successful organizations are all over the map.
So now you're getting advice from a successful person. They built their success on a hill in the top right (on some pair of dimensions). So they tell you to move upwards.
But actually, you're on the side of a pretty nice hill in the bottom left, and moving upwards will make things worse.
You could try to move the organization all the way to the top right in one big leap, but you'll probably fail, and it may not be any better than climbing your local hill.
I think this partly explains why advice is often not that useful (if you're pretty deeply focused on a project/organization).
I suspect something similar applies to people also (where the variables are more things like "how much of my day should I spend in meetings?" or "What sort of skills should I be trying to develop?").
(Probably someone else has had this idea before - if I stole it, I forgot that I did so.)
Interesting. Could you say more why you believe that there are clusters of traits that go well together?
The main example that comes to my mind is that people have different personalities and preferences, so if your team clusters around a set of certain personality traits and preferences, that implies that some specific organizational design choices work better than others.
But I'd feel more reluctant to say things like "move fast and break things works well with hiring quickly"; I find it hard to see any obvious hills based on the variables you mentioned.
I would have said something more like: Which strategy is best will depend on the specifics of what you're trying to do (market, product, goals).
Sure, I should have given examples from the start! I also agree that some of this is about adapting to the market etc.
Also, I think that your point about personality traits /preferences covers a fair few examples: e.g. some orgs choose to have a critical feedback culture, and hire people who respond well to very critical feedback (e.g. Bridgewater).
Some other examples:
"Hire aligned people" goes well with "have relatively loose HR policies (expenses, budgets etc.)"; "Hire unaligned people and incentivise them with money" goes better with "have somewhat tighter HR policies (firing, expenses etc.)". I think there are companies that have done well with each approach.
"Pay at the very top of the market" maybe goes well with "set very high standards and fire quickly"; "pay in the middle of the market" goes well with having somewhat lower standards. My impression is that Netflix is trying particularly hard to be in the first bucket here, and then there are other tech companies that are less extremely in that bucket.
I think "Move fast and break things" goes well with "have very short iteration cycles, so that you quickly fix the things you broke" (e.g. Facebook), and "move slowly with high quality" goes better with a more waterfall-based approach to development (maybe older/more established tech companies, as well as a bunch of others). This example is clearly partly about the product you're building, but I could imagine competitors in some markets choosing different paths here.
I agree with those examples!
(Maybe I feel somewhat skeptical about 'move slowly with high quality' ever being a good choice – it seems to me that the quality/speed tradeoff is often overstated, and there's actually not that much of a tradeoff.)
Move slowly with high quality makes more sense for people whose "product" is not optional, eg monopolies or public services.
You really don't want your water provider to upgrade quickly if it increases the chance you won't have water at all for a month.
Yeah, I am also skeptical of that, so maybe that's a bad example.
I can conjure examples (e.g. shipping a physical product) where you want to move slower with very high quality, because it's hard to iterate. But I think that when you open up "move slower with high quality", it's going to normally look like rapid, messy iteration on what the product is, the production line etc.