Cómo dar feedback técnico sin destruir la confianza del equipo
Un Tech Lead revisa un pull request un viernes por la tarde. El código funciona, pasa los tests, pero la solución elegida acopla dos servicios que llevaba meses intentando desacoplar. Escribe el comentario que le parece más honesto y directo: "Esto reintroduce el acoplamiento que quitamos en Q2. Hay que rehacerlo con un evento en vez de llamada directa."
Técnicamente, el comentario es correcto. Preciso. Sin ambigüedad. Y sin embargo, el lunes el autor del PR está más callado en el standup, defiende su diseño con más rigidez de la habitual, y la siguiente review que le toca a ese Tech Lead recibe respuestas de una sola línea.
El feedback era verdadero. El resultado fue peor equipo.
Dos formas de tener razón que no pueden ser ambas correctas
Hay una escuela que diría que el Tech Lead hizo lo correcto. El código tenía un problema real, lo señaló con claridad, no lo endulzó. La honestidad directa es una forma de respeto: asumir que el otro puede recibir la verdad sin que haya que envolverla. Kim Scott construye buena parte de Radical Candor sobre esta idea — el feedback que se suaviza hasta volverse ilegible no es amabilidad, es cobardía disfrazada. Decir la verdad rápido y sin rodeos es, en esta lectura, lo que un profesional le debe a otro.
Hay otra escuela que diría exactamente lo contrario. Que el comentario, por preciso que fuera, ignoró algo que ningún linter detecta: que el autor del PR no leyó "hay que rehacerlo" como una observación técnica. Lo leyó como un juicio sobre su criterio. Y una vez que alguien interpreta el feedback como un juicio sobre quién es, deja de procesar el contenido y empieza a defender su identidad.
Aquí está la tensión real. Si el Tech Lead cede a la segunda escuela, corre el riesgo de diluir cada review hasta que nadie sepa qué hay que cambiar de verdad. Si se aferra a la primera, corre el riesgo de tener razón en cada comentario y perder al equipo comentario a comentario.
Ambas fallan por la misma razón. Y encontrarla exige desarmar un supuesto que casi nadie cuestiona.
Qué creyó el Tech Lead que estaba haciendo cuando escribió el comentario
Fíjate en el supuesto oculto. El Tech Lead creyó que el feedback opera sobre el código. Que hay un objeto — el PR — con una propiedad — el acoplamiento — y que su trabajo era señalar la propiedad para que el objeto se corrigiera.
Pero el feedback nunca llega al código. Llega a una persona. Y esa persona no recibe las palabras: recibe su interpretación de las palabras.
Piensa en lo que pasó dentro de la cabeza del autor del PR al leer "hay que rehacerlo". El Tech Lead quiso decir "este diseño tiene una consecuencia arquitectónica que no queremos". El autor entendió "no confío en las decisiones que tomas cuando no te estoy mirando". Mismas palabras. Dos significados que no se parecen en nada.
¿Por qué esa brecha? Porque cada ingeniero llega a una review con un modelo distinto de lo que significa recibir una corrección. Para uno, que le rehagan un PR es rutina — parte del oficio. Para otro, que lleva seis meses intentando probar que merece el puesto, cada corrección es evidencia en un juicio que cree que está en curso. El Tech Lead no puede ver ese modelo desde fuera. Está dentro de la persona, construido con una historia que él no conoce.
Y aquí es donde la primera escuela se rompe. La honestidad directa asume que la verdad, dicha con claridad, se recibe como verdad. Pero la claridad es una propiedad del emisor. La interpretación es una propiedad del receptor. El Tech Lead controlaba una de las dos.
La pregunta que cambia el diseño del comentario
Si el feedback opera sobre interpretaciones y no sobre comportamientos, la pregunta útil deja de ser "¿cómo digo esto con claridad?" y pasa a ser otra: ¿cómo escribo esto de forma que sobreviva a la interpretación que no puedo controlar?
Se resuelve separando dos cosas que el comentario original había fundido en una sola frase.
Mira "esto reintroduce el acoplamiento, hay que rehacerlo". Hay dos capas ahí, y están pegadas. Una es la observación: el diseño tiene una consecuencia técnica concreta. La otra es la conclusión: hay que rehacerlo. El autor del PR no puede distinguir dónde termina la observación y dónde empieza el juicio, porque el Tech Lead se las dio juntas y ya masticadas.
Esta es la distinción que Difficult Conversations pone en el centro: separar lo que observaste de la historia que te contaste sobre lo que observaste. "Reintroduce el acoplamiento" es observación. "Hay que rehacerlo" es la historia — la conclusión del Tech Lead sobre qué hacer con esa observación. Y al entregar solo la conclusión, le quitó al autor la posibilidad de razonar el problema por sí mismo.
¿Qué habría pasado si el comentario hubiera sido "esto acopla PaymentService con NotificationService igual que antes de Q2 — ¿lo ves? ¿hay alguna razón por la que en este caso el acoplamiento sea aceptable que yo no esté viendo?"?
Dos cosas cambian. Primera: el autor recibe la observación sin el veredicto, así que no tiene una identidad que defender — tiene un problema técnico que mirar. Segunda, y más importante: el Tech Lead admite que su información es incompleta. Que quizá el autor tiene un contexto que él no tiene.
Por qué la pregunta no es una técnica de suavizado
Alguien podría leer esto como manipulación: preguntar en vez de afirmar para que el otro "llegue solo" a la conclusión que ya tenías. Si fuera eso, sería peor que el comentario directo — sería el comentario directo disfrazado, y los ingenieros huelen ese disfraz en dos reviews.
La pregunta funciona solo si es sincera. Y es sincera porque el Tech Lead, de hecho, no lo sabe todo. El autor del PR estuvo dentro de ese código durante horas. Conoce restricciones que el Tech Lead no vio: quizá el evento asíncrono que el Tech Lead prefiere introduce una latencia que rompe un SLA, quizá hubo una decisión de producto que forzó el acoplamiento. El conocimiento relevante para decidir bien no está concentrado en quien hace la review. Está repartido entre el que revisa y el que escribió.
Esto es lo que Marquet descubrió al mando de un submarino donde no podía ser el experto técnico de cada sistema a bordo: tuvo que construir un modo de operar donde la información fluía desde quien la tenía hacia quien decidía, en vez de asumir que el que manda es el que sabe. La pregunta abierta en una review hace lo mismo a pequeña escala. Convierte el feedback de un canal unidireccional — yo sé, tú corriges — en un intercambio donde puede emerger la mejor decisión, que a veces no es la que traía ninguno de los dos.
Liz Wiseman lo formula con precisión en Multipliers: la confianza no es "confío en que lo harás bien", es "confío en que aprenderás a hacerlo bien". Un feedback construido sobre la segunda deja espacio para el error sin convertirlo en veredicto sobre la persona. El error se vuelve material de aprendizaje, no evidencia en un juicio.
Lo que el Tech Lead no puede saltarse antes de escribir nada
Todo lo anterior asume una cosa que el comentario del viernes por la tarde no tenía: una relación previa donde el autor del PR ya sabe cómo interpreta el Tech Lead sus correcciones.
Porque la misma pregunta abierta, escrita a alguien que nunca ha recibido más que veredictos de ese Tech Lead, se lee como sarcasmo. "¿Hay alguna razón que yo no esté viendo?" suena a trampa si las diez reviews anteriores terminaron en "rehazlo". La interpretación que el receptor hace de cualquier comentario está teñida por todos los comentarios anteriores.
Por eso el feedback no se arregla comentario a comentario. Se arregla construyendo, a lo largo de muchas interacciones, un modelo compartido de qué significan las palabras entre estas dos personas concretas. Kim Scott insiste en que la guía buena ocurre en conversación, en persona — no porque el canal escrito sea malo, sino porque la conversación es donde se calibra la interpretación en tiempo real. Ves la cara. Corriges el rumbo antes de que el malentendido se solidifique.
Esto no es un proceso que se pueda escribir en una plantilla de cuarenta pasos. Es un contexto que se cultiva. El Tech Lead no puede diseñar la interpretación del otro — pero sí puede diseñar las condiciones bajo las cuales la interpretación tiende a ser generosa en vez de defensiva. Separar observación de conclusión, preguntar donde no sabe, admitir que su información es parcial: son las señales que, repetidas, construyen ese contexto.
Lo que esto generaliza más allá de una review
El principio que un Tech Lead debería llevarse de este caso vale para cualquier acto de comunicación donde crea que está transmitiendo información objetiva: la review, el 1:1, el post-mortem, el mensaje en el canal del equipo.
Ningún mensaje llega como se envió. Llega filtrado por el modelo de significado que el receptor construyó con una historia que tú no controlas y en buena parte no conoces. Tratar el feedback como si operara sobre comportamientos —"señalo el error, se corrige el error"— ignora la única capa donde el feedback de verdad sucede: la interpretación. Esa capa no se controla con más precisión ni con más honestidad. Se trabaja admitiendo que tu conocimiento del problema, y del otro, siempre está incompleto — y construyendo el intercambio para que la parte que te falta pueda aparecer.
El Tech Lead del viernes tenía razón sobre el acoplamiento. La pregunta era si el comentario dejaba al otro en condiciones de razonar el problema, o solo de defenderse de un veredicto.
Esta semana, antes de escribir tu próximo comentario en una review, sepáralo en sus dos capas y fíjate cuánto de lo que ibas a escribir era observación y cuánto era conclusión que aún no te habías ganado el derecho a entregar cerrada.
Cada semana analizo un problema real de liderazgo técnico. Con el mismo nivel de profundidad.