Caso completo: cómo uso feedback, 1:1s y diagnóstico de rendimiento para resolver una crisis de equipo real
Una Tech Lead recién ascendida hereda un equipo de seis ingenieros que, según todas las métricas de negocio, "funciona". Los deploys salen. Los tickets se cierran. El PM está razonablemente contento. Pero en su primer mes nota tres señales que no encajan: la ingeniera más senior ha dejado de comentar en los pull requests de los demás, dos personas que antes debatían diseño en el canal común ahora se escriben por privado, y el último retro terminó veinte minutos antes con un "todo bien por mi parte" recorriendo la mesa.
Nada de esto aparece en un dashboard. Y tiene que decidir qué hacer antes de que la primera renuncia lo decida por ella.
Arreglar lo que se ve o entender lo que no se ve
Hay dos formas válidas de encarar esto, y elegir mal cuesta caro.
La primera: actuar sobre las señales directamente. La senior no comenta PRs, así que le pides que vuelva a hacerlo. El retro muere pronto, así que impones una ronda obligatoria. Cada síntoma tiene una acción correctiva evidente. Es rápido, es visible, y demuestra a tu manager que estás encima del equipo.
La segunda: no tocar nada todavía. Los síntomas son la superficie de algo que aún no entiendes, y cada intervención prematura contamina la evidencia. Si presionas a la senior sin saber por qué se calló, cambias su comportamiento sin cambiar la causa — y pierdes la única señal honesta que te quedaba.
La primera vía trata los síntomas como el problema. La segunda asume que el problema está en otro sitio y que actuar ciego lo empeora. Ambas fallan en algún contexto. La pregunta es cuál se aplica aquí.
La primera pregunta no es qué hacer, sino qué está pasando
Camille Fournier compara depurar un equipo con depurar un sistema: antes de tocar el código necesitas una hipótesis de cómo llegó al estado fallido, y la formas de la manera menos invasiva posible para no destruir la evidencia con tu propia intervención. La Tech Lead no tiene esa hipótesis todavía. Tiene tres síntomas y ninguna causa.
¿Qué sabe realmente? Que tres comportamientos cambiaron. ¿Qué no sabe? Por qué. Y aquí está el error que casi comete: creer que, como es la líder, tiene la información suficiente para diagnosticar desde su silla.
El conocimiento de qué rompió la confianza del equipo no está en su cabeza — está repartido entre seis personas que dejaron de decir cosas en voz alta. Ese es exactamente el conocimiento que necesita, y es el que su posición le oculta. Cuanto más senior eres, más filtrado llega lo que ves.
Entonces, ¿dónde vive la evidencia que le falta? En conversaciones que no puede tener en grupo. Andrew Grove lo describió con el peer-group syndrome: pon a un grupo de iguales a resolver un problema real y darán vueltas en círculo sin que nadie diga lo que piensa de verdad. El retro que murió a los veinte minutos no era un equipo sin problemas. Era un equipo que ya sabía que el foro grupal no era seguro para nombrarlos.
Lo que descarta la primera vía. Imponer una ronda obligatoria en el retro no rompe ese silencio — lo formaliza.
Por qué el 1:1 deja de ser una reunión de estado
Si la evidencia está distribuida y no sale en grupo, el único instrumento que queda es el 1:1. Pero no el 1:1 como informe de progreso. El 1:1 como el único canal donde una persona dice lo que no diría delante de los otros cinco.
¿Cómo se estructura una secuencia de estas conversaciones sin convertirla en un interrogatorio que active más defensas? La Tech Lead no entra preguntando "¿qué está pasando en el equipo?". Entra preguntando por el trabajo concreto de cada persona, por lo que le frustra, por lo que cambiaría si pudiera. La causa emerge de los lados, no de frente.
Fíjate en la secuencia. Si empieza por la senior que se calló, arranca contaminada por su propia hipótesis sobre ella. Mejor empezar por las personas periféricas al conflicto — las que aún no han elegido bando y describen la situación sin defenderla. Cada 1:1 refina la hipótesis que llevará al siguiente. Para la cuarta conversación ya no está pescando: está confirmando.
Y aquí aparece lo que ningún síntoma le habría mostrado. Digamos que descubre que la senior dejó de comentar PRs porque, tres semanas antes de que la Tech Lead llegara, sus comentarios en una revisión terminaron en una discusión pública que el anterior líder zanjó dándole la razón a la otra persona delante de todos. Se calló para no repetirlo. Los mensajes privados entre los otros dos son la misma herida por otro lado: dejaron de debatir en abierto porque vieron lo que le costó a ella hacerlo.
El diagnóstico, entonces. No es "la senior no colabora". Es "un incidente no resuelto enseñó al equipo que discrepar en público tiene coste, y cada quien optimizó por protegerse". Rumelt diría que la Tech Lead acaba de reemplazar la complejidad abrumadora de seis comportamientos raros por una historia simple que señala lo que de verdad importa. Ese es el trabajo del diagnóstico: no describir todo, sino nombrar lo que determina todo lo demás.
El feedback que cierra el diagnóstico en vez de abrirlo
Con la causa clara, el feedback tiene destinatario y forma. No va dirigido a la senior por no comentar — eso sería castigar el síntoma. Va dirigido al patrón, y buena parte del feedback más importante lo recibe la propia Tech Lead: el equipo aprendió que discrepar cuesta porque el sistema anterior lo enseñó, no porque las personas sean conflictivas.
Lo que cambia lo que hace a continuación. No puede ordenar "vuelvan a debatir en abierto" — sería pedir el comportamiento sin cambiar la condición que lo apagó. Lo que puede hacer es diseñar la condición: nombrar el incidente en abierto, asumir que la respuesta anterior fue un error de liderazgo, y demostrar en el siguiente desacuerdo real que ahora discrepar no tiene el coste que tuvo. Una vez. Luego otra.
El orden no vuelve porque ella lo decrete. Vuelve porque ella retira la razón que lo bloqueaba y deja que el equipo lo reconstruya solo. Marquet insistía en esto: si cada decisión la toma el jefe bajo presión, el equipo nunca aprende a pensar por sí mismo. La Tech Lead no está resolviendo el conflicto por ellos. Está creando las condiciones para que dejen de necesitar que alguien lo resuelva.
Lo que este caso enseña sobre cualquier crisis de equipo
Esto generaliza a toda crisis donde los síntomas gritan y la causa calla. Ningún instrumento aislado la habría resuelto. El feedback sin diagnóstico habría corregido el síntoma equivocado. El diagnóstico desde la silla del líder habría fallado porque la evidencia estaba repartida en las personas que dejaron de hablar. Los 1:1s sin una hipótesis que refinar habrían sido reuniones de estado.
Los tres funcionan porque están en secuencia y porque cada uno alimenta al siguiente: los 1:1s producen el diagnóstico, el diagnóstico dirige el feedback, el feedback cambia la condición y no la conducta.
La próxima vez que un equipo tuyo "funcione" en las métricas pero algo no encaje en la sala, resiste la primera acción correctiva que se te ocurra. Esa acción es una respuesta a lo que ves. Y lo que ves nunca es lo que pasa.
Cada semana analizo un problema real de liderazgo técnico. Con el mismo nivel de profundidad.