A story about bottlenecks, breakthroughs, and the people brave enough to act on both.
There's a particular kind of frustration that comes from watching a capable system grind to a halt — not because the idea is wrong, but because one hidden constraint is strangling everything else. I first encountered that frustration in the early 1990s, working for a logistics firm in Germany. What happened next taught me more about technology adoption, organisational resistance, and the real meaning of performance than any course or certification ever could.
The World Before Real-Time Tracking
Today, you can watch your parcel inch its way across a city on a map in your pocket. In 1992, you phoned a hotline and waited while a human being tapped through amber or green text on a terminal — no mouse, no graphics, just the slow rhythm of keystrokes and patience.
The digital backbone of our operation was a piece of software running on SCO Unix servers. Every parcel in the network carried a barcode; every scan — entering a depot, loading onto a lorry, arriving at a final destination — fed into this system. Its most important output was the waybill: a printed route sheet handed to each delivery driver at the start of their shift, telling them exactly where to go and in what order.
Generating those waybills was, in computing terms, an almost perfect problem. But the solution we were running was far from perfect.
The Morning Bottleneck
Each night, batch jobs would dial out over modems to collect updated data from the central database: compressed files that travelled remarkably well down the phone lines of the era. By early morning, those files were decompressed and ready.
Then the real work began.
The scan software was a remarkable piece of craft: shell scripts, compiled C binaries, and a filing system that substituted for a proper database at a time when commercial SQL licences were ruinously expensive and the specialists to run them nearly as rare. To process a single waybill, the software would open files, read from them, write a line, save, close, reopen, and repeat — hundreds of files, thousands of times, for dozens of drivers.
Each individual operation was fast, but multiplied across an entire depot's morning workload, it was glacial! From the moment the software started to the moment the printers began spitting out waybills — thirty to forty minutes. Every single morning.
The drivers (a colourful crew, let's say, recruited partly because a fair number of employers wouldn't touch them and the job demanded toughness in all weathers) waited. And waited. The IT operator, overseeing the printing of the waybills, was often the target of their frustration. They refrained from getting physical with him directly, but kicking the door of his cabinet was a common thing. Staff turnover for this IT role was, shall we say, brisk.
The IT department tried everything: faster CPUs, more RAM. Nothing moved the needle. The bottleneck wasn't processing power or memory. It was the disks.
The Hidden Metric: IOPs
Input/Output Operations Per Second — IOPs — is not a term that ever made it into mainstream conversation, even now. But in enterprise computing it is one of the most reliable measures of real-world system performance. It tells you how many individual read and write operations a storage device can handle each second.
In the early 90s, a fast hard disk might manage 50 to 80 IOPs. The physical read/write head had to seek across spinning magnetic platters for every single operation. Our scan software was hammering those disks with thousands of requests simultaneously — and the laws of physics were winning.
Then my boss read something in an IT magazine.
The Mylex Moment
An American company called Mylex had released a SCSI RAID controller — the DAC960P — with an optional 32MB write-back cache (giving you 500 to 1500 IOPS was was effectively a 10x performance improvement). The concept was straightforward in retrospect: instead of going to disk for every individual operation, the controller held data in fast RAM, batched the writes intelligently, and served reads from cache wherever possible. The disk's physical limitations became, largely, irrelevant to the software above.
My boss phoned the regional sales office and talked them into a loan unit for testing.
We installed it over a weekend. When we ran the scan software the following Monday (in a live production environment, no backup plan, because those were the days) the waybills started printing in three minutes.
Not thirty-five. THREE!
The IT operator told the drivers he'd installed a turbo in the engine. He received thank-you baskets of beer, bacon, and cigarettes (he was a teetotal vegan, but he had the good sense not to mention it).
The Organisational Fight That Followed
The controller was only on loan. When it went back, so did the goodwill, and the situation deteriorated rapidly. My boss sought budget approval to purchase the hardware outright. The request was declined. Senior management could not grasp what a 10x performance improvement meant in operational terms, or why a faster disk controller had anything to do with the bottom line.
What changed the outcome had nothing to do with technology. The managing director of the depot was due a company car upgrade — from his eight-year-old Opel Omega to an Audi. He did the arithmetic himself: 35 drivers, 30+ minutes saved per day, more deliveries per driver, no need to hire additional staff to handle demand peaks. He cancelled the Audi, kept his Omega, and spent the equivalent of half a car on a Mylex card, cache module, and four new SCSI disks.
The board of directors were furious! That the money, designated for a company car upgrade, was spent on a... controller?
But then they looked at his depot's numbers. It became the best-performing site in Germany. Now, they couldn't fire him... And after some consideration, they gave him a Mercedes instead.
My boss was now invited into boardroom meetings. His sign-off authority doubled. I became a senior network administrator, received a company car of my own, and was put in charge of rolling out Windows NT across every German site. A £5,000 controller had redrawn the organisational map.
The Analogy That Writes Itself
If you work with AI today (and if you're reading this, you probably do, or you're thinking about it), then this story may feel familiar.
The bottleneck in our logistics system wasn't visible to the people making budget decisions. It wasn't a failure of the software's logic, or the hardware's raw power, or the people running it. It was a single hidden constraint in the flow of data, compounding across thousands of operations, that made everything else irrelevant.
AI workflows have exactly the same character. The LLM model is often not the bottleneck. What slows things down — or stops them entirely — is how data moves: how documents are ingested, how context is structured, how outputs are routed back into the next step of a process. A team can have access to state-of-the-art models and still be grinding through a 35-minute morning if nobody has identified where the real friction lives.
The organisations that got value from that Mylex controller weren't the ones with the biggest IT budgets. They were the ones with someone willing to look clearly at where time was actually being lost, make the case in terms the business understood — deliveries, revenue, headcount — and find the courage to act on it.
Today, we have the same job. Yes, the disks spin faster now, but the principle remains unchanged.
This is my first in a series of posts about the technology decisions — good, bad, and spectacularly unconventional — that shaped how we think about building systems that actually work. Follow us for more! Yours, Rainer.