De 10 a 50 ingenieros, el equipo deja de comunicarse por instinto. Los equipos pequeños resuelven cosas en el pasillo; los equipos grandes necesitan estructura escrita. Una organización que contrata a 40 personas manteniendo el método antiguo pierde la velocidad que tenía y asume el costo del tamaño nuevo.
Squads de 5 a 8 personas por dominio
Cada squad cubre un dominio de negocio, como pagos, cuentas o búsqueda, y entrega solo dentro de él. De 5 a 8 ingenieros: grande bastante para salir solo, pequeño bastante para hablar de frente. Un dominio compartido evita que cada feature dependa de otro equipo.
Un squad definido cambia dónde ocurre la decisión. Sin squad, la decisión sube al CTO. Con squad, ocurre junto a quien ejecuta, y el cambio aparece en la velocidad en semanas.
Matthew Skelton y Manuel Pais clasifican a ese equipo como stream-aligned en Team Topologies (IT Revolution, 2019) y señalan la carga cognitiva de cada equipo, y no el número de personas, como la restricción real de una organización grande. Congelar el squad en ocho personas o menos es la defensa más simple contra esa restricción.
Un equipo de plataforma de 2 a 4 ingenieros
Un equipo pequeño se ocupa de lo compartido: CI/CD, monitoreo, bibliotecas internas, ambientes de prueba. Sin él, cada squad reconstruye la misma herramienta y repite la misma discusión. Con él, el squad vuelve al producto.
Trata a ese equipo como un equipo de producto con cliente interno. Sus métricas: bajó el tiempo de deploy, desaparecieron los incidentes repetidos, se acortó el onboarding de gente nueva. Skelton y Pais lo llaman platform team y definen su servicio como reducir la carga de quienes están en la primera línea.
Una guía de lo que cada squad decide
Escribe lo que el squad resuelve solo: framework dentro del squad, diseño de API interna, patrones de prueba locales. Escribe lo que pide alineación: cambios de infraestructura, dependencias nuevas de alto impacto, decisiones de seguridad.
La guía elimina la cola. Sin ella, todo sube hasta ti y la semana se vuelve triage. Con ella, entras en decisiones que cambian a toda la organización.
Una reserva del 15% para calidad técnica
Reserva el 15% de la capacidad de cada squad para trabajo que no genera feature: refactorización, tests, documentación, actualización de dependencias. Entra en la planificación de cada sprint como práctica continua.
El libro de Google SRE (Beyer et al., O'Reilly, 2016) define toil como trabajo manual y repetible que podría automatizarse y lo limita a menos de la mitad del tiempo de trabajo. Un squad que no reserva ese 15% llega en 18 meses a un punto donde cada feature nueva pide tanta estabilización que el producto se detiene.
Onboarding de 30 días
Semana 1. Ambiente arriba, primer commit, lectura del dominio. Semanas 2 y 3. Tickets reales con mentoría y revisiones comentadas. Semana 4. Presentación de una mejora que el propio ingeniero encontró.
La documentación sola no hace onboarding. Quien entra con alguien al lado entiende el sistema en dos semanas y se queda más tiempo en el puesto.
Medir resultados en lugar de velocity
Velocity cuenta puntos cerrados dentro de un equipo y no dice si el producto mejoró. Reemplázala por cuatro lecturas: tiempo de ciclo de los cambios, frecuencia de deploy, tiempo medio de recuperación y tasa de fallo de cambios.
Forsgren, Humble y Kim recomiendan esas cuatro métricas en Accelerate (IT Revolution, 2018) y muestran que se mueven junto con el desempeño de la organización. Bugs en producción y satisfacción del equipo quedan al lado como lectura secundaria.
