Slow is Smooth, Smooth is Fast

Welcome to Der Wienerschnitzel

May I take your order please?

>

Yeah, I want:

Two large cokes, two large fries

Chili-cheese dog, large Dr. Pepper

Super deluxe with cheese and tomato

— Descendents, "Der Wienerschnitzel"

Mark,

Soldiers say it. Surgeons say it. Jazz musicians say it. Climbers say it. Anyone who has to perform under actual pressure knows it.

Slow is smooth. Smooth is fast.

Nobody says "break things" out loud anymore. They say "move faster" and "question our safeguards." The translation takes one step.

"Move fast and break things" is what you tell the press about a company generating technical debt faster than finding positive revenue. In actual high-stakes work, breakage is not the price of speed. Breakage destroys speed. Every broken thing you ship is lead time you'll pay back with interest. Every rework cycle is a team-week you won't get back. Every shattered assumption is psychological cost on the people.

The State of DevOps data has been saying the same thing, more boringly, for a decade. High-performing teams deploy more frequently AND have lower change failure rates AND recover faster when something breaks. Speed and stability correlate. They do not trade off. The teams that ship quickly are the teams that do not break things. The teams that ship slowly are the teams that keep breaking things.

Lewis Carroll got there a century before Gene Kim. The Red Queen, in Through the Looking-Glass, tells Alice: "it takes all the running you can do, to keep in the same place." That is what "move fast and break things" actually produces. You break something, you fix it. You break something new, you fix that. If you are breaking things constantly, you are running as hard as you can just to hold your ground. Your forward progress is zero.

That is not speed. That is the shape of speed.

What We Actually Want

What we actually want is a team that delivers quickly and can iterate safely in production. A team that ships confidently, catches its own mistakes, recovers fast when something slips past, and learns from everything it releases. That is what "a high-performing team" means.

You don't get that team just handed to you. You get it by investing — over quarters, not months — in cohesion, in psychological safety, in technical fundamentals, in slack capacity. The team that can iterate safely is the team that has built the conditions for safe iteration. Delivery is downstream.

Here's the sharp edge of it, Mark. We are being asked to move faster, and our safeguards are being questioned — because we are falling behind.

Some of those safeguards I've questioned. Were they put there by fear? Were they inherited and never tested? Not every guardrail survives a team that has grown out of it.

But "question the safeguards" and "remove safeguards to move faster" are different things. The slippage between them produces breakage. And breakage makes us fall further behind. The prescribed remedy accelerates the disease. That is not tenable.

The company is asking for the output of a team it didn't build. It wants the velocity and safe iteration and confident pace — stripped of the underlying capability.

This is the same pathology as last week, Mark. Different costume. Then it was token counts — the meter measuring the ritual of AI use instead of the output. This is the same move. You can't measure whether anyone is actually producing value faster. So you measure whether they look like they're working harder.

Meanwhile my team — eleven people who still need to become one team — gets the worst of both. The pressure to perform speed. The accumulating breakage. The deferred work of actually becoming cohesive. The eventual reckoning when all the broken things come due at once.

The Question I Keep Circling

Here's where it gets complicated, Mark. And here's where I admit I haven't figured this out.

The business isn't wrong. We're missing deadlines because we aren't yet the team they need. Someone made commitments that assumed a team that could hit them, and we're not that team. The urgency is real. The frustration is earned.

Last week was easy to write because mandating metrics is clearly bad. Mandating a method is harder. Because sometimes — genuinely — you do need to set the method. A team without one drifts. Eleven people with four pillars and no coherent practice will not self-organize into functional unity just because I leave them alone. Somebody has to call the stroke.

So the question isn't "mandate or don't." It's: what do I mandate, and how?

The best answer I have is from 924 Gilman. Tim Yohannan didn't mandate behaviors — he mandated conditions. "No violence. No racism, sexism, homophobia. No major labels. All-ages." Those are the rules. What happens inside the rules — which bands play, what the community does on Thursday night — none of that was his business. The rules protect the conditions where the community can self-organize.

Applied here, it looks like this. I can mandate conditions: we do not ship breakage. We do not cut corners that shift work to the next team. We do not let one pillar project metastasize because it's blocking another one. Those are the rules. They protect the conditions where eleven people can become a team.

What I can't mandate is the behavior. I can't tell any engineer exactly how to code, which practice to use on which day, when to pair and when to work alone. That's where I hand the work back to the humans doing it.

Here's the problem with 924 Gilman as a model. Self-organization takes time. Mandating conditions means the team has to stumble around in the dark to find the right answers for themselves. And we're already slipping schedules.

This is a working hypothesis, Mark. I'm not sure it holds.

What I'm Actually Doing

Inside that frame, here's the narrow path.

I am naming the iron triangle. Speed, scope, cost — pick two. Leadership is trying to pick all three. Four pillars stay four pillars. Headcount stays eleven. Speed is what they're demanding. The triangle doesn't care what they demand. Something gives — the quality, the team, or both. Refusing to lie about capacity is part of the job.

The hard part is communicating it. Capacity is a boiling frog. There was no moment when the temperature jumped. It's been ratcheting since January. From inside the pot we feel it, but we can never point at a single moment and say "that's too hot." From outside it looks like more of the same. No alarm to raise — because every week just looked like the week before.

I am giving people PTO. Actual time off, not minimum compliance. The team has been running full tilt since January, and the team leadership wants won't come from depleted people.

I got everyone together for an on-site. Not a hackathon. Not forced team-building. Just time in the same room, because eleven people who happen to orbit the same codebase don't become a team over Slack.

And I am — this is the part I am least sure about — refusing to ship "transformation" during crunch. For the next two months: no process change I initiate. Not a "new way of working" on top of eleven people who are holding on. If the method has to change to unblock us, we'll change it.

These are my choices, Mark. I'm worried they'll cost me more in battles than they can win me in the war.

For Mark

Here's the question I can't answer, and the reason I'm writing this to you.

Have you ever seen a team successfully rebuilt during crunch? Or has it always been calm or gone wrong? In all your years of coaching, was there a case where someone had a fragile team, and actually threaded the needle? What did they do?

I'm not asking rhetorically. I'm walking the narrow path I just described and I don't know if it works. The other choice I see: hold the line so hard I become the blocker, get replaced, and watch my team get broken up from afar.

Slow is smooth. Smooth is fast. But someone at the drive-through window is yelling about the chili-cheese dog.

What do you do when it's your turn at the speaker?