The Slowest Blade

Last Tuesday, I was blending food for my daughter. She’s almost eight months old, and I had the minipimer set to maximum, like always. Peas, carrots, potato. Full speed. Smooth paste. Done in thirty seconds.

She wasn’t having it.

Not crying, not refusing. Just… uninterested. Pushing the spoon away with that calm, devastating indifference that only a baby can pull off.

The next meal, my phone rang. I picked up with one hand, grabbed the minipimer with the other, and turned it to the slowest setting. Not because I had reconsidered my blending strategy. Not because I’d read an article about infant texture preferences. Because the thing was too loud and I wanted to hear the person on the other end.

Same ingredients, same pot, same water. But slower, I could actually watch. The chunks breaking down gradually, the texture changing as the blade caught them. What came out wasn’t smooth paste. It had grain. Small, soft pieces that actually looked like food.

She ate all of it. Then looked up and demanded more with the urgency of someone who had been waiting for this her whole life (which, to be fair, she had).

I hung up and looked at the minipimer. So who made the better parenting decision that day… me, or whoever called?

Hold that thought.

How Many of Your Best Decisions Were Actually Yours?

Think about the best architectural choice you ever made. The refactor that unlocked the project. The technology decision your team still talks about. The thing you put on your CV.

Now think about what happened right before. Was it really a moment of clarity? Or did something break, something change, something force your hand… and you just happened to be standing in the right place when the constraint landed?

I’ve spent years telling project managers a line that isn’t a joke: nine women in a room won’t make a baby in one month. They usually laugh. Then they ask me to parallelize the delivery anyway.

The excuse is always the same. “The client won’t listen.” “We have deadlines.” “We need to show progress.” And so the blade goes to maximum. More people, more sprints, more velocity points on the board. Same ingredients. Faster processing. Surely the output is the same, just sooner?

When was the last time you checked?

Not whether the feature “worked.” Whether it had texture. Whether someone on the other end, a user, a colleague, a customer, actually wanted more of it. Or whether they just pushed the spoon away.

What Changes When the Ingredients Don’t?

There’s a reason slow-cooked food tastes different from the fast version of the same dish. It’s not better ingredients. It’s not a better recipe. It’s not a better chef.

It’s time.

Time for the heat to penetrate evenly. For the flavors to break down and recombine into something new. For the collagen to dissolve into richness that no amount of high heat can replicate. A stew on full flame for thirty minutes and the same stew on low heat for four hours use the same pot, the same ingredients, the same fire. One is dinner. The other? When was the last time a meal made you stop talking?

Years ago, I joined a company as the second employee and inherited what I can only describe as a monolith of sorrow. An e-commerce platform where changing the registration flow broke the shopping cart, and touching payment logic crashed the catalog. Everything depended on everything. Eleven people, one codebase, one deploy pipeline, and every Friday release was a coin flip.

The instinct was to rewrite. Tear it all down, start clean, go fast. Every engineer reading this knows the instinct. You’ve felt it. You might be feeling it right now about something in your own codebase.

But we couldn’t. Not enough people, not enough time, not enough confidence that a rewrite wouldn’t just produce a different kind of mess at twice the speed. So we chose the strangler fig pattern: extract one domain at a time, let the old and new coexist, migrate gradually.

Was that wisdom? Or was that the only door that wasn’t locked?

The first extraction took six weeks. Six weeks where, from the outside, it looked like nothing was happening. No new features. No visible progress. Just two engineers carefully untangling dependencies that had been fused together for years.

How would your manager react to six weeks of “no visible progress”? How would you?

Here’s what happened inside those six weeks. Every day, someone said something like “oh, I didn’t realize this was connected to that.” You know what those realizations are? They’re the collagen. And what happens to collagen on high heat? It seizes up. It toughens. It only dissolves into something rich when the temperature stays low and the time stays long.

Can you schedule that in a sprint?

By the third extraction, we had it down to three weeks. Deploys went from weekly Friday prayers to multiple releases a day. New developers onboarded in weeks instead of months. Bugs stopped cascading. The system started breathing.

But here’s the question I didn’t ask myself at the time, and I should have: did I choose the slow blade? Or did the budget choose it for me?

What Happens Without the Constraint?

Then the company stopped paying its cloud provider. Not for a month. For over six months. And the provider, with the patience of a landlord who has heard every excuse, finally pulled the plug.

Instant migration. Different cloud. Everything, now.

Same concepts, technically. Lambda becomes Functions. Same idea, different approach, different texture. But there was no time to understand the differences, no time to taste anything. We were blending at maximum speed because someone else had set the timer.

We did it. The system ran. But what came out? You’ve shipped something like this. You know what it looks like. The feature that works but nobody wants to maintain. The migration that’s “done” but everyone avoids touching. The codebase that passes every test and fails every developer who opens it.

But here’s where it gets complicated. Because that panicked, textureless, paste-quality migration? It also cut the infrastructure costs in half. Same system, same capabilities, less than half the spend. The remaining team knew every puzzle piece. Every domain boundary, every dependency, every quirk of the system they’d spent years slowly untangling.

So which was it… a disaster, or a success? Was the migration fast, or was it just the last step of something that had been slow-cooking for years? When the team made decisions in hours that would have taken months at the beginning, were they rushing… or were they spending understanding they’d already earned at low heat?

Same engineers. Same knowledge. Same concepts. Different speed. So what changed… the ingredients, or the processing? Or does the answer depend on which speed you’re measuring?

Three Events. Three Outcomes.

I turned the blade down because I was on the phone. My daughter liked it. So who knew better what she needed… me, with eight months of practice, or a random phone call?

I chose the strangler fig because I couldn’t afford a rewrite. It became the best architectural decision of that project. So who was the architect… me, or the budget constraint?

The cloud migration had the same people, the same knowledge, no constraints. And it produced paste. So what was the secret ingredient in the first two stories… skill, or the lack of options?

I tell PMs that nine women can’t make a baby in one month. When do I tell them? In week one, during planning? Or in week three, when the timeline is already collapsing?

The phone rang, and I slowed down. The budget ran out, and I slowed down. The provider cut the cord, and I didn’t. Three events, three outcomes. What’s the variable… and who controlled it?

What Do You Call That?

When was the last time you saw someone choose to go slow and thought “that person has their priorities right” instead of “that person is going to miss the deadline”?

The deliberate choice to turn the heat down… before the pot boils over, before the baby pushes the spoon away, before the provider sends the final notice. Have you ever made it? Not as a reaction to something breaking. As a decision, on a Tuesday morning, with nothing on fire.

Have I?

What do you call it when every “lesson learned” was actually a lesson that happened to you? When the wisdom on your CV is really just a list of constraints you didn’t choose and accidents you didn’t plan? Is that experience? Or is that just… a series of reactions you’ve learned to narrate well?

Even this article. I wasn’t planning to write about speed and texture. I was making baby food and my phone rang. Five layers of accidental discovery, and here I am, presenting it to you like I meant to figure this out. Did I?

So here’s what I can’t stop thinking about. And now it’s yours:

If every insight you’ve ever had about slowing down came from something forcing your hand… if every good decision was a reaction to a constraint you didn’t choose… if the only reason you ever questioned your speed was because something already went wrong…

Why isn’t the question the default, instead of the reaction?