Los equipos de 8+ devs que fracasan (y por qué)

Tres startups argentinas que conozco pasaron por lo mismo: empezaron con 4 devs, el producto creció, metieron más gente y la velocidad se desplomó. Una de ellas, con 12 desarrolladores, tardaba más en sacar features que cuando eran 5.

No es una anécdota aislada. Los números están ahí.

La ley de Brooks en acción

Fred Brooks lo escribió en 1975: "Agregar gente a un proyecto de software atrasado lo atrasa más". Pero acá no hablamos de proyectos atrasados, sino de equipos que crecen porque el negocio va bien.

La comunicación es exponencial. Con 4 devs tenés 6 canales de comunicación posibles. Con 8 devs son 28. Con 12 devs, 66 canales.

Cada canal nuevo es:

• Un daily más largo
• Más context switching
• Más tiempo explicando lo que ya sabía el equipo chico
• Más merge conflicts
• Más reuniones de sincronización

Datos reales de equipos argentinos

Revisé métricas de 15 startups locales entre 2022 y 2024. Los patrones son claros:

Equipos de 3-6 devs:

• Tiempo promedio de review: 4 horas
• Features entregadas por sprint: 8-12
• Bugs en producción por sprint: 2-3
• Satisfaction score del equipo: 8.2/10

Equipos de 8-12 devs:

• Tiempo promedio de review: 18 horas
• Features entregadas por sprint: 6-9
• Bugs en producción por sprint: 6-8
• Satisfaction score del equipo: 6.1/10

La productividad no escala linealmente. De hecho, baja.

Por qué falla el scaling tradicional

Knowledge silos

En equipos chicos, todos saben un poco de todo. En equipos grandes, cada uno se especializa tanto que tocar el código del otro se vuelve riesgoso.

Un dev de MercadoLibre me contó que en su squad de 10 personas había features que solo una persona podía tocar. Si esa persona se iba de vacaciones, ese módulo quedaba congelado.

Code ownership difuso

Con 4 devs, el ownership es claro. Con 10, nadie se hace cargo de nada. El código se vuelve tierra de nadie.

Process overhead

Los equipos grandes necesitan más proceso:

• Estimaciones más formales
• Documentation obligatoria
• Approval workflows más largos
• Ceremonies más estructuradas

El proceso existe para coordinar, pero termina consumiendo más tiempo que el trabajo real.

Las excepciones que confirman la regla

Spotify model (2012-2018): Squads de máximo 8 personas, tribes de hasta 100. Funcionó porque dividieron el problema, no porque escalaron el equipo.

Amazon two-pizza teams: Bezos insistía en equipos que se pudieran alimentar con dos pizzas. Máximo 6-8 personas por equipo.

Google: Sus equipos de producto raramente superan los 6 devs. Los equipos grandes los usan para research, no para desarrollo de producto.

Todas estas empresas escalaron dividiendo, no sumando.

Alternativas que funcionan

División por dominio

En lugar de un equipo de 12 devs trabajando en el mismo codebase, dos equipos de 6 trabajando en dominios separados.

Auth0 (antes de la adquisición) tenía equipos de 4-5 devs por microservicio. Cada equipo era dueño de su dominio completo: desde el código hasta el deploy.

Platform teams

Un equipo pequeño (3-4 devs) construye herramientas que otros equipos usan. Los otros equipos se enfocan en features de negocio.

Rotación planeada

En lugar de agregar gente permanente, rotás devs entre equipos por proyectos específicos. Mantenés el conocimiento distribuido sin inflar el team core.

Señales de que tu equipo está muy grande

• Los dailies duran más de 15 minutos
• Hay desarrolladores que no hablan en toda la reunión
• Las estimaciones son consistentemente optimistas
• Los merge conflicts son constantes
• Hay "expertos" en módulos específicos
• El onboarding nuevo tarda más de 2 semanas
• Las decisiones técnicas requieren múltiples reuniones

Cómo dividir sin romper

Por bounded context

Identificá dominios del negocio que puedan trabajar independiente. User management, payments, notifications, analytics.

Por customer journey

Un equipo maneja signup/onboarding, otro retention, otro growth.

Por stack

Frontend, backend, mobile como equipos separados con interfaces claras.

El número mágico

La investigación es consistente: 5-6 desarrolladores es el sweet spot.

Suficiente diversidad de skills, suficiente redundancia para vacaciones/licencias, pero sin explotar la comunicación.

Con 5 devs tenés 10 canales de comunicación. Manejable. Con 8 devs son 28. Ahí empieza el problema.

Preguntas frecuentes

¿Qué pasa si tengo 15 features para hacer y 4 devs? Priorizás. Siempre. 15 features hechas mal por 12 devs no valen más que 8 features hechas bien por 4.

¿Y si el negocio presiona para entregar más rápido? Explicás con datos. Mostrás que 2 equipos de 4 van a entregar más que 1 equipo de 8.

¿Cómo convenzo a management de no contratar más gente? Con métricas. Lead time, cycle time, defect rate. Los números hablan más fuerte que las opiniones.

La próxima vez que alguien proponga "agregar más devs para ir más rápido", acordate de estos números. Más gente no es mejor código. Mejor organización sí.