[High-Performance Team] Team Design y Stack Tecnológico (Parte 2/3)
[High-Performance Team] Team Design y Stack Tecnológico (Parte 2/3)
En la Parte 1/3 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:
-
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.
-
Responsabilidad — Se hace cargo de sus proyectos end-to-end. Asegura que funcionen bien y busca mejorarlos constantemente.
-
Autonomía — Cubre todo el espectro. Se autogestiona sin necesitar micromanagement.
-
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.
-
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.
-
Soluciones Simples — Evita over-engineering. Tiene la habilidad de resolver problemas de forma directa y eficiente.
-
Escalabilidad — Experiencia diseñando y construyendo soluciones que escalan.
-
Experiencia — Más de 7 años desarrollando software a alto nivel, con crecimiento demostrable.
-
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.
Comments