> ## Content Index
> Fetch the complete content index at: https://www.ariet.net/llms.txt
> Use this file to discover other available public pages before exploring further.

# The Learning Problem
- URL: https://www.ariet.net/the-learning-problem/
- Published: 2026-07-16T12:25:55.000Z
- Updated: 2026-07-16T12:25:55.000Z
- Author: Richard Thackeray
- Tags: Enterprise Architecture, People and Organisation

*What the sinking of the Wasa tells us about how we fail to design and scale innovation today… more inspiration from Scale, by Geoffrey West.*

The Wasa sank in full view of Stockholm, less than a mile into her maiden voyage. She had been launched with cannon fire, crowds, and the king's name attached to every plank of her. A gust of wind caught her sails, she heeled, water poured through the open gunports, and she went down before she cleared the harbour. Nothing about her looked doomed.

It's tempting to call this bad luck, or incompetence somewhere in the shipyard, but it was neither. The knowledge needed to predict this failure existed, scattered across different people. Shipwrights understood the hull was unusually narrow for her height. Someone, late in the build, ordered a second gun deck added on top of the first, at the king's instruction, without a corresponding redesign of the hull to carry the new weight. Before launch, an officer ran the closest thing the era had to a stability test: thirty men running side to side across the deck, to see how far she'd roll. She rolled alarmingly and the test was stopped before anyone hurt themselves and the ship sailed despite this.

Nobody held the whole picture, and nobody was positioned to say: we don't know how to build this. The instinct was to treat an unprecedented design as a bigger version of a familiar one, on a hull form that was an extrapolation rather than a tested shape. That's an execution mindset applied to what was, in fact, a learning problem.

None of these decisions, alone, sinks a ship. A narrow hull is a known trade-off. An extra gun deck is a request a king is entitled to make. A worrying test result that is absorbed without changing the schedule happens in shipyards, and maybe software pipelines. What makes the Wasa instructive is that these weren't independent risks running in parallel; they stacked. The narrow hull made the extra weight more dangerous than it would have been on a different design. The extra weight made the stability test's result more alarming than it would otherwise have been. The suppressed test result meant nobody recalculated either of the first two decisions considering what the third had revealed. Each error raised the stakes of the next, and because no one was tracking the combination, no one could see the total had become unrecoverable until it sank.

The stability test deserves more attention because it complicates the easy version of this story. They did a test, and it worked as it gave a clear signal that something was wrong. What failed was what happened next: nobody with the authority to delay a royal launch was willing to act on thirty men staggering across a deck.

That compounding is the part that doesn't belong to 1628\. It belongs to any system complex enough that errors interact rather than sit in isolation, and what's changed since is only the clock speed. The Wasa took years to build and minutes to sink, which meant the gap between "looks fine" and "catastrophic" was at least visible, even if it wasn't acted on. Modern systems compress that gap until it nearly disappears.

Knight Capital deployed new trading software with old, dead code still live on one server; nobody had the complete picture of what was actually running across the fleet, and the compounding errors that took the Wasa from keel to harbour floor took Knight Capital from launch to four hundred million dollars lost in forty-five minutes.

Boeing's 737 MAX carried a similar stack: a hardware change, a software correction layered on to compensate for it, a single point of sensor failure that engineers flagged through channels built to catch exactly this, and a commercial timeline that didn't have room to absorb the signal.

The pathology is almost identical to the Wasa's. What's different is that the failure surfaces in minutes or seconds rather than years, which means there's less time for any human in the loop to notice the stack become dangerous before it's already failed.

There is a version of learning that looks like learning but isn't; an inquiry is held, a report is written, the failure is catalogued and a process is put in place to prevent that thing happening again. These are not nothing, but they are not institutional learning as they address the last failure, not the capability gap that made it possible. Real learning would have asked a harder question: what does this failure reveal about the limits of what we know how to do, and it would have changed the next design, not just the next checklist.

Sweden, eventually, did learn in that deeper sense. The country that lost the Wasa became a serious naval power within a generation, not by avoiding ambitious ships but by building the institutional knowledge to match the ambition. The failure was expensive enough, and visible enough, that it forced a reckoning with what was unknown rather than just what had gone wrong. That's a high price for a lesson but it's also what distinguishes an organisation that compounds its capability from one that merely compounds its errors.

The difference matters because execution problems and learning problems require completely different responses. An execution problem asks: how do we do this better next time? A learning problem asks: do we yet know enough to attempt this at all, and if not, what would it take to find out? Treating a learning problem as an execution problem doesn't just risk repeating the failure. It guarantees that whatever review follows the next failure will also miss the point, because the institution has no habit of asking what it doesn't know. The gap stays invisible, the capability stays unbuilt, and the next ambitious project sails on the same untested assumptions as the last one, only faster.

Which suggests the wrong question is "how do we move more carefully," because caution isn't really the variable that matters here. The better question is about scale, and scale doesn't mean size. A vast project can be a small leap if it's the hundredth iteration of something well understood. A modest one can be an enormous leap if it asks for capability nobody in the room has yet. The Wasa wasn't dangerous because she was big, she was dangerous because the distance between what Swedish shipwrights had reliably built before and what they were now attempting was taken in a single bound, with no smaller version tested first, and because the individual decisions within that bound were allowed to compound unwatched.

That changes what good practice looks like and note that it isn't "always be incremental." It's matching the size of the leap to the strength of the feedback loop and treating that loop as something that must track the combination of small decisions, not just each one in isolation. A fast, honest, cheap signal lets you leap further, because you'll know quickly if the stack has gone wrong and the cost of correction stays low. A slow signal, or one with no authority to stop the launch, means even a modest leap is a gamble, because by the time the combination becomes visible there may be no minutes left to act on it.

Most failures, the Wasa's and ours, aren't failures of ambition. They're failures where the instruments existed, gave true signals, and the organisation had no mechanism by which those signals, added together, could stop anything. A feedback loop with no teeth is not going to work and in a fast system, it sinks the ship before anyone in the crowd has finished watching it leave the dock.

There is a role that could have saved the Wasa. Not the king's naval advisor, the master shipwright, or the officer who ordered the stability test. Someone who walked the seams between all of them, who knew enough about the hull to understand what the extra gun deck meant for it, enough about the test result to know it wasn't an isolated data point but the combination becoming visible, enough about the schedule pressure to expose what was being traded away. Someone positioned to hold the whole picture precisely because they weren't responsible for any single part of it.

That role exists and, you knew this was coming, it's called an enterprise architect, or maybe the chief engineer in the Wasa example (“I can’t change the laws of physics!”). Not the enterprise architect who produces the perfect drawings, the complete model, the exhaustive stakeholder map as that version of the role is exactly what gets conscripted into the accounting function when what the situation needs is a sensing one. The enterprise architect worth having is the one with enough freedom to walk the seams, ask the question nobody in a single domain can ask, and name the capability gap before the compounding starts. Not "here is the complete picture" but "here is what the picture tells us we don't yet know how to do"; risk based design, what’s next is what design risk is top of the pile.

That only works inside a community that doesn't just permit questions but gives them somewhere to land. The community around any complex project needs the same quality the architect needs: not the freedom to raise concerns, which most organisations already claim to provide, but the expectation that a true signal, however uncomfortable, changes what happens next. Without that, the architect is just another strand that fades before it reaches the ship.