El Desafío del Escalamiento
Escalar un equipo de ingeniería no se trata solo de contratar más personas. Agregar personal a un equipo sin cambiar cómo opera a menudo hace las cosas más lentas, no más rápidas. La Ley de Brooks ("Agregar personal a un proyecto de software atrasado lo atrasa más") captura esta realidad: la sobrecarga de comunicación crece cuadráticamente con el tamaño del equipo.
La Ley de Conway
La Ley de Conway establece: "Toda organización que diseña un sistema producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización."
Implicaciones de la Ley de Conway
- La arquitectura refleja los equipos: Si tienes tres equipos, obtendrás un sistema de tres partes, independientemente de si esa es la arquitectura correcta
- Maniobra Conway Inversa: Diseña la estructura de tu equipo para que coincida con la arquitectura que deseas, y el software seguirá
- Límites de comunicación: Espera APIs bien definidas entre servicios de diferentes equipos, y código acoplado dentro de servicios de un equipo
- Reorganización = rearquitectura: Cuando reestructuras equipos, espera cambios correspondientes en la arquitectura del software
Topologías de Equipo
Cuatro Tipos de Equipo
| Tipo de Equipo | Propósito | Ejemplos |
|---|---|---|
| Stream-Aligned | Entrega valor en un flujo de negocio específico | Equipo de Checkout, Equipo de Búsqueda, Equipo de Notificaciones |
| Plataforma | Proporciona servicios internos que usan los equipos stream-aligned | Infraestructura, CI/CD, Herramientas de desarrollador |
| Habilitación | Ayuda a otros equipos a adoptar nuevas capacidades | Habilitación de seguridad, Orientación de arquitectura |
| Subsistema Complicado | Gestiona un subsistema que requiere conocimiento especialista | Equipo de ML/AI, Equipo de procesamiento de video |
Tamaño Óptimo del Equipo
La investigación muestra consistentemente que el tamaño óptimo para un equipo de ingeniería es 5-8 personas. Los equipos más pequeños de 5 carecen de diversidad de pensamiento. Los equipos más grandes de 8-10 experimentan sobrecarga de comunicación que ralentiza la toma de decisiones.
Cuándo y Cómo Dividir Equipos
## Lista de Verificación de División de Equipos
### Antes de la División
- [ ] Identificar límites claros de propiedad para código y servicios
- [ ] Asegurar que cada nuevo equipo tenga una rotación de guardia viable (mín 3 personas)
- [ ] Definir las APIs/contratos entre los servicios de los nuevos equipos
- [ ] Identificar un Tech Lead para cada nuevo equipo
- [ ] Planificar la transición de propiedad de código y documentación
### Durante la División
- [ ] Mover repositorios o propiedad de código en tus herramientas
- [ ] Actualizar rotaciones de guardia y runbooks
- [ ] Establecer nuevos canales de equipo y normas de comunicación
- [ ] Realizar una reunión de inicio para cada nuevo equipo
### Después de la División
- [ ] Monitorear problemas de integración entre los nuevos equipos
- [ ] Verificar después de 2 semanas para abordar problemas iniciales
- [ ] Establecer reunión de sincronización entre equipos para preocupaciones compartidas
- [ ] Actualizar organigramas y contactos de partes interesadasContratación para Escalar
- Equilibrio de experiencia: No contrates solo ingenieros senior (costoso y crea problemas de demasiados líderes) ni solo juniors (capacidad insuficiente de liderazgo y mentoría). Apunta a una proporción de aproximadamente 1 senior por cada 2-3 ingenieros de nivel medio y junior.
- Contrata anticipadamente: Comienza a contratar antes de que el equipo esté al máximo de capacidad. Toma 1-3 meses desde abrir un puesto hasta tener un nuevo miembro productivo.
- Portadores de cultura: Las primeras contrataciones establecen la cultura. Contrata personas que encarnen los valores que quieres que tenga el equipo.
- Perspectivas diversas: Los equipos homogéneos tienen puntos ciegos. Recluta activamente diversidad cognitiva, de origen y de experiencia.
Anti-patrones de Escalamiento
- Contratar en el cuello de botella: Agregar más personas a un equipo cuyo problema es proceso o arquitectura, no personal
- Escalamiento prematuro: Dividir equipos antes de que el trabajo lo justifique, creando sobrecarga sin beneficio
- Ignorar la cultura: Crecer tan rápido que las normas culturales se diluyen porque los nuevos contratados superan en número a los miembros existentes
- Contratación monocultural: Contratar de las mismas pocas empresas u orígenes, creando pensamiento grupal
- Sin inversión en incorporación: Contratar rápidamente sin escalar el proceso de incorporación, dejando a los nuevos contratados a la deriva
Resumen
Escalar equipos de ingeniería es un arte que requiere equilibrar arquitectura técnica, estructura de equipo, estrategia de contratación y preservación cultural. Aprovecha la Ley de Conway intencionalmente, mantén los equipos pequeños y enfocados, divide equipos a lo largo de límites naturales e invierte en incorporación y cultura mientras creces. Los Tech Leads que navegan bien el escalamiento son aquellos que reconocen que el diseño organizacional es tanto un problema de ingeniería como el diseño de sistemas.