What a fascinating idea. I suppose if you don't know whether you're going the right direction you might as well try to get there as fast a possible.
I worked for a while with a bunch of former video game developers at a non-game company. They got an amazing amount of work done, but they also just did what they wanted without discussing it. They just assumed that everybody would naturally agree with them so they didn't see any problem with sending a note to the rest of the team that said, "We've changed the signature of most of the UI method calls. The build now has 5,000 errors. Please make changes to your code."
Given the PayPal story, which started with the company being encryption software to beam money between Palm Pilots, that couldn't possibly be what Max meant. They definitely didn't "know whether [they were] going in the right direction."
What he means, I think, is that at an early stage startup the cost of coordination is very high. When you have 5 people working together you almost want a hive mind. If part of everyone's mutual understanding includes how, when, and why to change course then the cost of potentially sticking with the wrong thing for too long is far outweighed by the cost of coordination.
Your example is the opposite of what I take him to mean, viz., in a small team where everyone understands how to operate independently and has a deep, mutual understanding then nobody's going to introduce a breaking change that leaves the other 4 people flat footed at a critical time.
He's putting his own cognitive narrative on a singular event. A few things change (they dont connect with elon, they dont give up on the palm pilot as a focus, etc) and the story ends radically different, to negative effect. Truth is, sometimes, if you bust your ass in the right place at the right time, shit goes marvelously to your favor. Or not. Either way.
> We've changed the signature of most of the UI method calls. The build now has 5,000 errors. Please make changes to your code.
I feel a build should actually compile before committing changes. If you make a change that create 5000 build errors, you better get to fixing 'em or revert that change.
What a fascinating idea. I suppose if you don't know whether you're going the right direction you might as well try to get there as fast a possible.
I worked for a while with a bunch of former video game developers at a non-game company. They got an amazing amount of work done, but they also just did what they wanted without discussing it. They just assumed that everybody would naturally agree with them so they didn't see any problem with sending a note to the rest of the team that said, "We've changed the signature of most of the UI method calls. The build now has 5,000 errors. Please make changes to your code."