[High-Performance Team] El Diagnóstico y el Framework de Optimización (Parte 1/3)
[High-Performance Team] El Diagnóstico y el Framework de Optimización (Parte 1/3)
Hace un tiempo, mientras trabajaba como líder de ingeniería en una FinTech en LatAm, me tocó enfrentar un reto que muchos engineering managers conocen pero pocos documentan: rediseñar una organización de ingeniería completa — equipos, servicios, cultura, stack tecnológico — con el objetivo de construir una estructura más enfocada y efectiva.
No era solo un problema de eficiencia. El equipo de ingeniería trabajaba aislado del negocio, sin foco en producto ni métricas de impacto. No existía un equipo de ingeniería cohesivo como tal — eran grupos de personas trabajando en paralelo sin alineación. El reto no era solo optimizar recursos y velocidad, sino construir un equipo real por primera vez: uno que entendiera el negocio, apuntara a dar valor medible y operara como una unidad.
Me tomó un mes diseñar el framework completo. No quiero que se quede en el olvido, así que decidí compartirlo como un playbook abierto para quien lo necesite.
Esta no es teoría de libro. Es un framework que construí con datos reales, problemas reales y restricciones reales.
Nota: Esta metodología fue diseñada en un momento donde los LLMs apenas estaban entrando en escena en el mundo del desarrollo. Hoy, con herramientas de AI integradas en el flujo de trabajo de ingeniería, muchas de las decisiones — especialmente alrededor de capacidad por persona, automatización y estructura de equipos — probablemente serían diferentes y hasta más eficientes. Los objetivos siguen siendo los mismos; el medio para llegar a ellos es lo que cambiaría.
Los 4 Objetivos
Todo empezó con una pregunta simple: ¿qué necesita esta organización de ingeniería para ser realmente efectiva?
La respuesta se condensó en 4 objetivos claros:
- Maximizar eficiencia — lograr más con una estructura más enfocada.
- Acelerar la velocidad de ejecución — menos fricción, más entregas.
- Reducir costos al mínimo — infraestructura, herramientas, servicios.
- Construir un equipo de alto performance — mayor ownership, compromiso y ejecución.
No son objetivos independientes. Cada uno alimenta al siguiente. Un equipo compacto y senior naturalmente ejecuta más rápido, gasta menos en overhead y tiene mayor ownership porque cada persona tiene impacto visible.
El Framework de Optimización: 5 Pilares
Pilar 1 — Equipo Compacto y High-Performance
El equipo era grande, pero no era efectivo. Había muchas personas haciendo poco, con dependencias cruzadas y poca autonomía.
La propuesta era rediseñar la estructura. Un equipo compacto de personas senior, con skills completos y autonomía real, supera consistentemente a un equipo grande donde el ownership está diluido. La clave: scope claro y las herramientas necesarias para ejecutar sin fricción.
Pilar 2 — Simplificar el Flujo de Trabajo
La burocracia estaba matando la velocidad. Permisos que tardaban días, procesos de aprobación innecesarios, desarrolladores que no podían tocar la base de datos o la infraestructura sin pedir acceso.
La propuesta: programadores con skills completos. Un developer senior debería poder manejar base de datos, infraestructura y desarrollo sin depender de otros equipos para cada paso.
| Métrica | Antes | Proyección |
|---|---|---|
| Lead Time / Cycle Time promedio | X días | 1-2 días |
| Porcentaje de tareas bloqueadas | Alto | Mínimo |
Pilar 3 — Consolidación de Servicios y Herramientas
Este fue uno de los hallazgos más impactantes. La empresa tenía 160 microservicios reconocidos, de los cuales solo 66 estaban siendo usados activamente. El resto era legacy muerto, experimentos abandonados y duplicaciones.
La proyección: consolidar a 45 servicios funcionales y mantener solo lo que generaba valor.
En paralelo, el uso de herramientas externas (monitoreo, identity management, repositorios, etc.) se podía reducir un 30% eliminando redundancias y licencias innecesarias.
| Métrica | Antes | Proyección |
|---|---|---|
| Microservicios | 160 (66 usados) | 45 |
| Uso de herramientas/servicios | 100% | 70% |
Pilar 4 — Automatización del Soporte Operativo
Los desarrolladores estaban gastando un porcentaje significativo de su tiempo en tareas de soporte operativo: atender tickets de herramientas internas de administración, hacer queries manuales, resolver problemas de configuración de clientes.
El objetivo era claro: reducir las tareas de soporte realizadas por desarrolladores a menos del 5% — lo más cercano a cero posible. Todo lo que fuera repetitivo debía automatizarse. Todo lo que fuera configurable debía tener una interfaz para el equipo de operaciones.
| Métrica | Antes | Proyección |
|---|---|---|
| % soporte operativo hecho por devs | Alto | <5% |
Pilar 5 — Nueva Cultura y Forma de Trabajo
Los primeros 4 pilares son estructurales. Este es el que lo sostiene todo. Sin una cultura definida y práctica, el resto se desmorona en semanas. Profundizo en esto en la Parte 3/3 de esta serie.
Scope: Mapeo Completo de Proyectos
Antes de tocar equipos o tecnología, necesitaba entender el scope completo. Mapeé 21 proyectos evaluando cada uno en estas dimensiones:
- Deuda técnica (Alto/Medio/Bajo)
- Nivel de mantenimiento requerido
- Nivel de nuevos features esperado
- Prioridad para el negocio
- Skills requeridos (Frontend, Backend, Data, etc.)
- Objetivos de producto y KPIs asociados
El resultado fue una matriz que permitía ver de un vistazo dónde estaba el valor y dónde estaba el desperdicio.
Proyectos de Alta Prioridad
Los proyectos que demandaban más atención y tenían mayor impacto en el negocio:
- Onboarding — El proceso de self-onboarding para clientes. Deuda técnica alta, features nuevos necesarios. Objetivo: reducir el tiempo de onboarding significativamente.
- Nuevos Métodos de Pago (BNPL, cashin, cashout) — Motor de crecimiento. Bajo legacy, alto en features nuevos. Objetivo: múltiples integraciones funcionando perfectamente, incrementar conversión de checkout.
- Motor de Detección de Riesgo — Sistema de evaluación de riesgo transaccional. Bajo legacy, alto en features nuevos. Objetivo: mantener chargeback rate y decline rate en niveles óptimos.
- Gestión de Disputas — Procesos de representación y gestión de disputas. Deuda técnica alta, features nuevos necesarios.
- Procesamiento de Pagos Core — Core del negocio. Deuda técnica media, requería estabilización y robustecimiento.
Proyectos de Mantenimiento
Proyectos que debían funcionar bien pero no necesitaban innovación constante:
- Dashboard de Clientes — Web app para que el cliente vea el estado de su negocio.
- Herramientas internas de administración — Configuración y mantenimiento de procesos.
- Operaciones Financieras (dispersiones, retenciones, balances) — Procesos financieros core.
- Infraestructura y Plataforma — Cloud, CI/CD, bases de datos.
Proyectos para Consolidar o Deprecar
- Procesamiento de pagos legacy — Sistemas antiguos que debían migrarse.
- Transferencias legacy — Prioridad baja, bajo mantenimiento.
- Canal de cobro legacy — En declive.
¿Qué Sigue?
Con el diagnóstico y el framework definidos, el siguiente paso fue diseñar los equipos concretos — quién, dónde, haciendo qué — y decidir qué hacer con un stack tecnológico fragmentado en 8 lenguajes y 571 repositorios. Eso lo cubro en la Parte 2/3: Team Design y Stack Tecnológico.
Comments