Slow Down to Speed Up

I lead engineering teams, and even I found it overwhelming.

New tools, new workflows, new opinions on what you should be doing differently. Every. Single. Day. The pressure to adopt AI isn't coming from one direction — it's coming from everywhere. Your feed. Your peers. Your leadership. The industry conference you just attended. The blog post your CEO forwarded with the note "thoughts?"

If you're feeling behind, you're not alone. And if the instinct is to move faster — to find the right setup, the right prompt library, the right workflow — I want to suggest something counterintuitive: the real skill right now is learning how to slow down.

Slowification

Gene Kim and Steve Spear have a word for this. In Wiring the Winning Organization, they introduce the concept of "slowification" — the deliberate practice of slowing down to create the conditions for learning before optimizing for output. It sounds backwards. It's not.

The idea is that organizations (and individuals) who rush to perform in high-stakes, fast-moving environments tend to make expensive mistakes, burn out their people, and build fragile systems. The ones who invest time in learning — in safe, slower environments first — end up faster and more resilient in the long run.

Slow down to speed up. Create the conditions to learn before you optimize for output.

I've been applying that principle to my own AI journey. Not as a framework or a methodology — just as a mindset. And three things have stood out as genuinely useful.

Start Small

The internet will tell you there's a perfect setup. The right IDE, the right model, the right prompts, the right workflow. There isn't. The search for the optimal configuration is a procrastination trap dressed up as productivity.

The best setup is the one where you actually start. Pick a simple task — a test you've been putting off, a script you write every quarter, a refactor that's been nagging you. Use AI to help. See what happens. Don't judge the tool by the first result. Iterate. Try a different prompt. Try a different approach. The point isn't to get the perfect output. The point is to build intuition for what AI is good at and where it falls short.

That intuition can't be taught. It can only be built through repetition with low-stakes tasks, where the cost of getting it wrong is a few minutes, not a production incident. This is slowification in practice — learning in a safe environment before performing in a consequential one.

Give Yourself Time

Here's a distinction that took me a while to internalize: we're not adopting a new tool. We're learning a new way to build. Those are fundamentally different things.

Adopting a tool is a configuration problem. You install it, you learn the interface, you integrate it into your workflow. It's bounded. Learning a new way to build is an identity problem. It changes how you think about your craft, your role, your value. It touches something deeper than process.

There's excitement on both sides of this — genuine enthusiasm and genuine anxiety — and both are valid. The engineer who's energized by AI pair programming and the engineer who's unsettled by it are both responding rationally to something that is changing the nature of the work. Dismissing either reaction is a leadership failure.

Give yourself permission to be a beginner. The patience you show yourself now is what makes you effective later.

I gave myself that permission. I let go of the expectation that I should already know how to use these tools fluently just because I've been building software for 18 years. Expertise in one paradigm doesn't automatically transfer to the next. Acknowledging that isn't weakness — it's the prerequisite for growth.

Find a Partner

This was the unexpected unlock.

AI makes solo work easier — that much is obvious. But what surprised me was how it also creates new space to collaborate. When the tedious parts of a task are handled faster, you have more bandwidth for the creative, ambiguous, judgment-heavy parts. And those are exactly the parts that benefit from another person in the room.

Pair with a colleague. Build something together. Not as a formal exercise, but as an experiment. In Vibe Coding, Gene Kim and Steve Yegge describe rediscovering the fun of building — the thing that drew most of us to this work in the first place. That resonated with me deeply. I've found that feeling comes alive fastest when you share it with someone.

There's also a practical reason: when two people explore AI together, they calibrate faster. One person notices something the other missed. You build a shared vocabulary for what works and what doesn't. You normalize the awkwardness of being a beginner. The learning curve feels less steep when you're not climbing it alone.

The Leadership Implication

If this is true for me — someone who leads engineering teams for a living — it's true for the people on those teams, too. And it has implications for how we lead through this transition.

The temptation for leaders is to push for speed. Roll out the tools. Set adoption targets. Measure prompt usage. That approach optimizes for visibility, not learning. It creates a culture where people perform AI adoption rather than actually learning how to work differently.

Slowification asks something harder of leaders: create the conditions for your teams to learn at a pace that sticks. That means giving people low-stakes environments to experiment. It means not penalizing slow adoption. It means modeling the beginner mindset yourself — visibly, not just in theory.

The teams that will be strongest on the other side of this shift aren't the ones that adopted AI the fastest. They're the ones that learned it the deepest. Speed is an output. Learning is the input.