🎖️La Ley de Brooks
Por qué sumar gente a un proyecto retrasado lo retrasa aún más
Hola 👋 bienvenido a la Newsletter de 🎖️Team Hackers.
Soy Felipe Polo y escribo esta newsletter para ayudar a fundadores y operadores de compañías a generar autonomía y equipos más fuertes.
Hay un patrón que veo en muchas empresas que crecen: el proyecto se atrasa, el CEO pide más manos, y el proyecto entonces se retrasa aún más.
Bueno, pues esto tiene una explicación matemática. Hoy te presento la Ley de Brooks.
En los años 60, IBM lanzó el proyecto OS/360. Más de 1.000 desarrolladores y presupuesto ilimitado. Todo el talento que el dinero podía comprar.
El resultado: años de retraso, caos de coordinación, y un sistema que se convirtió en el ejemplo de lo que no hay que hacer en gestión de proyectos.
Mientras tanto, en Bell Labs, tres personas (Thompson, Ritchie y un colega) crearon UNIX y el lenguaje C en aproximadamente un año. La base de iOS, macOS, Linux, Android.
Medio siglo de tecnología creado por 3 tipos en 1 año.
Fred Brooks, el gerente del proyecto OS/360, sacó la lección y la formalizó en The Mythical Man-Month: "Agregar más personas a un proyecto retrasado solo lo retrasa más."
La llamó una "frívola sobresimplificación." Pero lleva 50 años cumpliéndose.
Por qué ocurre: las tres trampas
1. El ramp-up es real y caro.
Cada persona nueva necesita contexto, formación, explicaciones. Mientras absorben información, no producen. Y los que sí producían ahora están enseñando en vez de avanzando.
El resultado neto puede ser negativo durante semanas. Has sumado capacidad teórica y restado capacidad real.
2. La comunicación crece cuadráticamente.
Aquí entra la matemática que mata. Con 2 personas, hay 1 canal de comunicación. Con 5, hay 10. Con 10, hay 45.
La fórmula es simple: n(n-1)/2. Cada persona nueva no suma un canal, suma tantos como personas ya había en el equipo.
Más canales significan más reuniones, más malentendidos, más fricción.
El esfuerzo de coordinación crece de forma cuadrática mientras la capacidad de trabajo crece de forma lineal.
3. Hay tareas que no se pueden dividir.
El corolario clásico: nueve mujeres no pueden tener un bebé en un mes.
Hay procesos que requieren continuidad, conocimiento profundo, o una única visión. No importa cuántas manos pongas: el tiempo mínimo es el que es. Y meter gente en una tarea indivisible solo añade coordinación sin añadir velocidad.
Más allá de los genios de Bell Labs
Podrías pensar que UNIX fue una rareza irrepetible. Tres mentes brillantes en un laboratorio legendario.
Pero en 2014, WhatsApp operaba con 55 empleados atendiendo a más de 450 millones de usuarios activos mensuales. Sin ejército de managers, sin burocracia. La clave no era sumar gente, sino sostener un equipo pequeño, enfocado, con una arquitectura pensada para escalar.
Y al revés: una empresa de software documentada por Agile Minds redujo su equipo por reestructuración y vio cómo la productividad aumentó. Al eliminar el equipo de arquitectura separado, los desarrolladores tomaban esas decisiones sin esperar aprobaciones. Cerraban más tickets con menos gente.
Cuándo la ley se puede romper
Brooks no pretendía que su ley fuera una condena. Hay condiciones donde sumar gente sí funciona:
- En fases tempranas. Si detectas que necesitas refuerzos antes de que el cronograma esté comprometido, puedes integrar personas sin tanto daño. La clave es hacerlo cuando aún hay tiempo de absorber el costo de incorporación.
- En áreas paralelas. Sumar personas para testing, documentación o soporte (tareas separables del núcleo) libera al equipo central sin añadir canales de comunicación al trabajo crítico.
- Con profesionales que ya conocen el terreno. Un desarrollador senior que domina el stack o el negocio aporta valor casi de inmediato. El caso de Healthcare.gov en 2013 lo demostró: ingenieros de élite rescataron en semanas lo que no se había logrado en meses. La diferencia: llegaron sabiendo y no necesitaron onboarding.
- Con arquitectura modular. Si el proyecto está bien segmentado, los equipos pueden trabajar en paralelo con mínima interdependencia. Linux escala con miles de colaboradores porque el núcleo lo mantiene un grupo pequeño y el resto trabaja en módulos separados.
El patrón es claro: sumar gente funciona cuando reduces la necesidad de coordinación entre las personas que sumas.
Lo que ningún CEO quiere escuchar
Steve McConnell, uno de los ingenieros de software más respetados, hizo una pregunta incómoda: "Agregar personal lo retrasa… ¿lo retrasa con respecto a qué?"
Si la estimación original ya era fantasiosa (y la mayoría lo son: el proyecto de software promedio acaba un 120% por encima del plazo), el retraso no viene de sumar gente. Viene de haberse mentido sobre el plazo desde el día uno.
Eso no invalida a Brooks sino que lo complementa. Y es que el problema suele ser doble: una estimación irreal y una solución instintiva (más manos) que no ataca la causa real.
Jeff Bezos lo operacionalizó con la regla de las dos pizzas: ningún equipo debería ser tan grande que no pueda alimentarse con dos pizzas.
La idea no es la pizza. Es que los equipos pequeños se coordinan mejor, deciden más rápido y producen con menos fricción.
Qué hacer en la práctica
1. Antes de sumar gente, pregunta por qué estás retrasado. ¿Es un problema de alcance? ¿De estimación? ¿Un cuello de botella técnico? Si la causa es estructural, más personas no la resuelven.
2. Si vas a hacer crecer el equipo, modulariza primero. Divide el trabajo en bloques autónomos. Cada sub-equipo debería poder avanzar sin depender del resto.
3. Valora el coste de incorporación. ¿El tiempo que dedicarás a explicar vale más que lo que el nuevo sumará en el plazo que queda? Si la respuesta es sí, pospón la incorporación.
4. Acepta que hay cosas que no se aceleran. Algunos problemas necesitan tiempo, no personas.
5. Invierte en efectividad del equipo actual. Elimina obstáculos, reduce reuniones innecesarias, automatiza lo repetitivo. A veces optimizar al equipo que ya tienes rinde más que duplicar la plantilla.
La Ley de Brooks no dice que nunca puedas hacer crecer tu equipo. Dice que crecer un equipo bajo presión y sin estructura, es una receta para multiplicar los problemas que intentas resolver.
La pregunta correcta no es "¿cuánta gente necesito?" sino "¿cuánta coordinación puedo absorber sin que el sistema colapse?"
¿Alguna vez sumaste gente a un proyecto retrasado y funcionó? Me encantaría saber qué fue diferente en ese caso.