Everyone believed the Titanic could never sink. They believed it so firmly that when it hit the iceberg, some of the first lifeboats went down half empty, because people genuinely thought staying on the ship was the safer option. And then it sank.
That is a black swan: something nobody saw coming, with a massive impact, that everyone explains afterwards as if it were obvious all along. “Of course there weren’t enough lifeboats, of course they were going too fast.” Funny how nobody was saying that before.
So why am I talking about ships?
Because The Goal by Eliyahu Goldratt and The Black Swan by Nassim Taleb have been in my head for a while now, and it’s time I put them on paper. Somewhere in between, I was dropped midway into a client project, an Agentforce rollout for an aviation maintenance software company. It ran on Salesforce, a platform I hadn’t worked with much before. Oddly, both books kept showing up in my day-to-day work.
The Goal is a novel about a factory that is losing money. Alex, the plant manager, slowly figures out that the whole plant can only move as fast as its slowest machine, the bottleneck. One of the book’s big lessons comes from a scout hike: the troop can only walk as fast as Herbie, the slowest kid, so Alex puts Herbie at the front and takes things out of his backpack. Find the slowest point, make it work as hard as possible, and make everything else serve it. Simple, right?
The Black Swan is a completely different kind of book. It’s about why we’re so bad at predicting the things that actually matter, and then so good at pretending we saw them coming.
You’d think the two have nothing in common, since one is about machines and the other is about chaos, but they agree on more than you’d expect.
Where they agree
Both of them hate averages. In The Goal there’s a dice game where kids pass matchsticks down a line, and each kid rolls a die to decide how many to pass on. You’d expect the good rolls and the bad rolls to cancel out, but they don’t, and the delays keep piling up at the end of the line. Taleb would have loved this, because the average lies :)
Both of them also hate measuring the wrong thing really well. Goldratt goes after accounting that makes every machine look busy while the factory goes broke. Taleb goes after the bell curve, which makes risk look neat and tidy while hiding the one event that actually destroys you.
The idea that applied most directly to my work is that piles of unfinished work hide problems. In a factory, that’s half-finished parts sitting around. In code, it’s branches that stay open for weeks, and on our project those quietly hid things. A senior on my team kept telling me to keep the repo clean and keep main and the org matched, so the repo stays the source of truth and we don’t have to dig through unmerged branches to find the last published agent version.
Where they split
Do they contradict each other? Yes.
A die can only roll from 1 to 6, and you can’t roll a 100 no matter how hard you try. The Black Swan calls this kind of world Mediocristan, a place where no single thing can change the total by much. Height is Mediocristan: put the tallest man alive in a stadium and the average height barely moves. Wealth is Extremistan: put one billionaire in that same stadium and suddenly he owns most of the money in it. I love this concept, and ever since I came across it I’ve been sorting things, scenarios, businesses and even ideologies into these two countries. It clears up a lot.
Goldratt’s factory lives in Mediocristan. Machines break, but within a range. That’s exactly why his method works: the bottleneck stays in one place long enough for you to find it, you keep a little buffer for the normal ups and downs, and eventually it moves.
Software doesn’t really behave like that.
On our project the bottleneck kept moving. Finding the Herbie helped, but assuming Herbie would stay in the same place did not. Sometimes protecting the bottleneck just meant saying no to requests that were never part of the scope, which is The Goal’s “make everything serve the constraint” happening on a client call.
And sometimes one tiny thing was pure Extremistan. Our agent was giving weak answers and everyone assumed it was the prompt. It wasn’t. Old archived versions of help articles were sitting at the top of the search results and pushing the right answer out, and one filter fixed it everywhere. In a factory, one setting almost never changes every single unit. In AI systems, it can.
So software delivery does follow The Goal in places. There’s always a bottleneck somewhere, unfinished work really does pile up and hide problems, and keeping everything focused on the slowest part still works. But software doesn’t behave like a factory in the way that matters most. A factory is almost always Mediocristan: the machines are predictable, the variation stays inside a range, and Herbie stays in one place long enough for you to find him.
Software now is Extremistan. One change, one prompt, one silent bug or one shift in scope can affect the whole project, and the bottleneck keeps running around. So we should treat it as Extremistan, watch the tails, and prepare so that one bad surprise can’t sink everything.
If we bring Mediocristan practices into an Extremistan world, we’re cooked. It’s like checking the average depth of a river before walking across it: the average says four feet, totally fine, and then you drown in the one spot that’s twelve feet deep.
One metric, measured close to the customer
The Goal says a business has one goal, which is to make money, and that is throughput. A part sitting in the warehouse isn’t throughput; it’s just a part. I’m genuinely bullish on this one-metric idea, because it kills so much noise.
On our project, throughput was never the number of commits, PRs, test runs or tickets moved to done. It was always how satisfied the client was at the end, and hundreds of commits mean nothing if UAT fails. This is also where the black swan sneaks in. Everything looked great, but I was the turkey, because I was measuring at my desk rather than the way the customer would phrase things. QA scores came back well below our eval scores until we improved, and that gap was the real throughput talking. Measure as close to the customer as you can, because a metric measured too far from the customer will happily feed you every day right up until Thanksgiving.
Not all inventory is waste
The Goal hates inventory, because it’s money stuck on the shelf and, worse, it hides problems. The Black Swan is a little kinder to it, since spares look like waste right up until the day you need one. I think both are right, depending on what kind of inventory you’re talking about.
On our project the inventory was basically the GitHub board: open issues, PRs sitting open for weeks, branches nobody merged, and even work that was live in the org but not on main. That kind of inventory is pure Goldratt waste. It costs attention every single day and it muddies what’s actually done.
But not all inventory is bad, and this is where The Black Swan has a point. Some of it is backup, and backup is cheap until the day it saves you. Our three orgs, partial copy, full copy and prod, were both kinds of inventory at once.
Where is the bottleneck today?
The Goal says the bottleneck moves too. Once you fix Herbie, someone else becomes the slowest, so you go back and find the new one. In a factory that move is slow: you add a machine, things change, and months later something else becomes the slowest. On our project it moved almost every week, and half the time the bottleneck wasn’t a machine at all. It was access we didn’t have, a decision waiting on someone, or a client call that hadn’t happened yet. So the question I learned to ask wasn’t “what is the bottleneck?” but “where is the bottleneck today?”
That’s what these two books ended up giving me. The Goal gave me a way to look at the work: find the slow part, keep the clutter low, and measure what actually matters. The Black Swan reminded me that whatever I’m looking at is never the whole picture.
