Row Boats and Starships
Somewhere in your organization right now, a team is drafting a proposal for a sophisticated new platform to fix a problem that a spreadsheet with three broken formulas is actually causing. Nobody has even opened the spreadsheet. The proposal already has a budget line and a launch date.
The technology is almost beside the point. What’s actually failing is order. Most organizations have stopped asking whether the simple fix would work before reaching for the disruptive one, whether that’s AI, automation, a new platform, or whatever the current wave happens to be. Skipping that question gets expensive long before any advanced technology enters the picture.
Approximately 1,920 words · 10 minute read
Published September 16, 2026
The Row Boat Test
If you need to cross a river, do you build a starship or a row boat?
It sounds obvious until you watch how often organizations answer it wrong in practice. A starship is thrilling to propose and easy to get budget for. It’s also genuinely the right call for the handful of problems that actually need one. A row boat gets no press release. It gets you across the river, which was the point.
The discipline here is sequencing. Execute the mundane perfectly first. Simplify what’s tangled, consolidate what’s duplicated, eliminate what’s simply broken. Only once that layer is solid does an extreme, disruptive fix earn its place, because at that point it’s the only thing left that can actually move you forward. Solid means the ordinary version has actually been tried, not skipped because it looked too plain to bother with.
Skip that order and you get an expensive tool bolted onto a problem nobody diagnosed, doing the wrong job faster than before.
Every Organization Is Already Paying for Skipping This
The scale of the habit shows up clearly in how much software most companies already carry without anyone fully accounting for it. Zylo’s 2026 SaaS Management Index puts the average organization at 305 applications, spending close to $55 million a year on software, with 46% of licenses sitting unused in a typical month, roughly $19.8 million wasted annually at the average company. That sprawl built up one reasonable-sounding purchase at a time, none of them checked against what was already sitting in the stack, the row boat that was often already there before someone bought a starship instead.
The same habit shows up one layer down, inside the systems themselves. Deloitte’s 2026 Global Technology Leadership Study found that technical debt now absorbs between 21% and 40% of total IT spending at the average organization, capital that would otherwise go toward the work everyone actually wants to do. That debt built up the same way, one reasonable fix stacked on the last, until a small leak needed a full rebuild.
The Current Wave Is Repeating the Pattern, Faster
AI is the clearest example of this right now, but it won’t be the last wave to make the same mistake. WalkMe’s 2025 State of Digital Adoption research found the average enterprise is now running roughly 200 AI tools, while only 28% of employees actually know how to use the ones their company has already bought.
That gap comes down to inventory. Nobody has checked what’s already been bought against the actual problem it was supposed to solve. Bill Gates made the underlying point in Business @ the Speed of Thought decades before most of this software existed. Automation doesn’t fix what’s broken, it runs it faster, and buying a disruptive tool, AI or otherwise, for a process nobody has diagnosed does exactly that, automating the confusion that was already there, at a bigger price tag than before.
Most Fixes Are Boring, and That’s the Point
Not every fix deserves a keynote slide. A misfiled intake form, a step nobody remembers the reason for, a report three people maintain by hand because nobody agreed on which number is correct. None of these need a sophisticated new system. They need someone willing to actually look at them.
The boring fix rarely gets credit for this exact reason. Proposing a new platform photographs well in a leadership meeting. Correcting a folder structure does not. But the second one is usually what was actually broken, and the first one tends to leave it broken while adding a shinier interface on top.
Software engineering ran into this exact problem decades before any of today’s tools showed up, and settled it the same way. Donald Knuth, writing in his 1974 paper on structured programming, noticed programmers burning enormous effort chasing speed in parts of a program that barely mattered.
“Premature optimization is the root of all evil.”
Knuth’s real complaint was timing. He estimated that roughly 97% of a program doesn’t need the elaborate fix at all, and that the real skill is knowing which 3% actually does. That’s the row boat and the starship in one line, written for compilers instead of org charts, and it’s held up for fifty years because the underlying discipline never expires.
The Incentives Work Against It, So Look Anyway
The incentives point the other way.
Proposing a bold new platform gets a name attached to a roadmap slide and a seat at the strategy review. Fixing a shared spreadsheet, correcting a workflow step, or retiring a redundant tool rarely gets either, and the work that actually closes the gap stays invisible by design. Nobody writes a case study about the confusion that didn’t happen because someone cleaned up a process back in March.
There’s a career logic underneath this too. Championing a disruptive initiative is a resume line. Quietly fixing the underlying process is, at best, a footnote in someone else’s success story, since the disruptive tool that comes after usually gets the applause the diagnostic work made possible. Reversing that pattern doesn’t need a new org chart, just someone in the room willing to ask what the boring fix would actually cost before the exciting one gets approved.
The diagnostic work itself is simple. It just doesn’t get done. Before reaching for anything disruptive, get organized. Write down what’s actually happening instead of relying on what everyone assumes is happening. Identify who, or what, is doing each piece of the work today, whether that’s a person, a spreadsheet, a script, or a vendor. Then ask the only question that matters. Is it doing what you actually need it to do, or has everyone just gotten used to working around it?
That’s usually the whole exercise, a few honest conversations and a clear look at the actual workflow, not the one described in the process document nobody’s opened in a year. The gap it turns up is almost always smaller and more boring than the fix everyone was about to buy.
Even the Starship Started as a Row Boat Problem
The same discipline shows up far outside business or software too, in one of the most consequential course corrections in the history of science.
In 1859, astronomer Urbain Le Verrier noticed something wrong with Mercury’s orbit. After accounting for the gravitational pull of every other planet, Newton’s equations still fell short by 43 arcseconds per century, an angle about the width of a penny seen from a football field away, drifting that little once every hundred years.
Nobody’s first move was to discard Newton. Astronomers spent more than fifty years trying row boat fixes. They rechecked the observations, proposed an entire unseen planet nicknamed Vulcan tucked close enough to the sun to account for the gap, and even tweaked the exponent in Newton’s inverse-square law itself. None of it worked. Vulcan was never found. The tweaked law broke predictions for planets Newton had already gotten right. The number kept coming up short by the same 43 arcseconds, decade after decade.
Only after every ordinary explanation had been tried and had failed did anyone reach for something as radical as curved space and time. When Einstein finally worked the numbers for general relativity in November 1915, the theory accounted for the missing 43 arcseconds exactly, with nothing left to explain away. By his own account, the moment gave him heart palpitations.
Einstein built a starship because the row boat had been tested rigorously for more than half a century and still had a real, measured hole in it that nothing simpler could close.
The Basics, Done Daily, Win
Doing the basics perfectly, every day, wins.
Not as a stepping stone to something bigger. As the whole strategy, when it’s actually done that way.
Most businesses don’t fail because they lacked a disruptive breakthrough. They fail because ordinary things slip, just enough and just often enough, that customers and employees stop trusting the operation to hold, things like bills going out on time, invoices coming out correct, inventory counts matching what’s actually on the shelf, promises kept on the day they were made. No platform or AI model fixes that. It takes someone doing the plain work correctly, again the next day and the day after. None of it is glamorous, but it’s what compounds.
Trust is the actual product being built here, whether or not anyone on the team would put it that way. A customer who gets what was promised, on time, without having to follow up, stops thinking about the business entirely, which is exactly the goal, while a customer who has to double-check an order or chase down an invoice starts paying attention in a way competitors can exploit. Qualtrics’ 2025 Consumer Trends research, surveying nearly 24,000 consumers worldwide, found that 53% cut spending after just one bad experience, and its own top recommendation for keeping them was simply to go back to basics. No disruptive feature repairs that kind of damage as fast as simply not doing it in the first place.
This rarely gets written up as strategy, since there’s no product launch behind it. It just shows up as fewer complaints and more repeat business, quarter after quarter, a reputation competitors spend heavily trying to manufacture with marketing instead of earning with consistency.
The row boat, rowed well enough, often enough, for long enough, is the whole strategy for most businesses, most of the time. The rare exception is real. It’s just rarer than the roadmap slides suggest.
The Test Before You Approve Anything
Before signing off on the next platform, the next disruptive technology, the next big fix, three questions do most of the work:
- Has the boring fix actually been tried, not just assumed insufficient?
- Would the boring fix solve most of the problem, even if not all of it?
- Is what’s left after the boring fix small enough that it doesn’t need a disruptive tool at all?
If the honest answer to any of those is no, the case for the starship is real, and it deserves full budget and attention.
The rare exception still holds. A team of nothing but row boats loses to the team that builds a starship when a starship is genuinely what the problem calls for. Earning it, the way Einstein did, means proving first, with real rigor, that the simple version truly isn’t enough, not assuming it going in.
Most problems in most organizations are river-crossing problems. They don’t need a starship. They need someone willing to check whether the row boat, unglamorous and usually already sitting right there, would have done the job. That check costs an afternoon. Skipping it costs years, and most organizations never go back and calculate what it actually cost them.