Fun read but a bit too much fluff? I was a design MechE for about a decade and I’m by no means as successful as the OP. But I have worked on a 5 person design team that had an annual net revenue of 30M and another job where I worked on 25M+ contract with just a team of 2, me and my mentor at the time. End of the day, hardware execution is hard and there’s a ton of product development cycle theories, you just need a culture with what I call good engineering discipline. Good communication, good documentation, and realistic milestones with accountability.
"Good documentation and realistic milestones with accountability" — this is the part that almost every post-mortem I've seen identifies as the actual failure point, not the technical decisions.
The frustrating thing is it's not mysterious. Everyone knows documentation matters. The failure mode is that it gets deprioritized the moment the team is moving fast, which is exactly when it matters most. A decision made under pressure with no record becomes a source of technical and organizational debt that compounds quietly.
The teams that scale well seem to have internalized documentation as a forcing function for clear thinking, not just a record-keeping chore. If you can't write down what you decided and why in two sentences, you probably haven't finished deciding.
That’s why I’m a huge proponent of pushing the idea of engineering discipline. And like any organization, discipline comes from the top to bottom. Coming from bottom to top is just a recipe for disaster and clear tell sign of misaligned objectives between management and the engineers.
Fluff? It is written by a chatbot.