Elon Musk does not “Aspire to Inertia”
I am a big fan of Elon Musk, the engineer, the technician, his ideas and big goals. I am less of a fan of what transpires in other areas but let’s leave that at the door!
But in a recent podcast with Lex Fridman, he talked a lot about first principles thinking and letting the desired outcome determine the tools and processes used to build the product.
First principles
In one example, he talks about how getting the price of components down to a level where they become economically viable in Space X’s rockets. The problem most potential suppliers have is that they propose a price that is based on using the same tools and processes that they already have. This always turns out to be a more expensive and less innovative result.
The companies that succeed in producing parts for Space X and Tesla are those that build, choose or design tools and processes specifically to produce the product.
If Space X built rockets using the tools and processes of NASA then instead of more advanced, more powerful, reusable and thus cheaper rockets, the result would have been another Saturn V or Space Shuttle. Likewise a Tesla could never be built with Ford’s factories and processes.
Remove the rules
Furthermore, he went on to talk later about how there are hundreds or thousands of people employed in organisations and governments whose job it is to create rules, yet none employed to remove rules! No matter how many 1000 year old laws exist allowing a man to drive his sheep through a town centre, no-one is employed to, just as aggressively, remove rules that are out of date, overly restrictive or even dangerous!
Combining these two points into a great analogy, he described how he doesn’t see how a company or design can be innovative when engineers are like Gulliver, tied down by a thousand chains.
If Elon made software
The parallels with software design and architecture are of course obvious. If an organisation wants innovative, cheaper, ground-breaking solutions to business problems, then the absolute last thing they should is keep adding chains onto the engineers.
Digital transformation is as much about leadership, trust and empowerment as anything else “technical” such as Cloud, DevOps, or CI & CD.
Applying old top-down principles such as pre-selected technologies and languages, enforced tooling and common processes will fail with the same results as pre-transformation because the conditions for the actual engineering work haven’t changed.
The only aspiration achievable under such conditions is inertia, yet the blame for a failed transformation will likely be purely at the feet of the engineers.
