Feedback técnico, pull requests e incidentes: el Human Stack que nadie documenta
Un comentario en el pull request puede cuidar la calidad o activar una defensa. El feedback técnico mejora cuando separas el código, la interpretación y la conversación.
Hugo Casanova· Coach ICF · Facilitador RECOProgramando· Actualizado 6 min de lectura
El comentario dice “esto está mal” y el pull request queda quieto toda la tarde. Quien lo escribió piensa que fue directo. Quien lo recibió escucha una sentencia sobre su capacidad. En el equipo técnico, la calidad del trabajo depende también de cómo conversamos sobre decisiones, errores y riesgos.
El código no es la conversación completa
Una revisión puede señalar un comportamiento, explicar un riesgo y abrir una alternativa. También puede mezclar una preferencia personal con una regla del sistema y presentarla como verdad. Antes de escribir feedback, pregunta qué estás protegiendo: seguridad, mantenibilidad, claridad, tiempo o simplemente la costumbre de hacerlo a tu manera.
Cómo conversar sin suavizar el problema
Cuidar la conversación no significa convertir cada observación en un elogio. Significa describir el comportamiento, explicar su impacto y preguntar qué alternativa ve la otra persona. En un incidente, separar el hecho de la culpa permite aprender más rápido. En un pull request, distinguir bloqueo de sugerencia permite decidir qué debe cambiar y qué puede discutirse después.
El feedback también revela tu patrón
Tal vez corriges todo porque temes que el resultado se asocie contigo. Tal vez evitas comentar para que nadie piense que eres difícil. Tal vez recibes una observación como amenaza y respondes con una explicación de diez párrafos. Ver ese patrón no elimina la exigencia técnica; te permite elegir una respuesta que cuide el estándar y la capacidad del equipo.
Puedes practicar este Human Stack en Tech Lab. Conecta con las habilidades blandas que sí se entrenan y con feedback laboral. Consulta también las próximas experiencias.
Una práctica para la siguiente revisión
Escribe primero qué observaste sin adjetivos. Después qué riesgo o impacto ves. Finalmente formula una pregunta o propuesta que permita decidir. Si el cambio es necesario, dilo con claridad. Si es una preferencia, nómbrala como tal. La precisión técnica gana fuerza cuando la conversación deja de obligar al otro a defender su identidad.
La claridad protege a ambas partes
Un equipo que evita el feedback acumula decisiones silenciosas. Después aparecen bugs, resentimiento y revisiones que parecen personales porque llegan demasiado tarde. La claridad temprana puede incomodar, pero permite que la otra persona responda mientras el cambio todavía es pequeño. Por eso conviene comentar cerca del comportamiento observable y conversar en vivo cuando el hilo ya carga demasiada interpretación.
También necesitas recibirlo. Antes de explicar por qué elegiste una solución, pregunta qué impacto tuvo para quien la revisó. A veces el comentario técnico señala una deuda; otras veces revela que tu decisión no fue suficientemente visible. Hacer espacio para esa lectura no significa aceptar todo, significa ganar información para decidir con más criterio.
Una práctica sencilla: en la próxima revisión, separa comentarios bloqueantes, preguntas y preferencias. Pide que el equipo haga la misma distinción contigo. El estándar técnico puede mantenerse alto sin que cada desacuerdo se convierta en un juicio sobre la persona. Esa es la conversación que sostiene calidad cuando la IA acelera la producción y vuelve más importante saber revisar.
La revisión es una práctica de equipo, no una prueba de carácter
Si cada pull request depende del estilo de una sola persona, el equipo aprende a esperar aprobación en vez de compartir criterio. Definir qué significa bloquear, qué se conversa y qué se documenta reduce esa dependencia. También hace más fácil que alguien nuevo participe sin adivinar qué tono debe usar. La calidad técnica mejora cuando el equipo puede discutir decisiones sin que cada comentario tenga que proteger el ego de quien escribe o de quien recibe.
El Human Stack no compite con la profundidad técnica. La vuelve más sostenible porque permite que el conocimiento circule, que los riesgos se nombren y que las decisiones puedan ser revisadas. Un equipo que conversa mejor no evita los desacuerdos: los convierte en información antes de que lleguen convertidos en incidentes.
Preguntas frecuentes
- ¿Cómo dar feedback técnico sin generar conflicto?
- Describe el comportamiento observable, explica el impacto o riesgo y abre una alternativa. Evita atribuir intenciones y distingue un bloqueo de una sugerencia.
- ¿Qué habilidades humanas necesita un developer?
- Escucha, comunicación clara, colaboración, criterio, capacidad para pedir ayuda, recibir feedback y tomar decisiones con información incompleta.
- ¿Tech Lab trabaja feedback para equipos tech?
- Sí. Tech Lab trabaja situaciones reales de colaboración, comunicación, adaptabilidad y liderazgo para personas del ecosistema tecnológico.
Sigue explorando
¿Te gustó este artículo? Compártelo


