Slow Down to Speed Up

Why getting faster always starts with getting slower

There’s a piece of advice I’ve been getting most of my life: if you want to get faster at something, slow down first.

For most of my younger years, I half-listened to it. Slowing down sounded like something coaches said to keep impatient kids from hurting themselves. I wanted speed. I wanted to be the fastest version of me as soon as possible. The slow part felt like a tax on the way to the real thing.

It took me a long time to understand that the slow part was the real thing. And that I’d be doing it, in some form, for the rest of my life.

The cube #

Speed cubing is where I first met this idea, even if I didn’t know to call it an idea at the time. I picked up a Rubik’s cube more than ten years ago and never quite put it down.

Speed cubing looks like it rewards quick fingers, and at the highest level it does. But the way you actually get faster isn’t by speeding up the fingers you already have. It’s by learning new algorithms, sometimes hundreds of them, and learning each one slowly enough that your hands stop guessing.

There’s a particular shape to the cycle. You’re solving comfortably at some pace. You’ve memorised the methods that got you there. You hit a plateau. The only way to break through is to introduce a new technique — a better algorithm, a new look-ahead, a different finger trick. And the moment you do, your times get worse. You’re slower than you were. It feels like going backwards.

If you stay with it, what happens next is the part nobody talks about enough. The new technique slowly stops feeling deliberate. Your hands take it over. Then, one practice session, the new way becomes faster than the old way ever was. But only because you let yourself be slow with it for long enough.

The skill where this hit me hardest was look-ahead — the art of seeing your next step while your hands are still finishing the current one. For a long time I refused to slow down for it. It felt unnatural, almost wrong, to deliberately ease off while my hands wanted to keep moving. So I’d race through solves at a pace my eyes couldn’t keep up with, blunder a recognition, and lose more time than the speed had ever bought me.

A coach once watched me solve and pointed out something I hadn’t seen: I was taking longer than I should to recognise the last PLL, the final pattern you have to read before solving the cube, because I was peeking at the back of the cube to read it. He showed me you can recognise the correct PLL from just two sides at the front. I had no idea. For years I’d been turning the whole cube around for information that was already sitting in front of me. It took weeks of slow, deliberate solves to retrain my eyes. Eventually it shaved nearly five seconds off my times — not because my fingers had sped up, but because my eyes had finally caught up to them.

I’ve been around this loop more times than I can count. New technique. Slow down. Get worse. Stay with it. Get better. Plateau. Repeat.

The pool #

Swimming came years later. Only a few years back, in fact, after more than a decade with the cube. The same lesson found me from a different angle: in my body, in my breath, in water that didn’t care how fast I wanted to be.

When I got comfortable enough with swimming to start covering distance, I became fascinated with open water. The idea of swimming with sky overhead and the natural world around me, in water that wasn’t bound by walls — no lap to push off, no end coming up, just water and breath and somewhere far ahead — pulled me in.

But the harder I tried to push for distance, the worse it went. Each time I worked harder, I’d tire faster, and the same stretch took me longer than the time before. So I went back and started reading. A YouTube channel called Effortless Swimming taught me the two-beat kick — fewer kicks per stroke, more glide between them, breathing on every second stroke instead of going too long between breaths and gasping when I came up for air. Everything about it was slower. The first time I swam that way, I went further with less effort than I ever had.

When you slow a stroke down on purpose, your form has nowhere to hide. Every flaw shows. The drop in your elbow. The breath you took half a stroke too late. At fast pace, your body papers over all of this with effort. At slow pace, you have to feel each part separately, fix it, and feel it again.

Slowing down also taught me to breathe — not just breathe, but settle into a rhythm I wasn’t fighting. There’s a particular calm that comes when you stop racing the water and start moving with it. I didn’t have a name for it then. Now I’d call it focus, or mindfulness, or simply the thing that happens when your body and your breath stop arguing with each other.

