Cómo dar feedback técnico sin destruir la confianza del equipo

"El código está sobreingenierizado." Escribes eso en un pull request, das enter, y crees que has dicho algo objetivo. No lo has dicho.

Has enviado un símbolo. Lo que el ingeniero recibe al otro lado no es tu observación técnica. Es su interpretación de tu observación, filtrada por lo que él cree que piensas de él, por las tres veces anteriores que le comentaste algo parecido, por si ese día venía de una reunión donde ya se sintió cuestionado. Tú creíste que hablabas del código. Él escuchó algo sobre sí mismo.

Ese desfase es el motivo por el que un feedback técnicamente correcto puede romper la confianza de un equipo entero. Y es también el motivo por el que casi todos los consejos sobre "cómo dar feedback" fallan en la práctica.

El feedback no viaja intacto entre dos cabezas

El modelo mental que la mayoría de nosotros usamos sin darnos cuenta es el de la transmisión. Yo tengo una observación en mi cabeza, la codifico en palabras, tú la decodificas, y ahora la observación está también en tu cabeza. Feedback como transferencia de datos.

Ese modelo es falso, y su falsedad tiene consecuencias medibles en cómo reacciona tu equipo.

Cuando le dices a un ingeniero que su función "hace demasiadas cosas", tú tienes en mente un principio de diseño concreto: responsabilidad única, acoplamiento, testabilidad. Pero la palabra "demasiadas" no lleva ese contexto pegado. El ingeniero la recibe y la conecta con su propia red de significados. Si tiene tres años de experiencia y viene de un equipo donde le criticaban constantemente, "demasiadas cosas" significa "no sé diseñar". Si tiene quince años y una posición sólida, significa "tenemos criterios distintos sobre dónde cortar". Mismas palabras. Dos mensajes que no se parecen en nada.

El libro Difficult Conversations, de la gente del Harvard Negotiation Project, nombra esto con precisión: toda conversación difícil contiene en realidad tres conversaciones simultáneas. La de los hechos —qué pasó—, la de las emociones, y la de la identidad —qué dice esto sobre quién soy. El feedback técnico pretende operar solo en la primera. Pero llega a las tres a la vez, y la tercera es la que decide si tu comentario produce un cambio o produce un muro.

No tienes acceso directo a esa tercera conversación. No sabes qué modelo de significado tiene el ingeniero al otro lado del PR. Y ahí está el problema real: cualquier técnica de feedback que asuma que puedes controlar cómo se recibe tu mensaje está construida sobre una información que no posees.

Por qué la honestidad brutal falla precisamente donde debería funcionar

La respuesta popular a esto es Radical Candor, de Kim Scott: importa a la persona y desafíala directamente al mismo tiempo. Es un buen marco. Pero se malinterpreta casi siempre, y el malentendido es instructivo.

La mayoría de quienes citan Radical Candor se quedan con la mitad del desafío directo y olvidan que Scott insiste en algo más incómodo: la claridad no la mides tú. La mides en si la otra persona recibió lo que quisiste decir. Scott cuenta un episodio de Steve Jobs sobre criticar sin poner en duda la confianza en las capacidades del otro, "dejando poco espacio a la interpretación", y admite que eso es difícil. La dificultad no está en ser directo. Está en que "poco espacio a la interpretación" es un objetivo que depende del sistema de significados del receptor, no del tuyo.

Ser más brutalmente honesto no reduce ese espacio. Lo amplía. Cuanto más cargada emocionalmente es la frase, más se activa la conversación de identidad, y más margen tiene el ingeniero para interpretarla como un juicio sobre su valía. La honestidad sin calibración no es transparencia. Es ruido con más volumen.

Dónde vive realmente el contexto que necesitas

Aquí es donde el diagnóstico cambia la solución por completo.

Si el problema fuera que no eres suficientemente claro, la solución sería mejorar tu redacción. Escribir comentarios más precisos, más neutrales, más técnicos. Y sí, ayuda. Pero no ataca la raíz, porque la raíz no está en tu mensaje. Está en el modelo de significado del receptor, y ese modelo tú no lo tienes.

