The Luckiest Idiot in Business History

Timothy Dexter was an 18th-century American merchant who got rich on trades that sounded idiotic.

He shipped warming pans to the Caribbean. Metal bed-warmers, to the tropics. The stories say they sold to the molasses industry, because a warming pan with a long handle is also a ladle.

He shipped coal to Newcastle, a town famous for producing coal. The stories say his shipment landed during a miners' strike.

Cats. Bibles. Again and again, people gave Dexter ridiculous ideas expecting him to lose everything, and he kept coming back richer.

Everyone decided he was lucky.

Dexter's biography has picked up a lot of folklore over two centuries. He was real, he was a leather dresser who became a merchant, and his own strange book claims the warming-pan trade. The coal and the cats come from later biographers.

The coal story and the cats are hard to establish as clean fact. So treat all of it as the stories told about Dexter, not as documented history.

Which is fine, because the argument does not depend on Dexter being real. It depends on why the explanation everyone reached for was luck.

Here's the thing about that word. It gets applied by people who could not see the reasoning.

Dexter did not come from the merchant class. He grew up poor, apprenticed as a leather dresser, and spent years around working people before he had any money. The men laughing at him were the ones who had never stood next to a vat.

A warming pan is useless in a tropical bedroom. That's obvious from a drawing room in Boston. But to somebody working a sugar operation, it's a long-handled metal scoop, and that is a completely different object.

Coal is worthless in Newcastle. Right up until you're the person who knows the miners aren't producing any this month.

I want to be careful here, because this is the point where a story like this usually turns into nonsense. I am not claiming Dexter was a secret genius. Some of it probably was luck. For every Dexter there are people who shipped warming pans to the tropics and lost the ship.

The claim is narrower and I think more useful. We cannot tell the two apart from the outside, and the person on the floor can.

Which is a nice historical anecdote until it happens to you.

A 750-person clinic in San Diego. Fifty referral coordinators who needed browser automation. So I built them a tool. Desktop app, genuinely good work, did what it was supposed to do.

Nobody used it.

So I sat with one of the coordinators. Her name was Linda. I watched her work and said nothing. Inside thirty minutes she had ignored my tool completely and gone back to the browser, four tabs open, clicking between them.

I asked her why.

She said: "Look, Chris, I don't have time to learn a new tool. My workflow is in the browser. I want something that helps me in the browser."

I rebuilt it as a browser extension. Extensions don't automate the browser from outside, they become the browser. Same workflow she showed me, roughly ten times faster.

Here's what bothers me about that story. I was the technical one. I had the budget, the skills, and the mandate. And the useful information was sitting with a referral coordinator who had never written a line of code, and I only got it because I sat down and shut up for half an hour.

Now scale that.

For most of software history, knowing how the work should be done and being able to build software that does it were separated by years of training.

That gap is collapsing, and it is collapsing fast. Not to zero. But from "learn to code, then get good, then maybe build it" down to something a determined domain expert can cross.

So the constraint moves. When building was the expensive part, the advantage sat with people who could build. When building gets cheap, the advantage sits with whoever knows what to build, in detail, at the level where the detail matters.

And that knowledge does not live in the frontier labs. It lives in people who have spent fifteen years watching one process go wrong in the same seven ways.

The nurse who knows the fourteen things that happen between a physician ordering something and a patient receiving it.

The dispatcher who knows why the optimized route on the dashboard does not survive 4:30am.

The underwriter who knows which three fields actually change the decision, out of the sixty on the form.

The paralegal, the scheduler, the operations manager, the person who does the thing.

Every one of them is carrying thousands of small facts about how work actually happens, and almost none of it is written down anywhere.

I'd be doing the same thing the drawing-room merchants did if I pretended this bet is free. It is not, and the failure modes are specific.

I don't think it's one group. The interesting combination is probably a domain expert who can build a little, sitting next to an engineer who is willing to sit and watch for thirty minutes without talking.

But if I had to say which input is underpriced right now, it isn't the model access and it isn't the engineering talent. Both of those are getting cheaper and more available every quarter.

So here's the move, and it costs you half an hour. Pick the person in your organisation whose job you understand least. Sit with them and watch them work without offering to help.

Whatever they do that your system did not anticipate is your roadmap. It was always your roadmap. You just could not see it from where you were standing, which is the whole point.

Chris