The Two-Speed Mind

Where to move fast, and where to move like a bank. Part of the series.

The first time I really understood this, a customer had paid us and gotten nothing back. The renewal went through, the money left her account, and the thing she'd paid for never arrived. I didn't find out from a chart. I found out from a message — the polite, controlled kind of angry that's so much worse than yelling.

The part that turned my stomach wasn't the bug. It was realizing I'd built the machine that took her money the exact same way I'd built the button that changed a font: fast, loose, trusting the AI to get it right, shipping before I fully understood it. The font didn't matter. Her money did. And I had been running my whole system at one speed, which was the wrong speed for half of it.

That's the lesson of this one, and it took me longest to feel in my body: a system has two kinds of parts, and treating them the same is how you die. There's the part where a mistake is cheap and reversible — a layout, a draft, a feature nobody's using yet. And the part where a mistake is expensive and permanent — money, identity, data, anything you can't take back once it's out the door. The first part you build like a hacker. The second you build like a bank. The whole craft is knowing, at every second, which one your hands are on.

The bank knew this in its bones, and split itself in two to live by it. The front office moves fast — traders, deals, noise, speed. The back office moves slow on purpose — settlement, reconciliation, the people whose entire job is to make sure the money that's supposed to move actually moved, and the money that isn't supposed to move never does. Front office improvises. Back office does not improvise, ever. Nobody on the trading floor is allowed to also confirm their own trades — that's exactly how one man sank Barings. The two speeds aren't a style choice. They're the thing that keeps the building standing.

I used to think this was just a banking quirk, a peculiarity of an industry that handles money for a living. It isn't. It's the thing every company that survives a long time eventually learns, and the people who study companies even have a name for it: ambidexterity. The finding that stuck with me sounds dull and is quietly profound — the organizations that last are the ones that can run two opposed metabolisms at once, a slow disciplined hand on the part that cannot fail and a fast reckless one on the part that has to keep inventing, without letting either hand strangle the other. The analysts later renamed it bimodal: Mode 1 for the systems of record — the money, the ledger, the things that simply must be right — and Mode 2 for the experiments, where the whole point is to move fast and be wrong cheaply. Everyone wants the tidy answer: are we a fast company or a careful one? The answer the survivors landed on is that the question itself is broken. You have to be both, at the same time, in different organs. A company with only one speed is already dying; it just doesn't know yet from which end.

Here's why this matters more with an AI than it ever did with people. The machine has exactly one speed: fast, everywhere, all the time. It does not feel the difference between the font and the money. It will refactor your payment code with the same cheerful confidence it brings to a button color, do it in four seconds, and be wrong in a way you won't notice until it shows up on somebody's bank statement. The AI cannot tell which plane it's standing on. Knowing that — and slowing it down where it counts — is not its job. It's mine. It might be the only job that is truly, only mine.

So how do you tell, in the moment, which speed you're in? I use one question, and it's the same one the back office asks: if this goes wrong, can I take it back? If yes — it's reversible, the blast radius is small, the worst case is embarrassing — let the machine run. Ship it, watch it, fix it live. That's most of the system, and moving fast there is a real advantage, not a sin. If no — it moves money, deletes something, grants access, touches a real person's account — that part goes behind the wall. It gets the slow treatment: the boundaries from last time, the things it must never do, a second set of eyes, a gate it cannot pass on its own. Reversible, fast. Irreversible, slow. That's the entire two-speed mind on a sticky note.

The trap has two doors, and I've walked through both. One speed too slow everywhere, and you never ship — you're so frightened of breaking the money that you treat the font like a wire transfer and die of caution. That's most of corporate IT, and it's why the first version of my company moved like it was wading through wet cement. One speed too fast everywhere, and you ship beautifully right up until the afternoon the money breaks and you're reading a very polite, very angry message. That was me, that winter. The skill is holding two speeds in your head at once and switching the instant you cross the line between them.

There's a third way to get it wrong — the one that actually got me — because it never feels like a mistake while you're making it. The line between the two halves moves. A feature is born harmless — a toy, a draft, a thing three people use — so you build it fast and loose, and you're right to, because at birth it really was reversible. Then it grows up. Real people start trusting it, real money starts running through it, and one ordinary Tuesday the harmless little thing is quietly load-bearing and nobody ever called the meeting to say so. The code didn't change. Its blast radius did. That's the failure that frightens me most now — not building the money path too fast, because I know to stand guard there, but missing the moment some cheerful little feature crossed over from the fast half to the slow half while I had my back turned. So you don't get to ask the question once, the day you build a thing. You have to keep asking it, because the answer expires.

In practice it means the load-bearing parts of my system don't get to enjoy how fast everything else moves. The payment path, the credits, the login, the data you can't un-delete — they live behind boundaries the AI can't cross without me, they change slowly, and every change is assumed guilty until proven safe. There's one line in our payment code that, if you change it, silently breaks every transaction in production — so it sits wrapped in a warning that says, in effect, do not touch this, ever, not even if you're certain. The font has no such warning. It doesn't need one. The art is spending your fear correctly: almost none of it on the fast half, all of it on the slow half.

The bank taught me this the way it taught me everything — by making me feel, as a junior, the specific dread of the back office, where a misplaced decimal is a career and not a typo. I hated that dread at the time. It turns out it was a sense I was meant to keep. Building with AI hands you a worker with no dread at all — infinite speed, zero fear — and your job is to be the dread it doesn't have, but only in the half of the system that's earned it. Move fast where it's safe. Move like a bank where it isn't.

For a long time I thought the one thing I could never hand off was the sorting itself — that I had to label every part fast or slow. I was wrong, and unlearning it is the most useful thing I know about managing a machine. I can't hand-label a million lines; I don't have the detail and never will. What I do instead is run it like a design review, not a dictation. I'm not the engineer — I'm the tech lead who never writes a line but kills the bad plan by asking the right question. And it's almost always the same question Amazon drills into its leaders: is this a one-way door or a two-way door? The reversible calls — two-way doors — I let the machine sprint through. The one-way doors, the ones you can't walk back, are the only ones I slow down for. So I don't hand-label a million lines. I make the model tell me which doors they are. Which parts touch money, or auth, or state you can't un-delete? Treat those like a bank; run the rest. Ask it that way, with the principle already built in, and the machine — which holds far more detail than I ever could — can usually sort it itself.

The catch is the whole game, and it's why this is a craft and not a checkbox: common sense is not common. This touches money, slow down is obvious to a person and invisible to a machine until you make it visible. So the few places where a wrong guess is fatal — the money, the access, the data — I don't gamble on the machine's common sense at all; those get hard walls it cannot cross, the never do this from last time. Everywhere else, I ask, and I keep the veto. Hard walls where it's fatal; the right question everywhere else. That — not a list of files, but a way of asking — is the two-speed mind.

Next: the immune system — how a disaster, once it happens, becomes a wall the system can never walk through again.