Por qué la comunicación es el cuello de botella real en equipos de desarrollo
En la mayoría de los equipos tech, los problemas técnicos se resuelven. Los problemas de comunicación, en cambio, se acumulan. Un pull request rechazado con un comentario ambiguo, una retrospectiva donde nadie dice lo que realmente piensa, un acuerdo de arquitectura que cada persona interpretó distinto: estas situaciones no son accidentes, son síntomas de un equipo que no ha desarrollado sus habilidades de comunicación al mismo ritmo que sus habilidades técnicas.
En Lima, donde los equipos tech conviven con culturas organizacionales muy jerárquicas y con la presión de entregar en sprints cortos, la comunicación asertiva no es un lujo de soft skills. Es una competencia crítica. Cuando no existe, aparecen los silos, la deuda de conversaciones pendientes y, eventualmente, la rotación de talento. Cuando existe, los equipos entregan mejor, con menos fricción y con mayor bienestar.
En RECOProgramando trabajamos con equipos de desarrollo en Lima que ya tienen buenas prácticas técnicas pero sienten que algo no fluye. Casi siempre, ese algo tiene nombre: conversaciones que no se están teniendo.
- Los conflictos no resueltos generan deuda técnica y deuda relacional al mismo tiempo.
- La comunicación pasiva-agresiva en code reviews destruye la confianza del equipo.
- Los acuerdos ambiguos producen retrabajo, frustración y culpas cruzadas.
- Un equipo que habla claro entrega más rápido y con menos bugs de coordinación.
Cómo dar feedback técnico que construya en lugar de bloquear
El feedback técnico es uno de los momentos de mayor riesgo comunicacional en un equipo de desarrollo. Un comentario en un code review puede leerse como un ataque personal aunque no lo sea. Una observación en una demo puede cerrar la disposición de alguien a proponer ideas en el futuro. La diferencia entre feedback que construye y feedback que bloquea no está en el contenido técnico, sino en cómo se entrega.
El primer principio es separar el comportamiento o la decisión de la persona. No es 'este código está mal', sino 'esta implementación tiene un riesgo de rendimiento en escenarios de alta concurrencia, ¿lo viste? ¿Qué alternativas exploraste?'. Esta distinción parece pequeña, pero activa un modo de escucha completamente distinto en quien recibe el comentario. La persona deja de ponerse a la defensiva y puede pensar junto contigo.
El segundo principio es la especificidad. El feedback vago ('esto no está bien hecho') genera ansiedad sin dirección. El feedback específico ('el nombre de esta variable no comunica su propósito, lo que dificulta el mantenimiento futuro') da a la persona algo concreto sobre lo que actuar. En nuestras experiencias en Lima con equipos tech, trabajamos estas distinciones con práctica real, no solo teoría.
- Usa preguntas antes que afirmaciones cuando no tienes todo el contexto.
- Describe el impacto observable, no la intención que asumes.
- El feedback en privado primero, en público solo cuando sea necesario para el aprendizaje colectivo.
- Cierra siempre con una pregunta o un siguiente paso concreto.
Recibir feedback técnico sin ponerse a la defensiva
Recibir feedback es, para muchos desarrolladores, más difícil que darlo. El código que escribimos lleva horas de pensamiento, decisiones de diseño y a veces una identidad profesional implícita. Cuando alguien lo cuestiona, el cerebro lo registra como una amenaza antes de que podamos procesarlo racionalmente. Esta reacción es humana y comprensible, pero si no se gestiona, paraliza el aprendizaje y envenena la cultura del equipo.
La clave está en desarrollar lo que desde el coaching ontológico llamamos 'escucha generativa': escuchar para comprender, no para responder. Antes de reaccionar a un comentario de code review, hazte una pregunta simple: ¿qué está intentando cuidar esta persona con este comentario? Casi siempre la respuesta es la calidad del producto, la mantenibilidad del código o el éxito del equipo. Eso cambia el marco desde el que recibes la observación.
Otro recurso práctico es la pausa activa. En lugar de responder de inmediato cuando sientes que un comentario no es justo, di: 'Déjame entender mejor tu punto antes de responder'. Esa frase sola puede evitar escaladas innecesarias. Si sientes que el estrés acumulado está afectando cómo recibes el feedback de tus pares, puede valer la pena explorar también el tema de burnout en tech, que muchas veces subyace a estas reacciones.
- Distingue entre el feedback sobre tu trabajo y el feedback sobre tu valor como profesional.
- Pide ejemplos concretos cuando el comentario te parece vago o injusto.
- Agradece antes de argumentar: baja la temperatura de la conversación.
- Es válido pedir tiempo para procesar antes de responder.
Cómo sostener conversaciones difíciles en entornos de desarrollo
Las conversaciones difíciles en equipos tech tienen formas muy específicas: decirle a un tech lead que su decisión de arquitectura está generando problemas en producción, hablar con un compañero cuyo comportamiento en las reuniones está afectando la dinámica del equipo, o plantearle al product owner que el alcance del sprint es inviable. Estas conversaciones se evitan no porque la gente sea cobarde, sino porque nadie les enseñó cómo tenerlas.
El primer paso es preparar la conversación antes de tenerla. Esto significa clarificar para ti mismo: ¿qué observé concretamente? ¿Qué impacto tuvo en mí o en el equipo? ¿Qué necesito o qué propongo? Esta estructura simple (observación, impacto, necesidad) evita que la conversación se convierta en un intercambio de interpretaciones y emociones sin ancla.
El segundo paso es elegir el contexto adecuado. Una conversación difícil en medio de una daily standup, con el equipo completo escuchando, casi nunca termina bien. Busca un espacio privado, un momento sin presión de tiempo y una actitud de genuina apertura al diálogo. En RECOProgramando facilitamos espacios donde los equipos practican este tipo de conversaciones en un entorno seguro, antes de tenerlas en la realidad. Si quieres llevar RECO a tu empresa, podemos diseñar una experiencia a medida para tu equipo.
- Prepara la conversación: observación, impacto y propuesta antes de hablar.
- Elige el momento y el espacio: privado, sin presión de tiempo.
- Comienza con curiosidad genuina, no con un veredicto.
- Escucha la perspectiva del otro antes de defender la tuya.
- Cierra con un acuerdo explícito, aunque sea pequeño.
Construir acuerdos claros que el equipo realmente cumpla
Uno de los patrones más costosos en equipos de desarrollo es el acuerdo aparente: todos asienten en la reunión, pero cada persona salió con una interpretación distinta de lo que se decidió. Esto no es mala fe, es la consecuencia de no haber explicitado el acuerdo con suficiente precisión. En entornos ágiles, donde las decisiones se toman rápido y en contextos de alta ambigüedad, este patrón se multiplica.
Un acuerdo claro tiene al menos tres componentes: qué se va a hacer, quién es responsable de que ocurra y para cuándo. Parece obvio, pero en la práctica la mayoría de los acuerdos de equipo carecen de al menos uno de estos tres elementos. Añadir un cuarto componente mejora aún más la adherencia: cómo vamos a saber que el acuerdo se cumplió. Esta pregunta obliga al equipo a pensar en criterios observables, no en intenciones.
La cultura de acuerdos claros también requiere que el equipo se sienta seguro para renegociar cuando las condiciones cambian. Un acuerdo que no se puede renegociar se convierte en una deuda de conversación. En nuestras sesiones con equipos en Lima, trabajamos el concepto de 'acuerdo vivo': un compromiso que se revisita activamente y se actualiza cuando el contexto lo exige, en lugar de ignorarse en silencio cuando ya no es posible cumplirlo.
- Todo acuerdo debe tener: qué, quién y cuándo.
- Define cómo sabrán que el acuerdo se cumplió (criterio de éxito observable).
- Documenta los acuerdos, aunque sea en dos líneas en el canal del equipo.
- Crea un espacio seguro para renegociar sin que se sienta como incumplimiento.
Desarrollar una cultura de comunicación asertiva en el tiempo
La comunicación asertiva no se instala en un taller de dos horas. Es una práctica que se construye con consistencia, con modelos a seguir dentro del equipo y con espacios donde las conversaciones difíciles sean posibles antes de que se vuelvan urgentes. Los equipos que logran esto no son equipos sin conflicto; son equipos que han aprendido a procesar el conflicto de forma productiva.
El rol del tech lead o del engineering manager es fundamental en este proceso. Cuando un líder técnico modela la comunicación asertiva, pide feedback sobre sus propias decisiones y sostiene conversaciones difíciles con transparencia, crea un permiso cultural para que el resto del equipo haga lo mismo. Cuando el líder evita esas conversaciones, el equipo aprende que evitarlas es la norma.
En RECOProgramando combinamos herramientas del coaching ontológico, la agilidad y el desarrollo humano para acompañar a equipos tech en Lima en este proceso. No trabajamos sobre síntomas aislados, sino sobre los patrones de conversación que los generan. Si tu equipo está en un momento donde la comunicación se siente como un obstáculo más que como un recurso, puede ser el momento de explorar nuestras experiencias en Lima y ver qué es posible.
- La retroalimentación regular (no solo en crisis) normaliza la conversación honesta.
- Las retrospectivas bien facilitadas son un entrenamiento de comunicación asertiva.
- Los líderes técnicos que modelan vulnerabilidad habilitan equipos más honestos.
- La seguridad psicológica no se declara, se construye conversación a conversación.
Preguntas frecuentes
Es la capacidad de expresar ideas técnicas, necesidades y observaciones con claridad y respeto, sin agresividad ni pasividad. En equipos de desarrollo implica saber dar y recibir feedback de código, sostener conversaciones difíciles con pares y líderes, y construir acuerdos que el equipo realmente entienda y cumpla.
Sigue explorando
- Liderazgo consciente en Lima
- beAgile: agilidad para habitarte a ti mismo
- Habilidades humanas para equipos tech en Lima
- Habilidades blandas para profesionales tech en Lima
- Reprogramo: reprogramación profesional para equipos tech en Lima
- RECOProgramando: (page-total) para profesionales tech en Lima
- Conflicto productivo en equipos ágiles en Lima