Comment by seanhunter
5 days ago
This is a great example of persuasive, but superficial, analysis.
1) It may well be a dumb thing they do, but is this really "why big companies keep failing?" There's no real examination of this causal assertion which seems central.
2) Is it really the "stack"? That is to say, do people really assume that just the layer above them is trivial? I see engineers all the time assume that basically everything they don't understand is trivial. For example Elon Musk's famous assertion that the hyperloop is "Basically just like an air hockey table. It's not that hard". Well in turns out air hockey pucks don't need to transport people, g-forces aren't important for air hockey versus not murdering your passengers is quite important for a public transport system. Air hockey pucks don't need to breathe versus people do which makes the vacuum part quite critical and challenging especially since you have to figure out how to get people in and out without rupture. To think of it as like air hockey you are assuming that all interesting/challenging parts of the problem are trivial. To be clear: I think that this hubris is basically essential for innovation. I really don't think people would ever innovate if they worried too much about every small detail of things, but this is why a large proportion of experiments by everyone (big and small companies alike) fail. I don't think the layer above you in the stack is the important part here and the article doesn't examine whether that characteristic is important.
Your point 2 is interesting, but Musk isn’t any type of engineer really, just a money guy that uses engineer words. It seems more likely that he assumes a Hyperloop would be trivial not because it is a simple application of some lower framework that he’s got a deep understanding of, but because he hasn’t been given an itemized bill for one.
Musk used to be seen as an engineer. He co-founded a payments company that merged with PayPal (not sure if he did engineering, though). I believe he is widely seen as being a knowledgeable rocketry engineer. I also think that he contributed to engineering of early Teslas. Now he is completely over-committed, and seems to me like he is burnt-out but does not realize it, and is doing all sorts of crazy things which act to sort of paper that over. Twenty years ago he was seen as a high-level engineer (I've heard that Marvel's Tony Stark was based on Musk [I mean, obviously it was based on the comic book character, but hopefully you know what I mean]).
He co-founded a payments company - he certainly wasn't an engineer. He was fired and given a golden parachute from Paypal for his incompetent insistence that they stop all software development at PayPal for a year so that they could move off Linux and move to fully hosting on Windows NT servers (!). He was a manager and money guy from the start, he never was a software engineer or any kind of engineer.
I guess based on all the phrases like “used to” and “seen as,” you’d agree that these perceptions were never really all that realistic, right? He had better PR in the past for sure, but it was always just a PR thing. That makes his behavior a bad example of something engineers do.
We’ve got plenty of smug actual engineers, we don’t need to take blame for some cosplayer’s bad behavior.
I think you are criticizing an idea for not being a study. I think it's a reasonable and interesting idea, but at most it is something to consider, not some infallible axiom. More akin to "the Peter Principle" than a theorem.
Point 2 is... neither important nor really germane. (I don't care what engineers say, and Musk isn't an engineer anyway.) The point is that people understand their customer bases, and sell to them, and then imagine that means they understand how to succeed in the business their customers are in, and... not so.
It's basically a reminder that understanding the customer is everything. No matter how good the tech is, if you don't solve the customer's problem... they aren't buying.
Yes, when I wrote this article - I was pointing out that we seem to have missed this rather common pattern. And if you understand this pattern you can avoid some strategy mistakes.
I didn't claim that this one pattern explains all of the failures.
It's an interesting idea, but I don't think you explore it adequately. Firstly you don't even establish it's a mistake in the majority of cases - you just list some instances where it was a mistake. So "understanding this pattern" and trying to avoid strategy mistakes could be an even bigger mistake than not.