Entiende lo que importa.

Se nos había caído un microservicio de la aplicación B2B que estamos montando. Imagínate el panorama: el canal de Slack lleno de gente preguntando qué pasa y si hay que avisar al cliente.

Por suerte revisé Slack en ese momento, así que lo cogí antes de que la bola creciera. Entré en AWS, vi que el problema estaba en la base de datos, y con un par de iteraciones con Claude di con el fallo.

La solución fue aumentar las max_connections de nuestra instancia de RDS. Cambiar un número, vamos.

«¿Cómo lo has hecho tan rápido?», me dijo un compañero. Mi jefe se quedó impresionado. Tenía a gente preguntándome qué había tocado.

Esa misma tarde hice el postmortem. Documenté lo que creía que había provocado el fallo, tracé la secuencia de eventos y lo compartí en el hilo del incidente.

Al día siguiente, un compañero me dijo que no estaba de acuerdo con mi diagnóstico. Se puso a investigar y descubrió que la causa real era completamente distinta. Lo que yo había identificado era solo la última ficha del dominó. La pieza final de una cascada de sucesos.

Mi compañero rastreó toda la cadena. Encontró el origen real. Lo explicó por Slack, bien argumentado, con detalle.

Ni un comentario, ni una mención en ninguna reunión posterior. Su trabajo se quedó enterrado en un hilo que ya nadie leía. Dos canales más abajo alguien mencionaba lo rápido que se había resuelto el P0. Con mi nombre.

Es raro que te feliciten por algo que sabes que fue superficial. Yo cambié un número en una config y encima me equivoqué diagnosticando el problema. La distancia entre mi parche y el análisis de mi compañero era enorme.

Pero eso que yo hice fue lo que importaba.

Lo único que hacía falta era que la aplicación volviese a funcionar y que alguien dijera «me ocupo del resto». Hice exactamente eso sin darme cuenta de que era lo que el momento pedía. Con eso, mi nombre quedó asociado a la solución.

Todo lo que vino después ya no tenía el mismo peso. Mi compañero hizo un trabajo más profundo y más riguroso que el mío. Pero lo entregó cuando la urgencia ya se había disuelto. La ventana de atención se había cerrado.

No es que el equipo sea injusto ni que mi jefe no valore el trabajo técnico. Es que la atención tiene un ciclo. Cuando hay un problema abierto, todo lo que hagas tiene amplificación natural: todo el mundo está mirando. Cuando esa ventana se cierra, da igual lo brillante que sea tu trabajo.

Nuestro cerebro presta más atención al problema presente que al problema prevenido. Por eso cuesta tanto valorar el trabajo de prevención: no puedes ver lo que no llegó a pasar.

Si lo piensas con frialdad, el análisis de mi compañero era técnicamente mejor. Pero el valor real que aportó fue menor. No porque la investigación no sirva, sino porque el momento multiplicó el valor de una acción y redujo el de la otra.

Eso son las palancas. Saber dónde poner la fuerza para que el resultado se multiplique. A veces la palanca es pasar dos semanas haciendo un refactor limpio. Otras veces es cambiar un número y escribir «ya está» en Slack.

Lo que cambia no es la calidad del trabajo. Es el punto donde lo aplicas.

La respuesta no es dejar de hacer trabajo profundo. Pero sí desarrollar un instinto para leer el momento. Para distinguir cuándo el equipo necesita que alguien diga «ya está» y cuándo necesita que alguien diga «he encontrado por qué». Las dos son valiosas. Su peso cambia según cuándo las pongas encima de la mesa.

Las dos cosas son valiosas.
El timing decide cuál pesa.