Você tá voando. Tarefas somem do board. Mensagens no Slack recebem resposta na hora. Deploys saem no segundo em que o código compila. Parece velocidade. Parece progresso.

A maior parte é ilusão.

Tem um ditado das operações militares: "Devagar é suave, suave é rápido." A ideia: pressa causa erros, erros causam retrabalho, e retrabalho leva mais tempo do que fazer certo da primeira vez. Agir com intenção — não devagar, com intenção — gera resultados mais rápidos do que agir no desespero.

Eu discordava. Até que comecei a medir. 🧘

O imposto da pressa

Em outubro de 2025, registrei cada tarefa durante um mês. Cada uma recebeu dois carimbos de tempo: quando eu "terminei" e quando de fato concluí — sem follow-ups, sem correção de bugs, sem "pera, esqueci daquele caso extremo."

A diferença entre "terminei" e "de fato concluí" é o que eu chamo de imposto da pressa.

Tipo de tarefa Tempo pra "terminar" Imposto da pressa (retrabalho) Tempo total Se feito com intenção
Feature dev 4 horas 2,5 horas (bugs) 6,5 horas 5,5 horas
Config changes 15 min 45 min (env errado) 60 min 25 min
Respostas de email 2 min 15 min (esclarecimentos) 17 min 8 min
Deploy 10 min 90 min (rollback + fix) 100 min 20 min
Documentação 30 min 3 horas (correções) 3,5 horas 1,5 horas

O padrão: a pressa economizava 20–40% na primeira passada e custava 50–200% em retrabalho.

Olha a linha do deploy. Um deploy — enviar código pro servidor de produção para que os usuários vejam as mudanças — leva 10 minutos quando feito com pressa, quebra alguma coisa, e custa 100 minutos no total contando o rollback. Um deploy deliberado de 20 minutos com as verificações certas custa 20 minutos. A versão apressada é 5x mais lenta.

No mês inteiro, o imposto da pressa somou cerca de 12 horas por semana. Isso é 30% do tempo produtivo gasto consertando dano autoinfligido. O DORA State of DevOps report confirma esse padrão em escala: equipes com frequência de deploy mais alta mas com as salvaguardas corretas consistentemente superam equipes que só empurram código rápido e rezam. ⚙️

A regra das três respirações

Depois de ver esses números de outubro, comecei algo simples: antes de qualquer ação que toque produção — o sistema real do qual usuários de verdade dependem — ou que envie uma mensagem para mais de 5 pessoas, ou que faça commit, eu respiro três vezes. Dez segundos. Não é meditação. Só uma pausa.

Nesses dez segundos, uma pergunta: "O que eu estou prestes a fazer, e o que pode dar errado?"

Entre outubro de 2025 e março de 2026, essa regra evitou quatro incidentes:

  • Novembro de 2025, antes de um deploy: "Pera — não rodei as migrations localmente." Uma migration — um script que altera a estrutura do banco de dados — tinha um bug que teria deletado permanentemente uma coluna de dados do sistema de produção.
  • Dezembro de 2025, antes de um email para cliente: "Isso tá soando agressivo. Deixa eu suavizar o segundo parágrafo." Essa pausa salvou o relacionamento.
  • Janeiro de 2026, antes de uma alteração de config: "Essa é a config de produção, não staging." Staging é a cópia de teste do seu sistema. Eu estava prestes a jogar configurações de teste no sistema real. O serviço teria caído.
  • Março de 2026, antes de dar merge num PR: Um PR (pull request) é uma alteração de código esperando aprovação do time. Quatorze arquivos alterados, eu tinha revisado oito. Terminei a revisão — encontrei um SQL injection no arquivo 11. Isso é uma vulnerabilidade onde um atacante pode manipular seu banco de dados através de campos de entrada.

Quarenta segundos de pausa. Isso evitou mais de vinte horas de retrabalho. Essa é a conta.

Por que velocidade parece produtividade

Velocidade gera atividade visível. Tarefas são marcadas como concluídas. Mensagens voam. Código é entregue. O painel de itens finalizados sobe. Parece que você tá ganhando.