Lo tiene él.

Lo cual sugiere una inversión incómoda: si el contexto que determina cómo se recibe tu feedback vive en la cabeza del ingeniero, tu trabajo no es afinar la emisión. Es acceder a ese contexto antes de emitir. Y solo hay una forma de acceder a lo que alguien piensa: preguntar.

Nonviolent Communication, de Marshall Rosenberg, ofrece la mecánica más útil que conozco para esto, aunque su nombre suene a taller de fin de semana. Rosenberg separa la observación del juicio. "Esta función tiene ocho responsabilidades distintas" es una observación. "Esta función está sobreingenierizada" es un juicio. El primero describe algo verificable en el mundo. El segundo describe tu valoración de ese algo —y las valoraciones son precisamente lo que el receptor va a interpretar contra su propia identidad.

Cuando empiezas por la observación verificable, le das al ingeniero un punto de anclaje que no ataca su modelo de sí mismo. "Cuento ocho responsabilidades aquí. ¿Cómo llegaste a agruparlas así?" no dice nada sobre su competencia. Abre la conversación de los hechos sin disparar la de identidad. Y su respuesta te entrega justo lo que no tenías: su modelo de significado. Ahora sabes si agrupó por prisa, por una restricción que desconoces, o porque no tiene el principio de diseño interiorizado. Tres problemas distintos que requieren tres respuestas distintas, y que desde fuera parecían idénticos.

El code review como conversación, no como veredicto

De aquí sale un sistema que puedes aplicar en el próximo PR que revises, sin herramientas nuevas y sin cambiar tu proceso.

Empieza cada comentario de feedback técnico por lo observable, no por tu conclusión. En lugar de "esto está mal factorizado", describe qué ves: cuántas dependencias, qué acoplamiento concreto, qué caso no cubierto. Lo observable es discutible sin que nadie tenga que defender su valía.

Convierte tu juicio en pregunta cuando el juicio dependa de contexto que no tienes. La mayoría de las veces lo desconoces. "¿Qué te llevó a resolverlo por aquí?" no es blandura ni rodeo. Es la única forma de recuperar la información que te falta antes de decidir si tu feedback siquiera aplica. Marquet, en Turn the Ship Around, describe cómo tuvo que aceptar no ser el experto técnico de cada sistema del submarino y confiar en que la tripulación le aportara los detalles. El code review funciona igual: tú ves el código, pero el ingeniero ve las restricciones bajo las que lo escribió.

Reserva el juicio directo para cuando ya tienes el contexto. Después de escuchar su razonamiento, si sigues pensando que hay un problema, dilo con claridad. Ahora el desafío directo de Scott funciona, porque cae sobre una conversación de hechos que ya abriste, no sobre una identidad que acabas de emboscar.

Las conversaciones que importan no las tengas por escrito. Scott es explícita en esto: el buen feedback ocurre hablando, en persona. Un comentario de una línea en un PR sirve para lo trivial. Para lo que toca cómo alguien diseña, cómo piensa, cómo se ve a sí mismo como ingeniero, el canal asíncrono amplifica la mala interpretación en lugar de reducirla. Ahí abres un 1:1.

Nada de esto elimina la incertidumbre. Seguirás sin tener acceso completo a cómo interpreta cada persona tus palabras. Pero dejas de fingir que lo tienes. Construyes el feedback como un intercambio que revela el contexto que te falta, en vez de como una transmisión que asume un contexto que no existe.

Esta semana, en el próximo comentario técnico que estés a punto de escribir, para antes de dar enter. Lee lo que has puesto y pregúntate una sola cosa: ¿esto describe algo que cualquiera podría verificar en el código, o describe mi conclusión sobre ello? Si es lo segundo, no lo has observado todavía. Lo has juzgado. Y el ingeniero al otro lado lo va a notar antes que tú.

Cada semana analizo un problema real de liderazgo técnico. Con el mismo nivel de profundidad.

Suscribirse →