I went to the Vasa Royal Warship Museum in Stockholm the other day, which was amazing – it had a breathtakingly massive 17th century wooden warship, which had been submerged for over 300 years, nearly intact as its centerpiece. It’s worth a visit if you’re ever there.

The sad story of its sinking seems to have several potential causes, but one is noteworthy both in terms of engineering and leadership. The ship set sail in 1628 as the pride of the Swedish navy during a war with Poland. It was the pride of King Gustavus Adolphus II, who took a keen personal interest in it. But the ship sank literally minutes after setting sail.

How could that be? While the king was quick to blame the architect and shipbuilder, later forensics proved both to be mostly blameless.

Likely cause #1: after the ship was designed and construction was under way, the King overruled the engineers and added much heavier cannons on the upper armament deck. The ship became top-heavy and much less stable as a result, and while the engineers tried to compensate with more ballast below, it wasn’t enough.

Likely cause #2: the King cut short the captain’s usual stability testing routines because he wanted to get the ship sailing towards the enemy sooner.

Let’s translate these two causes of failure into Internet-speak. #1: In the middle of product development, CEO rewrites the specs (no doubt verbally), overruling the product managers and the engineers, and forces mid-stream changes in code architecture. #2: In order to get to market sooner, the CEO orders short-cuts on QA. I’m sure you’ll agree the results here aren’t likely to be pretty.

So product-oriented leaders everywhere…remember the tale of Gustavus Adolphus and the Vasa Royal Warship and mind the meddling with the engineers!