Org design de ingeniería: cuándo pasar de feature teams a squads y plataforma

Un VP Engineering de una scale-up SaaS chilena llega a los 45 ingenieros con la misma estructura de feature teams con la que partió en 12. Velocity cae 30 por ciento. Dos seniors renuncian en seis semanas. El roadmap Q3 se atrasa medio trimestre. La empresa cree que el problema es de talento. El problema real es de org design.

La mayoría de las scale-ups tech demora demasiado en evolucionar su estructura de ingeniería. No es por incompetencia: es porque la estructura que funcionó hasta los 30 ingenieros se siente conocida, segura y barata. La verdad incómoda es que cada umbral de tamaño exige un rediseño y los costos de no hacerlo son invisibles hasta que ya son irreversibles: deuda técnica que nadie asume, dependencias cruzadas que paralizan, on-call que se concentra en cuatro personas y burnout silencioso del Tech Lead más fuerte.

Este artículo entrega el framework operativo que IT Workers usa cuando un cliente nos pide ayudar a estructurar el área antes de abrir nuevas búsquedas. Es un mapa de cinco estructuras canónicas, sus umbrales reales, las señales que indican que toca evolucionar y los anti-patterns más comunes. Está pensado para VP Engineering, CTOs de scale-up, Heads of Engineering y Engineering Managers que están escalando equipo de 10 a 50 a 200 ingenieros. Para roles ejecutivos relacionados conviene revisar la guía de cómo contratar VP Engineering y Head of Data y la remuneración de Engineering Manager 2026.

Por qué la mayoría de scale-ups demora demasiado en evolucionar la org

Tres razones explican el retraso. La primera es sesgo de continuidad: lo que funcionó hasta acá debería seguir funcionando. La segunda es miedo al overhead: pasar a squads suena a más reuniones, más managers, más ceremonia. La tercera, la más cara, es falta de vocabulario operativo: muchos VP Engineering nunca han trabajado en una org de 100 ingenieros y no tienen un mapa claro de qué viene después de feature teams.

Cuando la estructura no evoluciona, los síntomas aparecen siempre en el mismo orden. Primero, las dailies de los feature teams se llenan de coordinación interequipo. Después, el tiempo entre commit y deploy a producción crece de horas a días. Luego, los seniors empiezan a hacer una mezcla de architecting, hiring, mentoring y reviewing que termina quemándolos. Finalmente, alguien renuncia y la cascada se inicia. Para entender cómo manejar ese escenario crítico, conviene revisar la guía de reemplazo emergente de Tech Lead en 21 días.

El segundo dato útil es la relación entre madurez de la plataforma interna y velocidad real de entrega. Una empresa con squads stream-aligned pero sin plataforma se queda atrapada en pipelines manuales y ambientes inestables. La inversión en plataforma tiene una curva de payoff clara que solo se ve cuando se mide deploy time end-to-end.

Las 5 estructuras canónicas de un área de ingeniería

El vocabulario operativo viene del trabajo de Matthew Skelton y Manuel Pais sobre topologías de equipos, pero la implementación que sigue está adaptada a la realidad de scale-ups tech en el cono sur: equipos más pequeños que los de Silicon Valley, mayor mezcla de seniorities y mayor presión por mantener velocidad de feature delivery durante la transición.

1. Feature teams (hasta 30 ingenieros)

Estructura básica de scale-up temprana. Tres o cuatro equipos pequeños, cada uno responsable de una vertical de producto, con un Tech Lead y entre 5 y 7 ingenieros. Cada feature team toca código transversal sin restricciones porque el costo de coordinación todavía es bajo. Funciona muy bien hasta 25-30 ingenieros. Más allá empiezan los choques de prioridad cruzada y la deuda compartida.

2. Stream-aligned squads (30 a 80 ingenieros)

Squads de 5 a 9 ingenieros alineados a un dominio o flujo de valor de negocio claro: checkout, onboarding, motor de recomendación, integraciones de pago. Cada squad tiene Tech Lead, Engineering Manager y, idealmente, Product Manager dedicado. La diferencia con feature teams es que el ownership es estable y el squad tiene autonomía de release. Esta es la estructura más común en scale-ups entre 40 y 100 personas en producto.

