Saltar al contenido
Pensamiento

Producto · Reflexión

El equipo no funcionaba (y el problema no era técnico)

Todos eran buenos técnicamente y el equipo no funcionaba. Reuniones sin decisión, un cuello de botella y feedback que llega tarde. Ninguno de los tres problemas es técnico, y todos son evitables si alguien los nombra a tiempo.

Publicado
Lectura
3 min
Autor
Daniel Chies Porras
Portada: Todos eran buenos técnicamente. El equipo no funcionaba.
Reuniones sin decisión: una reunión sin decisión es una conversación cara.
El cuello de botella: todo pasa por una sola persona. Cuando para, para el equipo.
Feedback que llega tarde: el feedback útil llega el primer día.
Lo que tienen en común: humano, no técnico. Todos son evitables si alguien los nombra a tiempo.

No era un problema de #skills. Era un problema de dinámica.

Con el tiempo he identificado los patrones que se repiten casi siempre cuando un equipo tech no rinde lo que debería:

Reuniones sin decisión La reunión termina, todos asienten y nadie sabe exactamente qué tiene que hacer mañana. Se convoca otra reunión para aclarar la anterior. Y así.

Una reunión sin una decisión tomada o una tarea asignada es una conversación cara. En tiempo y en foco. Si al acabar no puedes escribir en tres líneas qué se decidió y quién hace qué, la reunión no debería haber existido.

El que sabe más se convierte en cuello de botella Hay alguien en el equipo que entiende el sistema por dentro mejor que nadie. Todo pasa por él. Preguntas, revisiones, decisiones técnicas. Cuando ese perfil está bloqueado, el equipo entero para.

Ese conocimiento concentrado en una sola persona es el riesgo más silencioso que existe en un equipo tech. Y casi siempre ocurre sin que nadie lo haya planificado.

Feedback que llega tarde El developer lleva tres días construyendo algo en una dirección. Cuando lo enseña, resulta que no era lo que se esperaba. Se rehace. Se pierde tiempo, se pierde motivación.

El feedback útil es el que llega antes de que el trabajo esté terminado. No cuando ya hay que deshacerlo todo.

Métricas de actividad en vez de impacto Medir quién hace más commits, quién responde más rápido en Slack, quién está más horas conectado. Todo eso mide actividad — NO resultado.

Un equipo que optimiza para parecer ocupado y un equipo que optimiza para entregar valor se comportan de forma completamente diferente. Y se nota en el producto.

Conflictos que no se nombran Hay tensión entre dos personas del equipo. Todo el mundo lo sabe. Nadie lo dice. El problema crece por debajo hasta que explota en el peor momento posible.

Los equipos que funcionan no tienen menos conflictos. Tienen mejores formas de gestionarlos antes de que se conviertan en un problema real.

Lo que tienen en común todos estos errores: Ninguno es técnico. Todos son humanos. Y todos son evitables si alguien en el equipo los nombra a tiempo.

  • ¿Cuál de estos errores has vivido más en equipos donde has trabajado?
  • ¿Cómo gestionas tú el conocimiento concentrado en una sola persona?
  • ¿Hay algún error de dinámica de equipo que añadirías a la lista?

Lo que cuentan las diapositivas

Todos eran buenos técnicamente. El equipo no funcionaba.

Reuniones sin decisión

  • Reunión 1: sin decisión.
  • Reunión 2: aclarar la 1.
  • Reunión 3: …

Una reunión sin decisión es una conversación cara.

El cuello de botella

Todo pasa por una sola persona. Cuando para, para el equipo.

Feedback que llega tarde

Día 1, día 2, día 3… y al final: «No era lo que esperábamos». El feedback útil llega el primer día, no cuando ya está todo construido.

¿Terminado es que funciona en local? ¿Que pasó testing? ¿Que está en producción?

Lo que tienen en común

Humano. No técnico. Ninguno es técnico. Todos son evitables si alguien los nombra a tiempo.