# [High-Performance Team] Team Design y Stack Tecnológico (Parte 2/3) Cómo diseñé la estructura de squads, definí el perfil del developer ideal y planifiqué la consolidación de un stack fragmentado en 8 lenguajes y 571 repositorios. 11 abr 2026 · https://e1i0.com/es/high-performance-team-design-stack.html --- En la [Parte 1/3](/es/2026/04/11/high-performance-team-diagnosis-framework.html) cubrí el diagnóstico y el framework de 5 pilares. Ahora viene la parte más concreta: **diseñar los equipos y decidir qué hacer con el stack tecnológico**. Este es el punto donde las decisiones se vuelven reales — cada posición tiene un costo, cada lenguaje tiene un costo de mantenimiento, y cada servicio tiene un costo de infraestructura. No hay espacio para roles "por si acaso" ni para tecnologías que nadie domina. ## Diseño de Equipos por Squads Con el scope mapeado (21 proyectos, cada uno evaluado en prioridad, deuda técnica y skills requeridos), diseñé la estructura por **squads orientados a producto**. Cada squad tiene ownership claro sobre un dominio del negocio. ### Squad Risk | Rol | Nivel | % Código | Responsabilidad | | --- | ----- | -------- | --------------- | | Backend | Senior/Tech Lead | 50-70% | Mantenimiento + nuevos features | | Frontend | Senior | 90% | Mantenimiento + nuevos features | | Data Scientist | Lead | N/A | Desarrollo de modelos ML | | Data Analyst | Senior | N/A | Modelos ML (transaction, customer, client) | **Objetivo:** Evolucionar el motor de detección de riesgo. Este squad tenía la particularidad de combinar ingeniería de software con machine learning — un bridge que pocos equipos logran bien. ### Squad Processing | Rol | Nivel | % Código | Responsabilidad | | --- | ----- | -------- | --------------- | | Backend | Senior/Tech Lead | 50-70% | Mantenimiento + nuevos features | | Backend | Senior | 90% | Mantenimiento + nuevos features | | Frontend | Senior | 90% | Backoffice y dashboard | **Objetivo:** Mantener, estabilizar y robustecer la arquitectura de procesamiento de pagos core. El core del negocio requería solidez, no innovación constante. ### Squad Growth | Rol | Nivel | % Código | Responsabilidad | | --- | ----- | -------- | --------------- | | Backend | Senior/Tech Lead | 50-70% | Nuevos features — onboarding | | Backend | Senior | 90% | Deuda técnica — desacoplar operaciones financieras | | Backend | Senior | 90% | Nuevos features — onboarding | | Frontend | Senior | 90% | Mejoras en herramientas internas / dashboard | **Objetivo:** Agilizar onboarding y simplificar procesos. Uno de los backends estaba dedicado exclusivamente a resolver deuda técnica y desacoplar la arquitectura de operaciones financieras. ### Squad Payments | Rol | Nivel | % Código | Responsabilidad | | --- | ----- | -------- | --------------- | | Backend | Senior/Tech Lead | 50-70% | Nuevos features — integraciones | | Backend | Senior (x2) | 90% | Nuevos features — métodos de pago | | Frontend | Senior | 90% | Nuevos features — integraciones | | Mobile | Senior | 90% | Nuevos features — integraciones | **Objetivo:** Desarrollar nuevas integraciones y nuevos métodos de pago. El squad más grande porque era el motor de crecimiento. ### Squad Data | Rol | Nivel | Responsabilidad | | --- | ----- | --------------- | | Data Engineer | Senior/Lead | Pipelines y data infrastructure | | Data Analyst (x2) | Senior | Análisis exploratorios, insights, dashboards | | BI | Senior | Estrategia, tendencias, patrones de negocio | **Objetivo:** Construir y mantener la infraestructura de datos. Transformar datos en insights accionables para decisiones de negocio. ### Squad Platform | Rol | Nivel | Responsabilidad | | --- | ----- | --------------- | | DBA | Senior | Estabilidad de BD, optimización de recursos | | SRE | Senior | Estabilidad de infra, simplificación, costos | | Security | Senior | Procesos de seguridad, cumplimiento normativo | **Objetivo:** Mantener todo corriendo. Tres personas para toda la plataforma suena agresivo, pero con la consolidación de servicios (160 → 45) y developers con autonomía para manejar su propia infra, era viable. ### Principio de Diseño Cada rol estaba justificado por el scope. No había posiciones "por si acaso" ni buffers. Si un proyecto no era prioridad alta, no tenía squad dedicado — se cubría con rotación de los squads existentes. El resultado: una estructura donde cada persona tenía impacto visible y ownership real. ## El Perfil de Developer Ideal No basta con definir posiciones — hay que definir **qué tipo de persona** necesitas en cada una. Definí 9 características del engineer que necesitaba este equipo: 1. **Madurez** — Ya pasó la etapa de probar tecnologías cool porque están de moda. Elige herramientas porque resuelven el problema, no porque son trending en Hacker News. 2. **Responsabilidad** — Se hace cargo de sus proyectos end-to-end. Asegura que funcionen bien y busca mejorarlos constantemente. 3. **Autonomía** — Cubre todo el espectro. Se autogestiona sin necesitar micromanagement. 4. **Enfoque en Negocio** — Se preocupa porque todo lo que desarrolle tenga impacto real. Conoce bien el negocio y entiende por qué está construyendo lo que construye. 5. **Decisiones Inteligentes** — Evita decisiones de una sola vía (irreversibles) en lo posible. Se enfoca en decisiones de equipo, reversibles, que se puedan iterar en 1-2 días. 6. **Soluciones Simples** — Evita over-engineering. Tiene la habilidad de resolver problemas de forma directa y eficiente. 7. **Escalabilidad** — Experiencia diseñando y construyendo soluciones que escalan. 8. **Experiencia** — Más de 7 años desarrollando software a alto nivel, con crecimiento demostrable. 9. **Mentalidad Emprendedora** (nice to have) — Afinidad con startups y su ritmo de trabajo. Este perfil es exigente. Pero en un equipo compacto, cada persona tiene que ser excepcional. No hay espacio para "está aprendiendo" o "necesita supervisión constante." Cada developer es un multiplicador, no un recurso. ## Stack Tecnológico ### El Problema de la Fragmentación El stack era diverso — demasiado diverso: - **8 lenguajes** en producción: Golang, C#, TypeScript, JavaScript, Ruby, Java, PHP, Python - **571 repositorios** en GitHub (475 mapeados) - **158 microservicios** en producción - **MongoDB**: 3 bases de datos, 240 colecciones - **CI/CD fragmentado**: Jenkins, Drone y GitHub Actions conviviendo Cada lenguaje extra es un costo: librerías, dependencias, expertise, herramientas, debugging. Con un equipo compacto, mantener 8 lenguajes significa que algunos servicios dependen de una sola persona que "sabe Ruby" o "conoce ese servicio en Java." Eso es un bus factor de 1 — inaceptable. ### La Proyección: Consolidar | Aspecto | Antes | Proyección | | ------- | ----- | ---------- | | Lenguajes primarios | 8 | 2 (Golang + Python) | | Microservicios | 160 (66 usados) | 45 | | CI/CD | Jenkins + Drone + GitHub Actions | GitHub Actions | | Frontend | TypeScript + JavaScript | TypeScript | La consolidación hacia **Golang y Python** como lenguajes primarios no se haría de golpe. Era una migración gradual: servicios nuevos en Golang/Python, servicios legacy se migran cuando se tocan, los que no se tocan se deprecan. La consolidación de 160 a 45 servicios no solo reducía costos de infraestructura — simplificaba el mapa mental que cada developer necesitaba para entender el sistema. ## ¿Qué Sigue? Con los equipos diseñados y el stack definido, faltaba la pieza más importante: **la cultura y las prácticas técnicas** que harían que todo esto funcionara día a día. Un equipo de seniors sin una cultura clara se convierte rápidamente en un grupo de personas haciendo lo que les da la gana. Eso lo cubro en la [Parte 3/3: Cultura, Prácticas y Reflexiones](/es/2026/04/11/high-performance-team-culture-reflections.html).