3. Platform team (a partir de 50-80 ingenieros)

Equipo de 4 a 8 ingenieros que construye productos internos consumibles por self-service: pipelines de CI/CD, paved roads, observabilidad, manejo de secretos, gestión de ambientes, infraestructura como código. La regla operativa es que la plataforma se trata como producto, no como mesa de ayuda: tiene product owner interno, roadmap publicado y métricas de adopción. Para perfiles de plataforma conviene complementar con la guía de cómo contratar un SRE en 2026.

4. Enabling team (a partir de 100 ingenieros)

Equipo pequeño, generalmente de 3 a 5 ingenieros senior, con misión acotada en el tiempo: transferir capacidad técnica nueva a los squads stream-aligned. Ejemplos típicos son llevar al equipo a dominar testing automatizado, observabilidad moderna o un nuevo paradigma como event-driven. Se diferencia del platform team porque no construye producto interno permanente: enseña, deja patrones documentados y se disuelve o pivota a otro tema.

5. Complicated-subsystem team (a partir de 150-200 ingenieros)

Equipo especializado a cargo de un subsistema técnicamente complejo que requiere conocimiento profundo: motor de pricing, módulo de ML inference, sistema de billing transaccional, motor de matching de algoritmos. La especialización se justifica porque el costo de mantener este conocimiento en todos los squads es prohibitivo. Es la última estructura en aparecer y solo aplica cuando ya hay 4 o 5 squads consolidados.

La tabla siguiente resume las cinco estructuras lado a lado. Más allá de los manuales, el filtro real es siempre el mismo: si un nuevo Senior puede explicar la estructura completa en su primer 1:1 sin pedir un diagrama, está bien diseñada.

Señales claras para evolucionar de una estructura a la siguiente

Las señales no son sutiles. El error es ignorarlas y atribuir el síntoma a problemas de individuos en lugar de problemas de diseño. Cinco señales duras indican que la estructura actual no escala más y conviene preparar la siguiente.

1. Coordinación > 25 por ciento del tiempo de ingeniería: si los seniors pasan más de la cuarta parte de su semana en sincronizar entre equipos, la estructura está mal cortada. Los bordes de dominio deben absorber esa coordinación, no las personas.
2. Releases que se pisan entre equipos: dos teams toca el mismo servicio en la misma semana y se bloquean. Señal de que no hay ownership claro y de que conviene segregar por dominio con squads stream-aligned.
3. Deploy time crece de horas a días: si el tiempo entre commit aprobado y release a producción supera las 4 horas de mediana, la plataforma interna está siendo cuello de botella. Hora de invertir en platform team.
4. On-call concentrado en 3 personas: cuando el on-call no rota porque solo tres seniors conocen el sistema completo, la estructura está extorsionada por knowledge silos. Enabling team o rotación forzada.
5. Tech Leads quemados haciendo de todo: el Tech Lead que hace arquitectura, hiring, 1:1, code review y produce features se rompe en seis meses. Señal de que falta Engineering Manager dedicado al squad.

Los 5 anti-patterns que destruyen org design en scale-ups

Conocer los anti-patterns importa más que conocer las estructuras canónicas. Las estructuras se aprenden en una hora; los anti-patterns hunden empresas durante años.

Componentes compartidos sin dueño claro

El módulo de autenticación, el sistema de notificaciones, la capa de feature flags. Cuando estos componentes los toca cualquier squad sin un dueño formal, la deuda técnica que acumulan es invisible: cada cambio funciona en aislamiento pero el código colectivo se vuelve frágil. La regla operativa: todo componente crítico tiene un squad propietario, incluso si lo consumen todos. Sin dueño, no se construye.

Plataforma prematura con 20 ingenieros

Un CTO joven copia el modelo de empresas grandes y arma un platform team de 4 personas cuando todavía hay 20 ingenieros totales. El platform team consume 20 por ciento del headcount sin que exista todavía suficiente demanda interna. Resultado: la plataforma se construye en vacío, los stream-aligned squads no la adoptan porque tienen sus propios scripts, y el platform team termina haciendo tickets de soporte. La plataforma sirve cuando ya duele; antes, sólo absorbe recursos.

