Vas a toda velocidad. Las tareas vuelan del tablero. Los mensajes de Slack se responden al instante. Los deploys salen en cuanto compila el código. Se siente como velocidad. Parece progreso.

La mayoría es puro humo.

Hay un dicho en operaciones militares: "Lento es suave, suave es rápido." La idea: apurarte causa errores, los errores causan retrabajo, y el retrabajo toma más tiempo que hacerlo bien desde el principio. Moverse con intención — no lento, con intención — produce resultados más rápidos que moverse frenéticamente.

Yo no lo creía. Hasta que medí los números. 🧘

El impuesto de la prisa

En octubre de 2025, registré cada tarea durante un mes. Cada una llevó dos timestamps: cuándo la "terminé" y cuándo realmente quedó completa — sin seguimientos, sin corrección de bugs, sin "ah espera, se me olvidó ese caso borde."

La diferencia entre "terminé" y "realmente terminé" es lo que llamo el impuesto de la prisa.

Tipo de tarea Tiempo para "terminar" Impuesto de la prisa (retrabajo) Tiempo total Si se hace con intención
Desarrollo de feature 4 horas 2.5 horas (bugs) 6.5 horas 5.5 horas
Cambios de config 15 min 45 min (ambiente equivocado) 60 min 25 min
Responder correos 2 min 15 min (aclaraciones) 17 min 8 min
Deploy 10 min 90 min (rollback + fix) 100 min 20 min
Documentación 30 min 3 horas (correcciones) 3.5 horas 1.5 horas

El patrón: apurarse ahorraba 20–40% en el primer intento y costaba 50–200% en retrabajo.

Mira la fila de deploy. Un deploy — subir código al servidor en producción para que los usuarios vean los cambios — toma 10 minutos cuando te apuras, rompe algo, y cuesta 100 minutos en total contando el rollback. Un deploy deliberado de 20 minutos con las verificaciones adecuadas cuesta 20 minutos. La versión apresurada es 5 veces más lenta.

Durante ese mes completo, el impuesto de la prisa sumó unas 12 horas por semana. Eso es el 30% del tiempo productivo gastado arreglando daño autoinfligido. El reporte DORA State of DevOps confirma este patrón a escala: los equipos con mayor frecuencia de deploy pero con controles adecuados superan consistentemente a los equipos que simplemente hacen push rápido y rezan. ⚙️

La regla de las tres respiraciones

Después de ver esos números de octubre, empecé algo simple: antes de cualquier acción que toque producción — el sistema en vivo del que dependen usuarios reales — o envíe un mensaje a más de 5 personas, o haga commit de código, tomo tres respiraciones. Diez segundos. No es meditación. Solo una pausa.

En esos diez segundos, una pregunta: "¿Qué estoy a punto de hacer y qué podría salir mal?"

Entre octubre de 2025 y marzo de 2026, esta regla previno cuatro incidentes:

  • Noviembre 2025, antes de un deploy: "Momento — no corrí las migraciones en local." Una migración — un script que modifica la estructura de la base de datos — tenía un bug que habría eliminado permanentemente una columna de datos del sistema en producción.
  • Diciembre 2025, antes de un correo a un cliente: "Esto suena agresivo. Déjame suavizar el segundo párrafo." Esa pausa salvó la relación.
  • Enero 2026, antes de un cambio de config: "Este es el config de producción, no el de staging." Staging es la copia de prueba de tu sistema. Estaba a punto de subir configuraciones de prueba al sistema real. El servicio se habría caído.
  • Marzo 2026, antes de hacer merge a un PR: Un PR (pull request) es un cambio de código esperando aprobación del equipo. Catorce archivos modificados, había revisado ocho. Terminé de revisar — encontré una SQL injection en el archivo 11. Eso es una vulnerabilidad donde un atacante puede manipular tu base de datos a través de campos de entrada.

Cuarenta segundos de pausa. Eso previno más de veinte horas de retrabajo. Así de simple es la matemática.

Por qué la velocidad se siente productiva

