Equipos grandes, energía de equipo pequeño
En esta página
Cada pocos años, IEEE Spectrum publica otra autopsia de desastres informáticos1. La última suma más de 2 billones de dólares al año solo en costes de fallos de software en EE. UU. Los casos de estudio resultan tristemente familiares.
El sistema de nóminas Phoenix de Canadá se hinchó de CA$310 millones a $5,1 mil millones y dejó al 70% de los empleados federales con errores en su paga. El sistema Horizon de la oficina de Correos británica mandó a gente inocente a la cárcel mientras la dirección tapaba errores que sabía que existían.
He trabajado en organizaciones que habrían entrado en la lista si alguien se hubiera molestado en documentarlas.
Retrospectivas que no llevan a ningún sitio
Los proyectos se descarrilan. Llega la prisa. Y luego una retrospectiva que pregunta “¿qué pueden hacer distinto los desarrolladores?”, nunca la dirección.
He estado en esas retrospectivas. Las de siempre, donde todos saben qué salió mal (el alcance cambió tres veces, la fecha límite se fijó antes de que existieran los requisitos, alguien añadió un manager para “ayudar a coordinar” y de repente pasas más tiempo en reuniones diarias que escribiendo código), pero nadie lo dice porque decirlo es admitir que el problema es la estructura.
Para el poder que tienen sobre cómo se organizan los equipos y los procesos, los mandos intermedios casi no responden de los resultados. Te ahorrarías miles de millones y dispararías la productividad si la dirección fuera mínima y rindiera cuentas como todos los demás.
El impuesto de la capa de gestión
Los proyectos grandes no fracasan porque los ingenieros no sepan programar. Fracasan porque cada capa de gestión añade latencia, diluye la responsabilidad y crea incentivos que no van alineados con entregar software que funcione.
El patrón es previsible:
El proyecto recibe presupuesto. El presupuesto justifica plantilla. La plantilla requiere managers. Los managers requieren proceso. El proceso requiere reuniones. Las reuniones requieren documentación. La documentación requiere ciclos de revisión.
En algún punto de esa cadena, alguien tenía que estar escribiendo software.
Cada capa existe para coordinar la de abajo. Pero coordinar tiene un coste: el contexto se pierde en la traducción, las decisiones se retrasan esperando aprobación y la responsabilidad se disuelve en un comité. Cuando algo se rompe, hay tanta gente implicada que nadie es claramente responsable.
El sistema de nóminas Phoenix tenía 80.000 reglas de pago que implementar. Pero las reglas no eran el problema. El problema era una organización donde la información pasaba por tantas capas que nadie arriba entendía lo que ocurría de verdad abajo hasta que fue demasiado tarde.
Por qué funcionan los equipos pequeños
Los equipos pequeños rinden más que los grandes. No porque tengan mejores ingenieros, sino porque tienen:
- Ciclos de feedback cortos. Entregas algo y ves el resultado.
- Responsabilidad clara. Cuando algo se rompe, todos saben quién lo arregla.
- Comunicación directa. Nada de teléfono estropeado a través de tres capas de gestión.
Linear alcanzó una valoración de $1,25 mil millones con 100 empleados y 2 PMs. Sin tests A/B. Sin paneles de crecimiento. Sin sprint planning. Sin OKRs para los ICs. Solo equipos pequeños de diseñadores e ingenieros que piensan como gente de producto.
El producto se vende solo porque funciona. Y funciona porque casi no hay nada entre quienes toman las decisiones y quienes escriben el código. A menudo son las mismas personas.
Eso no es casualidad. Es el objetivo.
El error no es crecer, es cómo creces
La lección no es que las organizaciones deban quedarse pequeñas para siempre. Algunos problemas exigen escala.
El error es tirar de capas de gestión antes de necesitarlas. Nombrar un “director de ingeniería” cuando tienes 8 ingenieros. Crear una “oficina de gestión de proyectos” porque dos proyectos se solaparon una vez. Contratar managers para gestionar managers antes de haber demostrado que hace falta siquiera la primera capa.
Cada capa que añades es una apuesta a que el coste de coordinar compensa el beneficio de coordinar. La mayoría de las organizaciones pierden esa apuesta y ni se enteran.
Escribí sobre esto desde otro ángulo en mi post sobre Workforce Engineering en flowstate2. El problema de la mayoría de los líderes tecnológicos no es que no sepan lo que pasa, sino que han construido sistemas en los que la información tiene que atravesar tantas capas que saber se vuelve imposible.
La respuesta no es más managers. Es mejor visibilidad.
Cuando de verdad necesites escalar más allá de lo que puede hacer un solo equipo, el objetivo debería ser conservar la dinámica del equipo pequeño con herramientas, en vez de gestionar la complejidad con jerarquía. Haz visible la información por defecto. Deja que los equipos sean dueños de los resultados de principio a fin. Da autonomía a los líderes de ingeniería para coordinarse directamente.
En flowstate estamos construyendo justo eso: una plataforma de Workforce Engineering que da visibilidad a las organizaciones sin crear jerarquías de reporte. Que saca a la luz los bloqueos sin exigir reuniones de estado. Que mantiene informada a la dirección sin convertirla en un cuello de botella.
La oportunidad de 2 billones de dólares
Todo el mundo sabe qué falla. Arreglarlo exige que quienes tienen el poder se pongan límites a sí mismos.
Los mandos intermedios existen porque es lo que se hace por defecto. Porque siempre se ha hecho así. Porque los presupuestos grandes parecen necesitar equipos grandes y los equipos grandes parecen necesitar capas.
Pero la evidencia es abrumadora. Las organizaciones que queman miles de millones en proyectos fallidos tienen miles de empleados. Las que lanzan productos que funcionan suelen tener decenas.
La diferencia no es el talento. Es la estructura.
En algún momento tenemos que dejar de esperar resultados distintos.