Matriz hiperdocumentada que nadie entiende

Estructura cruzada donde cada ingeniero reporta a un Engineering Manager funcional y al mismo tiempo a un líder de capítulo y a un product owner. En el papel se ve sofisticado. En la práctica cada decisión necesita firma de tres personas, los 1:1 se duplican y el ciclo de feedback se diluye. La regla simple: cada ingeniero tiene un manager de people, un punto. Capítulos y guilds son comunidades de práctica, no estructuras de autoridad.

Squad enorme que se subdivide informalmente

Un squad creció a 14 personas y nadie lo dividió formalmente. Adentro hay tres frentes que en realidad ya son tres squads chicos, pero comparten Tech Lead, daily y backlog. Pierden contexto entre ellos, las dailies se hacen aburridas y el Tech Lead se quema. Por encima de 9 personas, dividir es obligación, no opción.

Enabling team que se vuelve permanente

El enabling team se creó para llevar al equipo a dominar testing automatizado en seis meses y dos años después sigue existiendo, ahora como equipo de QA disfrazado. Pierde su propósito original, captura a los mejores seniors técnicos y bloquea la responsabilidad de los squads stream-aligned sobre su propia calidad. Los enabling teams tienen fecha de término explícita al momento de crearse.

Org design simple gana siempre a org design elegante en papel. La estructura correcta no es la más sofisticada: es la que un nuevo Senior entiende completa en su primer 1:1 sin pedir un diagrama. Pablo Herrera, IT Workers

Ratios de seniority por estructura

Una estructura bien dibujada pero mal poblada no funciona. La pregunta crítica es la composición por seniority. Los ratios que siguen son los que IT Workers ve repetirse en scale-ups con velocidad sostenida y baja rotación.

El error frecuente es armar squads stream-aligned demasiado juniors para cumplir headcount. Un squad con 60 por ciento juniors y mids tempranos sin Senior fuerte produce código que tres meses después hay que reescribir. El otro extremo, squads 100 por ciento seniors, también falla: pierde energía de ejecución y suele sobreingeniería sistemática. El sweet spot del 30/50/20 con un Tech Lead Senior fuerte está validado en empresas tech con NPS interno de ingeniería sobre 40.

Qué roles contratar primero al pasar a squads

La transición de feature teams a squads stream-aligned se queda corta si no hay suficientes Tech Leads y Engineering Managers. El error más común es prometer una transición a squads sin haber asegurado los líderes antes. Tres roles son la columna vertebral.

1. Tech Lead Senior por squad: es el rol que sostiene calidad técnica del squad. Su perfil combina arquitectura, code review estricto, mentoring activo y discusión con el Engineering Manager sobre prioridades. Sin Tech Lead, el squad termina con un Senior haciendo de todo y quemándose.
2. Engineering Manager: people management dedicado: 1:1, performance reviews, hiring, career growth. La regla: máximo 6-8 reportes directos. Por encima de eso la calidad de people management cae y los buenos ingenieros sienten que su carrera no se gestiona.
3. Staff Engineer o Principal: cruza varios squads, define arquitectura global, escribe Tech Design Docs críticos y sirve como contrapeso técnico al CTO. Un Staff Engineer fuerte cada 2 a 3 squads marca la diferencia entre una org que escala y una que se llena de deuda invisible.

Si la empresa pasa a squads sin tener los Tech Leads internos listos, hay dos caminos: promover desde dentro a Seniors que ya están listos, o contratar externos. Ninguno de los dos es trivial. Para entender los tiempos reales del segundo camino, conviene revisar la guía sobre cuánto tarda contratar un perfil tech.

Cuándo conviene contratar un Head of Platform vs construir interno

El Head of Platform es un rol que muchas scale-ups deciden contratar tarde. El umbral típico es cuando el platform team ya tiene 3 o 4 ingenieros, opera con un Staff Engineer como líder parcial y empieza a aparecer dolor estratégico: roadmap reactivo, baja adopción interna, tooling fragmentado, falta de visión de plataforma como producto. Esto suele ocurrir entre los 80 y 120 ingenieros totales.

