When Watchmaker Thinking Fails

One of my quiet pleasures is watching people repair old mechanical watches on YouTube. In one video, a repairer is restoring a Rolex GMT from 1958. A client sent it to him scratched, dull, and completely lifeless. He opens the case and begins to take it apart, one layer at a time. You can see tiny screws, springs, and gears laid out in neat rows on his workbench. He cleans them, oils them, replaces a few worn parts, and then builds the whole thing back up again. At the end he closes the case and the watch starts ticking like nothing happened.

What struck me was how *possible* this work is seventy years after it was built. Marshall, the person at the bench is skilled, but he is not a lone genius. Any reasonably experienced modern watch repairer with the right tools and parts could follow the same steps. The movement has a known structure. The parts have known names and sizes. If something is worn, you can order a replacement from a catalogue and trust that it will fit when it arrives.

We do this with more than watches. A bridge is designed the same way: break it into well-understood parts, specify exactly what each part should do, assemble them with tight control so the whole system behaves predictably. A pacemaker, a braking system, a hospital’s infection-control protocol, all built on the same logic. Nobody wants their pilot to discover mid-flight that the wings have decided to improvise a new way of handling turbulence.

I call this *watchmaker thinking*. If each piece behaves as planned, the whole should behave as planned. Success is when nothing unexpected happens. The watchmaker’s craft matters, and it is often invisible precisely because it succeeds.

The pattern starts to fail, and fail quietly, when we carry it beyond where it belongs.

A few years ago I was the product director for a remittance app at a forty-person fintech startup in Beirut. The product was simple: migrant workers could send money home to their families, usually a few hundred dollars at a time, funded by debit or credit card. We used a third-party payment processor and had basic fraud rules in place. The system worked quietly for months.

Then one Tuesday, our finance lead pulled me into a meeting room. A batch of chargebacks had come through, all clustered in the same week, totaling just over eight thousand dollars. These were refund requests from cardholders who disputed the charges. Someone had created several accounts, funded transfers using prepaid cards (the reloadable kind you can buy at a convenience store), and sent the money overseas before the original cards were reported stolen. By the time the chargebacks hit, the money was gone. The pattern was obvious in hindsight: new accounts, prepaid card funding, transfers to a tight cluster of recipients. None of our fraud rules had caught it.

We scheduled a post-mortem. Around the table: me, our backend engineering lead, our finance lead, someone from our payment processor dialed in on speakerphone, and the CEO. The atmosphere was careful.

The finance lead walked through the timeline. Engineering explained what the fraud rules currently checked. The processor rep described tools we were not using. Nobody wanted to be the person who should have seen it coming.

The conversation moved quickly toward what we would lock down. Block prepaid cards entirely. Add velocity limits across accounts, not just within them. Require manual review for transfers above five hundred dollars from new users. Someone proposed a formal fraud impact assessment for every product change, signed off by product, engineering, and compliance. I started to say that most of these controls would slow down legitimate users while sophisticated fraudsters simply adapted. Then I stopped. The room wanted solutions that looked like control. Saying “we cannot fully prevent this” felt like giving up.

That is when I realized: the meeting was not really about preventing the next fraud. It was about making sure that if the next fraud happened, everyone in the room could point to a document and say they had tried to be careful.

After the fraud incident, we did what many teams do. We blocked prepaid cards, added the velocity limits, created the manual review queue, instituted the fraud impact assessment process. Our written fraud prevention procedures grew from three pages to fifteen. Every product change now needed sign-offs from product, engineering, and compliance. The chargebacks stopped, at least from that particular attack.

Six months later, a different fraud pattern appeared, this time using stolen bank credentials instead of prepaid cards. The new rules did not catch it. The system was more documented, more reviewed, more signed-off. Whether it was actually more secure against adaptive threats was harder to say.

Imagine you add a new gear to a watch. You can predict exactly how it changes the timing: predictable cause and effect. Now imagine you add a new person to a five-person product team. The outcome depends on who they are, who they sit near, what problems they overhear, and a dozen other invisible relationships: the same action, vastly different outcomes.

The first kind of system is what we call complicated. A complicated system has many parts, but those parts are stable and can be understood one by one. A mechanical watch is complicated. The second kind of system is complex. A complex system is built from parts that interact and change each other over time. A product team is complex. So is a fraud pattern in a fintech app. In these systems, the same action can have different effects on different days. The pieces are not fixed the way gears are fixed. They learn. They adapt.

Watchmaker thinking works beautifully for complicated systems. The mistake is applying it to complex ones.

Fraudsters are not gears. Add a control, and they route around it. Tighten one path, and they find another. The more we tried to specify every scenario in advance, the more we were designing a watch to deal with something that kept changing shape.

When you’re making these decisions, reaching for more detail feels responsible. When a project goes wrong, we tell ourselves the plan was not comprehensive enough. When a policy fails, we add more rules. The people who design these systems are usually trying to protect others from harm and themselves from blame. They are carrying a mental model that has served them well in more predictable domains and are trying to stretch it into places where it no longer fits.

It took me years to understand that complexity isn’t just an abstract scientific concept. I’m a slow thinker, but even accounting for that, this connection wasn’t easy to see. I used to think complex systems were something for ecologists or physicists to study—something separate from the fraud controls I was designing or the product teams I was managing. When I finally saw the pattern, it felt like finding a tool that explained a dozen different frustrations at once. That realization is what pushed me to start writing the book. I’m exploring these ideas in the open, and what it means for how we should work with them.

I still watch those repair videos. There is something beautiful about a system where every part has a place, where cause and effect are close together, where seventy years later someone can take it apart and put it back together and trust it will work.

But I have learned to ask: what am I working with? A watch, or something that adapts?

I’m guessing you’re still here because this struck a chord or you’ve seen this pattern play out somewhere. Maybe in a project that got over-specified, or a team locked into rigid rules. I’d love to hear your examples. Which of your systems are watches, and which need to breathe?