The discipline shows up here too. The swimmer who keeps showing up for the slow drills, week after week, is the swimmer who’s faster six weeks later. The drill isn’t magic. It’s just the only thing that lets the body actually learn.

I didn’t come to swimming for any of this. I came for the speed. What I kept was something else: a kind of inner steadiness I would never have found by trying harder.

The codebase #

There’s a third place I’ve watched this play out, and it’s the one that pays my bills: software.

Building software looks, from the outside, like a velocity game. Ship features. Hit deadlines. Move fast. That framing is everywhere — in startup playbooks, in quarterly goals and OKRs, in the way teams measure themselves. And it works for a while.

But code is a strange thing. It accumulates. Every shortcut you take to ship faster this week becomes a small drag on next week, a slightly heavier drag on the week after, and a real one six months from now. The shortcut that saved you an afternoon adds a tax to every change you make to that part of the system, forever, until somebody pays the tax in full by going back and fixing it.

The unglamorous name for this is technical debt. The honest name is: the speed you stole from your future self.

I’ve worked on systems where the team kept shipping features without ever circling back to refactor, simplify, or rebuild the parts that were quietly rotting under the surface. The first six months felt great — features flying out, dashboards green, demos crisp. Then the velocity started flattening. Then it started dipping. By month nine, we were spending more time fighting the codebase than building on it. The complexity had compounded. Each new feature took longer than the last. Twice as long, then three times as long. We weren’t talking about speeding up anymore. We were talking about how to stop slowing down.

The fix, when teams finally accept they need it, looks exactly like the slow drill in the pool or the new algorithm on the cube. You stop. You go back. You take the part that’s tangled and re-do it deliberately. You read the code carefully, add tests around it, refactor without changing behaviour, and then — only then — start building on it again. For the first few weeks, output looks slower from the outside. Velocity charts wobble. Stakeholders fidget.

And then, almost imperceptibly, the team starts moving faster than it has in months. Not because anyone is working harder. Because the system is finally letting the work happen.

I’ve also watched this from the outside. As a consultant, I’ve sat in meetings where leadership wanted to ship faster at any cost — and the pressure landed, predictably, on engineering. The corners that got cut never showed up in the next sprint. They showed up six months later, when the team was suddenly moving slower than it had been, and nobody could quite explain why.

I’ve been on both kinds of teams. The ones that paid the tax periodically and stayed nimble. The ones that didn’t, and watched their own velocity disappear underneath them. The difference doesn’t show up in the first quarter. It shows up in the second year.

The cycle #

None of this matches the instinct. Working harder feels productive; slowing down feels like falling behind. Every part of you wants to push, finish, ship. The instinct isn’t wrong — it’s right for the first hundred meters of any new skill. Past that, in almost everything I’ve tried to get better at, the math reverses: the harder you push, the worse you get. That takes a while to believe, even after you’ve lived through it.

Slowing down isn’t a phase you finish. It isn’t the boring chapter before the fun chapter. It’s the move you come back to every single time you want to grow — every time you want to break a plateau, every time there’s a new layer of skill sitting on top of what you already have. The better you get, the more often the slowing-down has to happen, because there’s always another layer.

I think this is where most people give up on getting good at things. The first round of slowing down feels like progress. The second round feels like punishment. By the third round, most of us are quietly looking for shortcuts, and the shortcut is usually: keep doing what you already know how to do, just faster. The plateau then becomes the ceiling.

That’s the trap.

Where to start #

I don’t always get this right. There are days I skip an algorithm I haven’t really learned yet, rush through a swim drill, or ship a feature without cleaning up the code underneath, because I want to feel fast. The cube punishes this in minutes. The pool punishes it in weeks. The codebase punishes it in months. They all punish it eventually.

If you’re trying to get faster at something — your work, the way your team builds, a sport, an instrument, a new skill, anything — try the slowest version of it for a while. See what’s actually there when you can’t hide behind pace. Then build the pace back up.

And then, when you’re fast again and you want to grow once more, slow down. Again.

That’s where speed actually comes from.