Producción caída: lo que separa a un Tech Lead de un ingeniero con título
Un Tech Lead recibe la alerta a las 14:12. El checkout de la plataforma devuelve errores 500 en una fracción de las transacciones. No en todas — eso sería más fácil de diagnosticar. En una fracción variable que sube y baja sin patrón obvio. El equipo de soporte ya escaló. El VP de Producto acaba de escribir en el canal general: "¿Qué está pasando con el checkout?".
Tiene dos cosas delante de él en este momento. Un stack trace que apunta vagamente a un timeout en la capa de pagos. Y una pregunta de un ejecutivo que espera respuesta.
Solo puede atender una de las dos con toda su atención.
Y aquí es donde empieza el caso — porque la decisión que tome en los próximos noventa segundos define no si el incidente se resuelve, sino cómo lo va a vivir todo el mundo que depende de él mientras se resuelve.
Dos instintos que no pueden coexistir en el mismo minuto
El primer instinto es el del ingeniero. El sistema está roto, el sistema es lo que sabe arreglar, y cada minuto que pasa hablando en Slack es un minuto que no pasa leyendo logs. Bajar la cabeza, entrar en el stack trace, encontrar la causa. La comunicación puede esperar a que haya algo que comunicar. ¿Para qué escribir "estamos investigando" si eso no aporta información nueva?
El segundo instinto es el del gestor. Hay un ejecutivo preguntando, hay soporte esperando saber qué decirle a los clientes, hay tres ingenieros más en el canal que no saben si deben meterse o quedarse fuera. El silencio de la persona que lidera es en sí mismo una señal — y una mala. Responder primero, diagnosticar después.
Ambos instintos son defendibles. Ese es el problema.
El que se lanza al código y resuelve en doce minutos parece que tomó la decisión correcta — hasta que descubres que durante esos doce minutos el VP llamó a otras tres personas, soporte inventó un mensaje para clientes que contradecía la realidad, y dos ingenieros empezaron a tocar el mismo servicio sin coordinarse. El que se dedica a comunicar y no toca el código parece responsable — hasta que resulta que era la única persona que entendía la capa de pagos y su ausencia del teclado alargó el incidente treinta minutos.
Elegir mal cuesta. Y no hay una respuesta que sirva para todos los incidentes. Lo que hay es una pregunta que el protagonista todavía no se ha hecho.
¿Qué información existe ahora mismo, y dónde está?
Empieza por lo que el Tech Lead tiene delante. Un stack trace y un timeout intermitente. Esa es toda su información directa.
Fíjate en lo que eso significa. La causa del incidente no está en su cabeza. No la tiene. Si la tuviera, no habría incidente — lo habría prevenido. En el momento de la crisis, la persona que lidera es, casi por definición, la que menos sabe sobre la causa real, porque la causa es algo que el sistema hizo que nadie anticipó.
¿Dónde está entonces la información que hace falta?
Está repartida. El ingeniero que tocó la capa de pagos hace tres días sabe que cambió el cliente HTTP a uno con timeout más agresivo. El de infraestructura sabe que hubo un despliegue de red esta mañana. Soporte sabe qué clientes concretos están afectados y desde qué hora exacta — un dato que ningún dashboard tiene con esa precisión. El de datos sabe que la latencia del proveedor de pagos externo lleva subiendo desde ayer.
Ninguna de esas personas tiene el cuadro completo. El Tech Lead tampoco. El cuadro completo no existe en ningún sitio todavía — hay que construirlo juntando fragmentos que están en cabezas distintas.
Y aquí la pregunta del código contra la comunicación se reordena sola. Si la información está distribuida entre cinco personas, la primera tarea no es leer logs. Es abrir el canal por el que esos cinco fragmentos pueden llegar a un mismo sitio. Bajar la cabeza al stack trace es optimizar el uno por ciento de la información que ya tienes mientras ignoras el noventa y nueve por ciento que está en otras cabezas esperando ser convocado.
Donella Meadows, en Thinking in Systems, insiste en que el comportamiento de un sistema emerge de las relaciones entre sus partes, no de las partes aisladas. Un incidente de producción es exactamente eso hecho visible: cada componente funcionaba bien por separado. El timeout del cliente HTTP era razonable. El despliegue de red era rutinario. La latencia del proveedor estaba dentro de rango. El fallo vive en la intersección de los tres — y ninguna persona la ve sola.
¿Por qué el silencio no es neutral?
El Tech Lead que elige callar hasta tener algo que decir asume que el silencio es información cero. Que no comunicar es no hacer nada.
No lo es.
Cuando un VP pregunta "¿qué está pasando?" y no recibe respuesta durante ocho minutos, no interpreta ese silencio como neutro. Lo llena. Y lo llena con la peor versión disponible: nadie está al mando, nadie entiende el problema, esto es peor de lo que parece. En ausencia de una señal clara, la gente construye la señal que más miedo le da.
Esto es lo que se te escapa cuando piensas la comunicación como transmisión de datos. Un "estamos investigando el checkout, impacto limitado a pagos, actualizo en quince minutos" no contiene información técnica nueva. No dice la causa. No dice el fix. Y sin embargo cambia por completo el comportamiento de todos los que reciben el mensaje.
El VP deja de llamar a otras tres personas. Soporte deja de improvisar un mensaje contradictorio. Los ingenieros que dudaban si meterse saben ahora que hay alguien coordinando. Un mensaje que no transmite información técnica reorganiza el sistema humano alrededor del incidente.
Piensa en el dato que ya establecimos: la información está dispersa y hay que convocarla. El mensaje de "estamos investigando" no es un parte de guerra vacío. Es la señal que le dice a las cinco personas con fragmentos que hay un sitio donde traerlos. Comunicar en crisis no es reportar lo que sabes. Es construir el canal por el que va a llegar lo que no sabes.
¿A quién le hablas, y por qué no es a todos a la vez?
Asumamos que el Tech Lead ya entendió que tiene que comunicar antes de resolver. Queda el problema difícil: no todos los que esperan una señal esperan la misma.
El VP de Producto no quiere el stack trace. Quiere saber tres cosas: cuánto impacto en clientes, si va a peor o a mejor, y cuándo tendrá la siguiente actualización. Si le das detalle técnico, lo lees como que no tienes el control del panorama. Le hablas en su moneda: negocio, tiempo, magnitud.
El ingeniero de pagos quiere exactamente lo contrario. Quiere el stack trace, el número de la línea, el timestamp del primer error. Si le das lenguaje de negocio, le estás quitando tiempo de diagnóstico.
Soporte quiere una sola cosa: qué puede decirle al cliente que llama enfadado, y qué no debe prometer. Un mensaje mal calibrado a soporte se convierte en una promesa pública que el equipo técnico no puede cumplir.
Chris Voss, en Never Split the Difference, construye toda su técnica de negociación sobre una idea que aquí es central: antes de intentar mover a alguien, tienes que demostrarle que entiendes qué le importa. En una crisis no estás negociando, pero el mecanismo es idéntico. El VP que siente que entiendes su preocupación por el cliente te da margen. El que siente que le estás ocultando o mareando con tecnicismos, no.
Y esto conecta con algo que David Maister describe en The Trusted Advisor: la confianza no se construye en el momento de la crisis, se gasta. El Tech Lead que ha comunicado con claridad y honestidad en los meses previos tiene una reserva de la que tirar cuando dice "dame quince minutos". El que solo aparece cuando algo se rompe no tiene esa reserva — y cada mensaje suyo se lee con sospecha.
La consecuencia práctica es incómoda para el instinto del ingeniero. No hay un mensaje del incidente. Hay tres o cuatro mensajes distintos del mismo incidente, uno por audiencia, y calibrar cada uno es trabajo real que compite por la misma atención que el diagnóstico. Por eso el Tech Lead no puede ser a la vez la persona en el teclado y la persona que comunica. Alguien tiene que sostener cada rol.
¿Quién arregla el código si tú estás comunicando?
Llegamos al punto donde la cadena se cierra sola.
Si la información está dispersa, si el silencio hace daño, si cada audiencia necesita un mensaje calibrado — entonces el Tech Lead no puede estar en el teclado buscando la causa. Su trabajo en el incidente no es encontrar el bug. Es construir el sistema temporal que hace que el bug se encuentre.
Eso significa nombrar, en voz alta y explícita, quién hace qué. Quién es el que investiga la capa de pagos. Quién revisa el despliegue de red. Quién habla con el proveedor externo. Quién mantiene informado al VP. Y quién — esto es lo que casi todos olvidan — sostiene la línea temporal del incidente para que en el post-mortem exista un relato reconstruible.
El Tech Lead que se resiste a esto suele ser el mejor ingeniero del equipo. Y ahí está la trampa. Camille Fournier lo describe con precisión en The Manager's Path: el Tech Lead que se mete en el agujero técnico mientras el proyecto se descontrola a su alrededor, convencido de que el problema real está en el código, porque el código es donde se siente competente. En una crisis ese reflejo se multiplica. La persona más capaz de leer el stack trace es precisamente la que más falta hace coordinando — y la que más ganas tiene de no coordinar.
Delegar el diagnóstico al ingeniero de pagos no es abdicar. Es reconocer que él tiene el fragmento de información que tú no tienes, y que tu valor no está en duplicar su trabajo sino en asegurar que su hallazgo llega a quien tiene que actuar sobre él, traducido a la audiencia correcta, en el momento correcto.
Fíjate en lo que ha pasado con la decisión inicial. La pregunta ya no es "¿código o comunicación?". Esa disyuntiva era falsa. Era la pregunta de alguien que creía que tenía que hacer las dos cosas él mismo. En cuanto aceptas que la información no está en tu cabeza sino repartida, el rol del que lidera deja de ser resolver y pasa a ser conectar. El código lo arregla quien tiene el fragmento que hace falta. Tú construyes las condiciones para que ese fragmento aparezca y se use.
Lo que el incidente reveló que no estaba en el sistema
Cuando el checkout vuelva a funcionar y llegue el post-mortem, la tentación será buscar al culpable del timeout. El ingeniero que cambió el cliente HTTP. El despliegue de red. El proveedor lento.
Ninguno de esos es la lección.
El fallo no fue negligencia de nadie. Fue el comportamiento esperado de un sistema que no tenía las señales para avisar antes de romperse. Nadie conectó los tres cambios porque no existía ningún sitio donde los tres estuvieran visibles a la vez. La información que habría prevenido el incidente existía — estaba repartida en tres cabezas que nunca coincidieron en la misma conversación. Como recoge la investigación de Accelerate, los equipos que se recuperan rápido de los fallos no son los que fallan menos, sino los que han diseñado el flujo de información para que el fallo se detecte y se acote antes de escalar.
Esto generaliza a cualquier situación donde alguien que lidera enfrenta un problema cuya causa no conoce y no puede conocer solo. La competencia que se evalúa en esos momentos no es cuánto sabes de sistemas distribuidos. Es cuán bien construyes, en tiempo real, el canal por el que el conocimiento que está fuera de tu cabeza llega a donde tiene que actuar — y cómo suena tu voz para cada persona que depende de esa señal para saber qué hacer a continuación. El ingeniero con título resuelve el bug que tiene delante. El Tech Lead diseña las condiciones para que el bug que nadie ve todavía se vuelva visible a tiempo.
La próxima vez que caiga producción, mide una cosa antes que el tiempo de resolución: cuántos minutos pasaron entre la alerta y el primer mensaje que reorganizó a la gente alrededor del problema. Ese número dice más sobre tu liderazgo que la causa raíz.
Para calibrar esos primeros mensajes sin improvisar bajo presión, preparé una guía de mensajes tipo por audiencia y timing para incidentes de producción — qué decirle al ejecutivo, al equipo técnico y a soporte en cada fase, disponible para suscriptores.
Cada semana analizo un problema real de liderazgo técnico. Con el mismo nivel de profundidad.