La pregunta concreta es: ¿conviene promover al Staff Platform Engineer interno a Head of Platform, o contratar uno externo con experiencia previa en empresa grande? La respuesta depende de tres factores.

• Madurez actual de la plataforma: si la plataforma todavía es básica, promover desde dentro funciona porque el Staff ya conoce el contexto. Si la plataforma ya es compleja y necesita un salto cualitativo, conviene externo con cicatrices de haber liderado plataforma a 200 ingenieros.
• Necesidad de credibilidad cross-org: el Head of Platform tiene que negociar con VP Engineering y con jefes de squads stream-aligned. Si el promovido interno tiene credibilidad construida, funciona. Si no, un externo con track record acelera la legitimidad.
• Velocidad requerida: promover desde dentro toma 3 a 6 meses de rampa al rol. Contratar externo toma 8 a 12 semanas de búsqueda más 2 a 3 meses de onboarding. Si la presión es alta, los tiempos son comparables.

Cuando se decide ir por externo, conviene tratar el proceso como búsqueda crítica con headhunter especializado. La oferta de Heads of Platform en Chile es limitada y los mejores candidatos están en empresas competidoras o cómodos en su rol actual, no buscando activamente. Para entender el modelo y los plazos, revisar el reclutamiento IT especializado de IT Workers y la pieza sobre cuándo conviene un IT headhunter.

Casos anonimizados: tres transiciones reales

Tres patrones que se repiten en clientes de IT Workers cuando rediseñan su org de ingeniería. Empresas anonimizadas, métricas reales.

Caso Fintech A: 35 a 60 ingenieros en 9 meses

Fintech de pagos B2B. Partieron con cuatro feature teams de 8-9 personas. A los 40 ingenieros el roadmap se atrasó dos meses, el deploy time pasó de 2 horas a 2 días y un Tech Lead clave renunció. Rediseñaron a seis squads stream-aligned (5-7 ingenieros cada uno) más un platform team de 4. Tiempo de transición: 10 semanas. Resultado a 6 meses: deploy time bajo a 30 minutos, velocity recuperó nivel previo más 20 por ciento adicional, cero renuncias de Tech Leads en el período.

Caso Marketplace B: el squad gigante

Marketplace de servicios con un squad de 14 ingenieros que cubrían el motor de matching. Tres frentes internos competían por backlog y el Tech Lead estaba quemado. Dividieron en tres squads de 5 ingenieros cada uno con dominios claros (algoritmo, calidad de datos, integraciones). Promocionaron a dos Seniors a Tech Lead y contrataron un Staff Engineer externo para mantener visión transversal. Velocity subió 35 por ciento en el trimestre siguiente y el burnout del antiguo Tech Lead se resolvió.

Caso SaaS C: la plataforma prematura

SaaS B2B de 28 ingenieros con un platform team de 5 construido prematuramente. El platform team consumía 18 por ciento del headcount sin que los squads stream-aligned adoptaran la plataforma. Disolvieron el platform team, redistribuyeron las personas a squads y crearon un capítulo informal de DevEx con 20 por ciento del tiempo de tres seniors. A los 6 meses, con 45 ingenieros totales, retomaron platform team de 3 personas pero esta vez con dolor real identificado y roadmap aprobado por los squads consumidores.

Transición ordenada de feature teams a squads en 10 semanas

La transición no se ejecuta en un fin de semana. Lo que sigue es el cronograma estándar que IT Workers recomienda para evolucionar un equipo de 30 a 60 ingenieros sin frenar entregas.

El error típico es intentar comprimir esta transición en 4 semanas. Bajo esa marca, los Tech Leads quedan sin tiempo de internalizar el rol, las dependencias residuales no se cierran y la productividad cae hasta 30 por ciento durante el trimestre siguiente. Diez semanas es el mínimo razonable para empresas tech entre 30 y 60 ingenieros.

Preguntas frecuentes sobre org design de ingeniería