Nice read but falls into a vast reductionist trap, a lot of survivorship bias dressed up as design philosophy or strategic bets. The context of decisions made decades ago != now, people were working under different constraints etc. Trying to frame the avionics example as the "subtractive" innovation is the most egregious, transistors were over 1000x times smaller, weight wasn't even a consideration.
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.
I think Clearmotion has a very interesting technology and product (ride stabilization), but let's paint a full picture here: the company was founded in 2009, took on $370 million in funding, and only recently landed large contracts (a $1 billion dollar deal in 2023 with Chinese auto manufacturer, Nio).
I'm sure they were in a constant struggle for survival and had to "move fast" to stay afloat, but their technology is more than a decade in the making.
I'm mostly curious how much of that revenue is actual ARR, which is to say contractually recurring. It is pretty dang rare for a hardware company to have nontrivial ARR.
automotive contracts are typically on 6 year cycles, so tech gets designed into a new car and it's locked in until the next vehicle generation (5-7 years depending on the automaker). year to year sales can fluctuate but are fairly predictable.
Outsource the mature, insource the uncertain is very true. A lot of startups outsource precisely the part of the system they understand least, but that is oftentimes the worst possible decision.
Can someone in plain English please tell us what this company does? I just see one anecdote after another that’s scattered with feel-good whodathunkit babble. I was anticipating the airplane holes analogy, but maybe I got lucky and missed it.
Depends on how much funding you have, your target audience, target vertical, and how custom your hardware is, no? There can only be so many things you can cut and optimize.
According to the draft Wikipedia article for this company that hasn't been published because it is not yet considered sufficiently noteworthy, this company has existed for 17 years, built their first production facility in 2023, and first delivered working units into real cars last March. That doesn't strike me as moving all that fast. It also says they acquired the Bose product they're shitting on in this article for doing things wrong.
If it works, it works, but I really wish companies and founders would just be honest about how and why they succeed when they do, instead of everything needing to be the constant projection of a desired image.
Nice read but falls into a vast reductionist trap, a lot of survivorship bias dressed up as design philosophy or strategic bets. The context of decisions made decades ago != now, people were working under different constraints etc. Trying to frame the avionics example as the "subtractive" innovation is the most egregious, transistors were over 1000x times smaller, weight wasn't even a consideration.
> a lot of survivorship bias dressed up as design philosophy or strategic bets
I wish more people realized this
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.
I think Clearmotion has a very interesting technology and product (ride stabilization), but let's paint a full picture here: the company was founded in 2009, took on $370 million in funding, and only recently landed large contracts (a $1 billion dollar deal in 2023 with Chinese auto manufacturer, Nio).
I'm sure they were in a constant struggle for survival and had to "move fast" to stay afloat, but their technology is more than a decade in the making.
I think the super long timelines in automotive make it really hard to succeed. Really impressed with what ClearMotion accomplished given that
Just when I think I cannot see more emdashes, there are more emdashes.
As a human emdash enjoyer, I'm pretty damn grumpy that everyone assumes I'm a chatbot now. :P
Could anyone recommend the same for a software startup? (Lessons learned, mistakes to avoid etc)
I'm mostly curious how much of that revenue is actual ARR, which is to say contractually recurring. It is pretty dang rare for a hardware company to have nontrivial ARR.
automotive contracts are typically on 6 year cycles, so tech gets designed into a new car and it's locked in until the next vehicle generation (5-7 years depending on the automaker). year to year sales can fluctuate but are fairly predictable.
Outsource the mature, insource the uncertain is very true. A lot of startups outsource precisely the part of the system they understand least, but that is oftentimes the worst possible decision.
Can someone in plain English please tell us what this company does? I just see one anecdote after another that’s scattered with feel-good whodathunkit babble. I was anticipating the airplane holes analogy, but maybe I got lucky and missed it.
"ClearMotion, a company developing automotive robotics that stabilize vehicle ride and handling"
Thank you!
[dead]
Optimizing for learning/iteration speed is a solid approach that applies just as much to software development.
Depends on how much funding you have, your target audience, target vertical, and how custom your hardware is, no? There can only be so many things you can cut and optimize.
According to the draft Wikipedia article for this company that hasn't been published because it is not yet considered sufficiently noteworthy, this company has existed for 17 years, built their first production facility in 2023, and first delivered working units into real cars last March. That doesn't strike me as moving all that fast. It also says they acquired the Bose product they're shitting on in this article for doing things wrong.
If it works, it works, but I really wish companies and founders would just be honest about how and why they succeed when they do, instead of everything needing to be the constant projection of a desired image.
Yup this reads like post hoc revisionist marketing content rather than an engineers diary
https://www.youtube.com/watch?v=lgKGIhfKrpY&t=301s
[dead]