One of the advantages of having customers to visit everywhere is that you get to see a lot of places. Recently I was lucky enough to get stuck in Stockholm after a meeting, and got the chance to visit the excellent Vasa museum. So what? What does the well preserved wreck of a 16th century Swedish warship – the world’s most high-tech warship when it set sail – have to teach us about organisation and modern business? Well, for one thing, it sank.
The launch of the Vasa did not go well. About 1.5km into its maiden voyage, it capsized, flooded, and sank to the bottom of the Stockholm harbour, not to be seen again for another 333 years. An inquiry was of course launched into what went wrong, and more importantly, who was to blame. Of course such things are common on any failure to launch a product as well. So what did go wrong?
The Engineering Process
Let’s look at the engineering process. Shipbuilding in 1628 was not unlike the way many agile software development teams operate. There are no drawings or plans for the Vasa, because that’s not really how it was done. An expert shipbuilder just sort of worked out which bits needed to be built (I mean, they’d built a few of these before, and they all pretty much worked). This one was a bit different (it had a second gun deck) but that was fine, they built it on the same basic framework and adapted to requirements as they became clear. Meanwhile the customer (King Gustavus Augustus) and the product owner (the Vice Admiral) tweaked and added requirements long after the basic hull was laid out. The ship builders willingly complied with the requests from their customer, the king.
Shortly before the official launch party, one nervous engineer decided it might be worth doing a few integration and acceptance tests on the ship. He tried valiantly to demonstrate the flaws to the product owners in the hope that shipping a disaster could be avoided. He had 30 sailors (let’s call them QA engineers) run back and forth across the code (sorry, deck) until the boat nearly capsized in its dock. Experts declared the fundamental design and architecture to be bad because there wasn’t enough ballast to ensure stability. Cognisant of urgent customer demands, the Admiral decided to ship it anyway, because no one wanted an angry King on their hands. And so, the product launched, and promptly sank.
Part of the lesson here might be seen as the need to test earlier and test often, as advocated in agile coding practices. However, this has to go further. Testing in a lab can show up a lot of flaws, but you can’t really tell what will happen to your product until you send it out into the open water and sail it through a few squalls in the sales and marketing channels.
Blame Flows Faster Than Water When Things go Wrong
Ultimately the inquiry decided that no one was to blame, because, well it was the King’s fault, and a little bit the VP who overrode the team’s test-based decisions on ground of corporate expediency. There’s a lesson in accountability here. Who gets the blame when a product is fundamentally flawed at launch? In software, where the lives of sailors are not on the line, it’s maybe easier to shrug off blame and carry on pretending you’ve learned something for next time, but someone usually gets fired. It’s rarely the person at the top of the accountability chart.
Avoiding a Vanity Project
The Vasa is a classic example of a CEO vanity project. The ship was festooned with emblems of power. Its stern was so tall and elaborately decorated with symbols showing how amazing and powerful the leaders were, that its vanity contributed significantly to its instability. How often do products fail because heavy internal political concerns outweigh the features that would perform in the market (like basic buoyancy)?
What can we learn from this failure, and all our own failures? Stakeholder management. Make sure you create an environment where you can save power from itself by speaking truth, and if you can’t persuade your leadership with good tests and real data, make sure you build in a lifeboat.
Hopefully we can avoid some of the past mistakes, because it’s unlikely that a dedicated bunch of conservators will be dredging up your product in 300 years’ time and pumping the holes full of wood preservative. So it might be worth taking a few precautions and launching something that makes it out of the harbour.
Comments 0