La velocidad genera actividad visible. Las tareas se tachan. Los mensajes vuelan. El código se sube. El dashboard de tareas completadas sube. Se siente como ganar.

Pero una tarea hecha y luego deshecha — por un bug, una falta de comunicación, un requerimiento que se pasó — tuvo impacto neto cero. Consumió tiempo dos veces mientras entregó valor cero veces.

Puedes trabajar 60 horas y entregar menos valor real que una semana de 35 horas hecha con intención. He vivido ambas. En la semana de 35 horas, completé cada tarea una vez, correctamente. En la semana de 60 horas, hice la mitad de las tareas dos veces — primero rápido, después bien.

Los operadores más efectivos que conozco parecen lentos. Leen toda la especificación antes de escribir código. Hacen preguntas de aclaración antes de empezar. Hacen deploy los lunes en la mañana, no los viernes en la noche. Terminan menos cosas por día y repiten casi nada. En un mes, entregan más. En un año, ni se compara. 📋

La lentitud como sistema

"Sé más cuidadoso" no funciona. La próxima crisis te va a empujar de vuelta a apurarte. El principio tiene que vivir en tus herramientas, no en tus intenciones.

El cirujano Atul Gawande planteó este caso para la medicina y la aviación en The Checklist Manifesto. La misma lógica aplica para ops.

Checklists de deploy. Un script — no tu memoria — verifica: tests pasan, migraciones probadas en local, health check actualizado, rollback listo. Cinco minutos. Previene más incidentes de los que cualquier cantidad de prisa podría recuperar.

Mensajes con delay. Escribe correos y mensajes de Slack de inmediato, prográmalos para 30 minutos después. En esa ventana, vas a detectar problemas de tono, archivos adjuntos faltantes y números equivocados que habrían requerido follow-ups vergonzosos.

Período de enfriamiento para PRs. Ningún pull request se mergea dentro de las 2 horas de haberse abierto. Aunque la revisión tome 10 minutos, espera. Ojos frescos — incluso los tuyos — funcionan mejor con distancia.

Delay en respuesta a incidentes. Cuando una alerta se dispara, espera 2 minutos antes de actuar (a menos que sea una caída total). El handbook de SRE de Google documenta el mismo instinto: alrededor del 30% de las alertas se resuelven solas en minutos. Actuar sobre una alerta que se resuelve sola desperdicia tiempo y arriesga empeorar las cosas. Dos minutos de paciencia eliminan el 30% de los arranques en falso.

El principio del carpincho

Los carpinchos no se apuran. No entran en pánico. Se sientan en aguas termales mientras el mundo zumba a su alrededor. Y de alguna manera son una de las especies más exitosas de Sudamérica — prosperando donde animales más agresivos luchan por sobrevivir.

El carpincho no sobrevive por ser rápido. Sobrevive por ser consistente, tranquilo y deliberado. No gasta energía en urgencia fabricada. Guarda capacidad para los momentos que genuinamente requieren acción.

Casi nada es tan urgente como se siente. El mensaje de Slack que "necesita respuesta ya" puede esperar una hora. El bug "crítico" generalmente es importante pero no urgente. El deploy que "tiene que salir hoy" generalmente solo tiene que salir esta semana. La urgencia real — servicio caído, filtración de datos, incidente de seguridad activo — pasa quizás una vez al mes. Todo lo demás es fabricado por mala planeación, prioridades poco claras, o la suposición cultural de que más rápido siempre significa mejor.

Cuando dejas de tratar todo como urgente, pasan dos cosas. La calidad de tu trabajo sube. Y cuando algo de verdad es urgente, tienes la capacidad de manejarlo — porque no quemaste tus reservas tratando tareas rutinarias como emergencias. 🍵

Muévete con intención. Construye cosas que no se rompan. El equipo que hace deploy con calma el lunes siempre le va a ganar al equipo que hace deploy en pánico el viernes — no porque tenga más talento, sino porque no pasa la mitad de la semana limpiando daño autoinfligido.

Lento es suave. Suave es rápido. Y rápido, paradójicamente, es lento. 🫶