Escalar de 10 a 50 ingenieros no es multiplicar personas. Es cambiar cómo funciona la organización. Los equipos pequeños se comunican por instinto. Los equipos grandes necesitan estructura. Quien ignora este cambio pierde velocidad en proporción al tamaño que alcanza.
Estructura de squads: 5 a 8 personas por dominio
Cada squad debe ser autónomo dentro de su dominio de negocio. Tamaño ideal: 5 a 8 ingenieros. Lo suficientemente grandes para entregar valor por sí solos, lo suficientemente pequeños para mantener comunicación directa. Los squads por dominio (pagos, registro, búsqueda) evitan la dependencia entre equipos para cada funcionalidad.
Sin squads definidos, las decisiones quedan centralizadas en el CTO. Con squads autónomos, las decisiones ocurren más cerca de quien ejecuta. El cambio de velocidad es visible en semanas.
Equipo de plataforma interna: 2 a 4 ingenieros
Un equipo pequeño dedicado a herramientas compartidas: CI/CD, monitoreo, bibliotecas internas, ambientes de prueba. Sin esto, cada squad reinventa la rueda. Con esto, los squads se enfocan en el producto y reciben herramientas consistentes.
El equipo de plataforma no es un centro de servicios. Es un equipo de producto cuyo cliente es la ingeniería. Métricas de éxito: tiempo de deploy reducido, incidentes menos frecuentes, onboarding de nuevos ingenieros más rápido.
Distribución de decisiones técnicas
Crea una guía que defina qué deciden los squads por sí solos (elecciones de framework dentro del squad, diseño de APIs internas, patrones de prueba locales) y qué requiere alineamiento (cambios de infraestructura, nuevas dependencias de alto impacto, decisiones de seguridad).
Esa guía elimina cuellos de botella. Sin ella, todo pasa por el CTO. Con ella, el CTO solo participa cuando la decisión realmente afecta a toda la organización.
Regla del 15% para calidad técnica
Reserva 15% de la capacidad de cada squad para trabajo que no genera funcionalidades: refactorización, pruebas, documentación, actualización de dependencias. No como proyecto puntual, sino como práctica continua.
Los equipos que no reservan ese espacio llegan en 18 meses al punto en que las nuevas funcionalidades exigen tanto trabajo de estabilización que el producto se detiene. La prevención cuesta menos que la corrección.
Programa de onboarding de 30 días
Primera semana: ambiente funcionando, primer commit, entendimiento del dominio. Segunda y tercera semanas: trabajar en tickets reales con mentoría. Cuarta semana: presentar una mejora que el nuevo ingeniero identificó.
Un buen onboarding no se trata de documentación. Se trata de una experiencia guiada que genera confianza y contexto. Los ingenieros con buen onboarding permanecen más tiempo y contribuyen más rápido.
Medir resultados, no velocidad
Velocity es una métrica de equipo, no de organización. Los resultados que importan: tiempo de ciclo de funcionalidad (del pedido al deploy), tasa de bugs en producción, tiempo medio de recuperación de incidentes, satisfacción del equipo.
Estas métricas cuentan la historia real de la organización. Velocity solo cuenta cuántos puntos se cerraron, sin decir si el producto mejoró.
