You're moving fast. Tasks fly off the board. Slack messages get instant replies. Deploys ship the moment code compiles. It feels like velocity. It looks like progress.
Most of it is fake.
There's a saying from military operations: "Slow is smooth, smooth is fast." The idea: rushing causes mistakes, mistakes cause rework, and rework takes longer than doing it right the first time. Moving deliberately — not slowly, deliberately — produces faster results than moving frantically.
I used to disagree. Then I tracked the numbers. 🧘
The rush tax
In October 2025, I logged every task for a month. Each one got two timestamps: when I "finished" it and when I actually completed it — no follow-ups, no bug fixes, no "oh wait, I forgot that edge case."
The gap between "finished" and "actually completed" is what I call the rush tax.
| Task type | Time to "finish" | Rush tax (rework) | Total time | If done deliberately |
|---|---|---|---|---|
| Feature dev | 4 hours | 2.5 hours (bugs) | 6.5 hours | 5.5 hours |
| Config changes | 15 min | 45 min (wrong env) | 60 min | 25 min |
| Email responses | 2 min | 15 min (clarifications) | 17 min | 8 min |
| Deploy | 10 min | 90 min (rollback + fix) | 100 min | 20 min |
| Documentation | 30 min | 3 hours (corrections) | 3.5 hours | 1.5 hours |
The pattern: rushing saved 20–40% on the initial pass and cost 50–200% in rework.
Look at the deploy row. A deploy — pushing code to the live server so users see changes — that takes 10 minutes when rushed, breaks something, and costs 100 minutes total including the rollback. A deliberate 20-minute deploy with proper checks costs 20 minutes. The rushed version is 5x slower.
Over that full month, the rush tax totaled about 12 hours per week. That's 30% of productive time spent fixing self-inflicted damage. The DORA State of DevOps report confirms this pattern at scale: teams with higher deploy frequency but proper safeguards consistently outperform teams that just push fast and pray. ⚙️
The three-breath rule
After seeing those October numbers, I started something simple: before any action that touches production — the live system real users depend on — or sends a message to more than 5 people, or commits code, I take three breaths. Ten seconds. Not meditation. Just a pause.
In those ten seconds, one question: "What am I about to do, and what could go wrong?"
Between October 2025 and March 2026, this rule prevented four incidents:
- November 2025, before a deploy: "Wait — haven't run the migrations locally." A migration — a script that changes the database structure — had a bug that would have permanently deleted a data column from the live system.
- December 2025, before a client email: "This reads aggressive. Let me soften paragraph two." That pause saved the relationship.
- January 2026, before a config change: "This is the production config, not staging." Staging is the test copy of your system. I was about to push test settings to the real thing. Service would have gone down.
- March 2026, before merging a PR: A PR (pull request) is a code change waiting for team approval. Fourteen files changed, I'd reviewed eight. I finished reviewing — found a SQL injection in file 11. That's a vulnerability where an attacker can manipulate your database through input fields.
Forty seconds of pausing. That prevented twenty-plus hours of rework. That's the math.
Why fast feels productive
Speed generates visible activity. Tasks get checked off. Messages fly. Code lands. The dashboard of completed items climbs. It feels like winning.
But a task done and then undone — because of a bug, a miscommunication, a missed requirement — had net-zero impact. It consumed time twice while delivering value zero times.
You can work 60 hours and ship less real value than a 35-hour week done deliberately. I've lived both. In the 35-hour week, I completed every task once, correctly. In the 60-hour week, I did half the tasks twice — first fast, then right.
The most effective operators I know look slow. They read the entire spec before writing code. They ask clarifying questions before starting. They deploy on Monday mornings, not Friday nights. They finish fewer things per day and redo almost nothing. Over a month, they ship more. Over a year, it's not close. 📋
Slowness as a system
"Be more careful" doesn't work. The next crisis will push you back to rushing. The principle has to live in your tools, not your intentions.
Surgeon Atul Gawande made this case for medicine and aviation in The Checklist Manifesto. The same logic applies to ops.
Deploy checklists. A script — not your memory — verifies: tests pass, migrations tested locally, health check updated, rollback ready. Five minutes. Prevents more incidents than any amount of rushing could recover from.
Message delay. Write emails and Slack messages immediately, schedule them for 30 minutes later. In that window, you'll catch tone problems, missing attachments, and wrong numbers that would have required embarrassing follow-ups.
PR cooling period. No pull request gets merged within 2 hours of opening. Even if review takes 10 minutes, it waits. Fresh eyes — even your own — work better with distance.
Incident response delay. When an alert fires, wait 2 minutes before acting (unless it's a full outage). Google's SRE handbook documents the same instinct: about 30% of alerts auto-resolve within minutes. Acting on a self-resolving alert wastes time and risks making things worse. Two minutes of patience eliminates 30% of false starts.
The capybara principle
Capybaras don't rush. They don't panic. They sit in hot springs while the world buzzes around them. And somehow they're one of the most successful species in South America — thriving where more aggressive animals struggle.
The capybara doesn't survive by being fast. It survives by being consistent, calm, and deliberate. It doesn't waste energy on manufactured urgency. It saves capacity for moments that genuinely require action.
Almost nothing is as urgent as it feels. The Slack message that "needs an answer now" can wait an hour. The "critical" bug is usually important but not time-sensitive. The deploy that "has to go out today" usually just has to go out this week. Real urgency — service down, data breach, active security incident — hits maybe once a month. Everything else is manufactured by poor planning, unclear priorities, or the cultural assumption that faster always means better.
When you stop treating everything as urgent, two things happen. Your work quality climbs. And when something actually is urgent, you have the capacity to handle it — because you haven't burned your reserves treating routine tasks like emergencies. 🍵
Move deliberately. Build things that don't break. The team that deploys calmly on Monday will always outperform the team that panic-deploys on Friday — not because they're more talented, but because they don't spend half their week cleaning up self-inflicted damage.
Slow is smooth. Smooth is fast. And fast, paradoxically, is slow. 🫶
