Over the last couple of weeks the world has been watching on as rescuers attempted to find, and then save, a young football team from Tham Luang caves in Thailand. Owing to a remarkable coordinated effort, and a lot of bravery from the team (including one diver who died), all 12 boys were brought back to safety.
Tech played a big part in the rescue mission too – from drones to subterranean radios. But it wanted to play a bigger role – or at least Elon Musk wanted it to. Musk and his submarine has been a somewhat bizarre subplot to this story, and while you can’t fault someone for offering to help out in a crisis, you might even say it was unnecessary.
Put simply, Elon Musk’s involvement in this story is a fable about the worst aspects of tech-solutionism. It offers an important lesson for anyone working in tech how not to solve problems.
Bringing a tiny submarine to a complex rescue mission that requires coordination between a number of different agencies, often operating from different countries is a bit like telling someone to use Angular to build their first eCommerce store. It’s like building an operating system from scratch because your computer has crashed. Basically, you just don’t need it. There are better and more appropriate solutions – like Shopify or WooCommerce, or maybe just rebooting your system.
Lesson 1: Don’t insert yourself in problems if you’re not needed
Elon Musk first offered his support to the rescue mission in Thailand on July 4. It was a response to one of his followers.
I suspect that the Thai govt has this under control, but I’m happy to help if there is a way to do so
— Elon Musk (@elonmusk) July 4, 2018
Musk’s first instincts were measures, saying that he suspects ‘the Thai government has got this under control’ but it didn’t take long for his mind to change. Without any specific invitation or coordination with the parties leading the rescue mission, Musk’s instincts to innovate and create kicked in.
This sort of situation is probably familiar to anyone who works in tech – or, for that matter, anyone who has ever had a job. Perhaps you’re the sort of person who hears about a problem and your immediate instinct is to fix it. Or perhaps you’ve been working on a project, someone hears about it, and immediately they’re trying to solve all the problems you’ve been working on for weeks or months. Yes, sometimes it’s appealing, but on the other side it can be incredibly annoying and disruptive.
This is particularly true in software engineering where you’re trying to solve problems at every level – from strategy to code. There’s rarely a single solution. There’s always going to be a difference of opinion. At some point we need to respect boundaries and allow the right people to get on with the job.
Lesson 2: Listen to the people involved and think carefully about the problem you’re trying to solve
One of the biggest challenges in problem solving is properly understanding the problem. It’s easy to think you’ve got a solution after a short conversation about a problem but there may be nuances you’ve missed or complexities that aren’t immediately clear.
Humility can be a very valuable quality when problem solving. It allows everyone involved to think clearly about the task at hand; it opens up space for better solutions.
As the old adage goes, when every problem looks like a nail, every solution looks like a hammer. For Musk, when a problem looks like kids stuck in an underwater cave, the solution looks like a kid-sized submarine.
Never mind that experts in Thailand explained that the submarine would not be ‘practical.’ For Musk, a solution is a solution. “Although his technology is good and sophisticated it’s not practical for this mission” said Narongsak Osatanakorn, one of the leaders of the rescue mission, speaking to the BBC and The Guardian.
Simulating maneuvering through a narrow passage pic.twitter.com/2z01Ut3vxJ
— Elon Musk (@elonmusk) July 9, 2018
Okay, so perhaps that’s a bit of a facetious example – but it is a problem we can run into, especially if we work in software. Sometimes you don’t need to build a shiny new SPA – your multi-page site might be just fine for its purpose. And maybe you don’t need to deploy on containers – good old virtual machines might do the job for you.
In these sort of instances it’s critical to think about the problem at hand. To do that well you also need to think about the wider context around it – what infrastructure is already there? If we change something, is that going to have a big impact on how it’s maintained in the future?
In many ways, the lesson here recalls the argument put forward by the Boring Software Manifesto in June. In it, the writer argued in favor of things that are ‘simple and proven’ over software that is ‘hyped and volatile’.
Lesson 3: Don’t take it personally if people decline your solutions
Problem solving is a collaborative effort, as we’ve seen. Offering up solutions is great – but it’s not so great when you react badly to rejection.
No, it means I created jobs for 50,000 people directly and, through parts suppliers & supporting professions, ~250,000 people indirectly, thus supporting half a million families. What have you done?
— Elon Musk (@elonmusk) July 10, 2018
Hopefully, this doesn’t happen too much in the workplace – but when your job is to provide solutions, it doesn’t help anyone to bring your ego into it. In fact, it indicates selfish motives behind your creative thinking.
This link between talent, status and ego has been developing for some time now in the tech world. Arguably Elon Musk is part of a trend of engineers – ninjas, gurus, wizards, whatever label you want to place on yourself – for whom problem-solving is as much an exercise in personal branding as it is actually about solving problems.
This trend is damaging for everyone – it not only undermines people’s ability to be creative, it transforms everyone’s lives into a rat race for status and authority. That’s not only sad, but also going to make it hard to solve real problems.
Lesson 4: Sometimes collaboration can be more inspiring than Elon Musk
Finally, let’s think about the key takeaway here: everyone in that cave was saved. And this wasn’t down to some miraculous invention. It was down to a combination of tools – some of them even pretty old. It wasn’t down to one genius piece of engineering, but instead a combination of creative thinking and coordinated problem solving that used the resources available to bring a shocking story to a positive conclusion.
Working in tech isn’t always going to be a matter of life and death – but it’s the collaborative and open world we want to work in, right?
Have you ever heard of QA in software ? Also have you followed the Sub’s story to the end ?
This case provided chance to do and test the very first test of isolated space solutions in rescue operations, there is always the first try that looks and sounds funny.
Elon started, we all have to acknowledge that, let alone that Thai officials actually were pushing him to keep working on the solution in case smaller kids couldn’t learn how to dive in time.
One of the senior divers in the operation said in interview that the efforts worked out because they maintained a big if-else map of possibilities and the sub was one of them … isn’t this a healthy practice in software development ? please re-check all rescue operation facts.
The first lesson in this article is the worst advice you can give to someone in IT today, simply because everyone in software industry already tends to be selfish and runs away from responsibility as the new form of ‘professionality in workspace’.
Tech workers nowadays couldn’t care less if the thing is not directly asked by line managers or written in the contract, the industry lacks a lot of empathy and sympathy.
A lot of good points. Just a pity one diver had to lose his life because some people decided that an initiation ceremony was cool.