Mas uma tarefa feita e depois desfeita — por causa de um bug, uma falha de comunicação, um requisito esquecido — teve impacto líquido zero. Consumiu tempo duas vezes e entregou valor zero vezes.

Você pode trabalhar 60 horas e entregar menos valor real do que uma semana de 35 horas feita com intenção. Eu vivi os dois cenários. Na semana de 35 horas, completei cada tarefa uma vez, corretamente. Na semana de 60 horas, fiz metade das tarefas duas vezes — primeiro rápido, depois certo.

As pessoas mais eficientes que conheço parecem lentas. Leem a spec inteira antes de escrever código. Fazem perguntas de clarificação antes de começar. Fazem deploy na segunda de manhã, não na sexta à noite. Terminam menos coisas por dia e refazem quase nada. No mês, entregam mais. No ano, nem se compara. 📋

Lentidão como sistema

"Ter mais cuidado" não funciona. A próxima crise vai te empurrar de volta pra pressa. O princípio precisa morar nas suas ferramentas, não nas suas intenções.

O cirurgião Atul Gawande defendeu essa tese para a medicina e a aviação em The Checklist Manifesto. A mesma lógica se aplica a ops.

Checklists de deploy. Um script — não sua memória — verifica: testes passando, migrations testadas localmente, health check atualizado, rollback pronto. Cinco minutos. Previne mais incidentes do que qualquer quantidade de pressa conseguiria remediar.

Delay de mensagens. Escreva emails e mensagens no Slack imediatamente, mas agende o envio para 30 minutos depois. Nessa janela, você vai pegar problemas de tom, anexos esquecidos e números errados que teriam gerado aqueles follow-ups constrangedores.

Período de maturação de PR. Nenhum pull request recebe merge em menos de 2 horas após ser aberto. Mesmo que a revisão leve 10 minutos, espera. Olhos descansados — mesmo os seus — funcionam melhor com distância.

Delay de resposta a incidentes. Quando um alerta dispara, espere 2 minutos antes de agir (a menos que seja uma queda total). O handbook de SRE do Google documenta o mesmo instinto: cerca de 30% dos alertas se resolvem sozinhos em minutos. Agir num alerta que iria se resolver sozinho desperdiça tempo e arrisca piorar as coisas. Dois minutos de paciência eliminam 30% dos alarmes falsos.

O princípio da capivara

Capivaras não correm. Não entram em pânico. Ficam sentadas em águas termais enquanto o mundo gira ao redor. E, de alguma forma, são uma das espécies mais bem-sucedidas da América do Sul — prosperando onde animais mais agressivos lutam pra sobreviver.

A capivara não sobrevive por ser rápida. Sobrevive por ser consistente, calma e deliberada. Não desperdiça energia com urgência fabricada. Guarda capacidade para os momentos que genuinamente exigem ação.

Quase nada é tão urgente quanto parece. A mensagem no Slack que "precisa de resposta agora" pode esperar uma hora. O bug "crítico" geralmente é importante, mas não urgente. O deploy que "precisa sair hoje" geralmente só precisa sair essa semana. Urgência real — serviço fora do ar, vazamento de dados, incidente de segurança ativo — acontece talvez uma vez por mês. Todo o resto é fabricado por planejamento ruim, prioridades confusas, ou pela cultura de que mais rápido sempre significa melhor.

Quando você para de tratar tudo como urgente, duas coisas acontecem. A qualidade do seu trabalho sobe. E quando algo realmente é urgente, você tem capacidade pra lidar — porque não queimou suas reservas tratando tarefas rotineiras como emergências. 🍵

Aja com intenção. Construa coisas que não quebram. O time que faz deploy com calma na segunda sempre vai superar o time que faz deploy no pânico na sexta — não porque tem mais talento, mas porque não gasta metade da semana limpando a bagunça que eles mesmos fizeram.

Devagar é suave. Suave é rápido. E rápido, paradoxalmente, é lento. 🫶