Diagnosticar una organización de ingeniería con datos
Diagnosticar una organización de ingeniería con datos
Hace un tiempo hice un trabajo de consultoría para una fintech de pagos en LATAM — un diagnóstico organizacional de su área de ingeniería. Lo comparto porque creo que el enfoque es replicable — no depende de la empresa ni del tamaño del equipo. Si lideras ingeniería en una fintech o startup, probablemente reconozcas varios de estos patrones.
Los nombres, datos y detalles fueron modificados. Lo que tiene valor aquí es el enfoque: cómo analizar los datos, qué priorizar y por qué.
Este es el primero de tres posts. Aquí va el diagnóstico. En los siguientes: estrategia de métricas y plan de ejecución a 90 días.
El escenario
Una plataforma de orquestación de pagos para marketplaces en LATAM. Los marketplaces integran un API para manejar split payments, dispersión a sellers, escrow y compliance (retención fiscal, anti-lavado).
Los problemas:
- Plazos de entrega con clientes incumpliéndose
- Demasiado tiempo apagando incendios
- Cycle times (el tiempo que tarda un ticket desde que se empieza hasta que se entrega) impredecibles entre squads
- Los interesados del negocio pidiendo más visibilidad
- El CTO necesitando métricas y un sistema de ejecución claro
Cuatro squads:
| Squad | Propósito | Tamaño | Seniority |
|---|---|---|---|
| Payments Core | Orquestación de pagos + split engine | 4 eng | 1 Sr, 2 Mid, 1 Jr |
| Payouts | Dispersión a sellers + conciliación | 2 eng | 1 Sr, 1 Mid |
| Onboarding | KYC sellers + integración de marketplaces | 3 eng | 2 Sr, 1 Mid |
| Compliance | AML pipeline + retención fiscal | 2 eng | 1 Sr, 1 Mid |
Términos clave:
- Flow efficiency: proporción de tiempo trabajando activamente vs esperando
- Cycle time P75: el tiempo que tarda el 75% de los tickets en completarse
- CFR (Change Failure Rate): porcentaje de deploys que causan un incidente
- GMV (Gross Merchandise Volume): volumen total de transacciones procesadas
- MTTR (Mean Time to Restore): tiempo promedio en restaurar un servicio caído
Resumen del diagnóstico
| Squad | Estado | Problema principal | Acción |
|---|---|---|---|
| Payouts | Crítico | 13% flow efficiency, 23% CFR en Payout Service | Proceso + estabilizar |
| Payments Core | Riesgo | 27% flow efficiency, 9% CFR en Split Engine | Mejorar flujo |
| Onboarding | Estable | 44% flow efficiency, <7% CFR | Mantener |
| Compliance | Estable | 32% flow efficiency, <5% CFR | Mantener |
Identificar los cuellos de botella
Payouts es el cuello de botella principal.
- Flow efficiency de 13% — por cada hora de código, casi 7 horas de espera entre code reviews, dependencias y bloqueos.
- Cycle time P75 de 19.7 días — la mayoría del trabajo no cabe en un sprint.
- CFR de 23% en el Seller Payout Service — casi 1 de cada 4 deploys rompe algo.
Payments Core es el problema oculto.
- Flow efficiency de 27% y cycle time P75 de 10.2 días — no llama la atención porque Payouts está peor.
- Pero Core mueve $9.3M mensuales en GMV entre el Split Engine y el Payment Gateway API.
- Cualquier degradación ahí tiene un impacto desproporcionado.
Onboarding funciona.
- 44% de flow efficiency y cycle times controlados.
- No necesita intervención inmediata.
Compliance también está estable.
- 32% de flow efficiency, CFR bajo, cycle times razonables.
Calcular el Revenue at Risk
Para priorizar con datos y no con intuición:
Revenue at Risk = (Deploys/semana × CFR) × (GMV/semana) × Severidad × (MTTR/168)
- (Deploys/semana × CFR) = incidentes esperados por semana
- (GMV/semana) = valor procesado (GMV mensual / 4)
- (Severidad) = peso del impacto (High: 1.0, Medium: 0.5, Low: 0.2)
- (MTTR/168) = tiempo promedio de restauración dividido entre 168 horas de la semana
Es una versión simplificada. En la realidad hay más variables — recuperaciones, fallbacks, reintentos, colas — que pueden mitigar o amplificar el impacto.
Ejemplo: Seller Payout Service
- Deploys/semana: 1.2
- CFR: 23% → incidentes esperados = 1.2 × 0.23 = 0.276/semana
- GMV/semana: $1.8M / 4 = $450K
- Severidad: High (1.0)
- MTTR: 6.5 horas → 6.5 / 168 = 0.0387
Revenue at Risk = 0.276 × $450K × 1.0 × 0.0387 ≈ ~$4.8K/semana
No es un número exacto — es una heurística para priorizar. Pero cambia la conversación de “el servicio de payouts tiene bugs” a “Payouts pone en riesgo ~$19K/mes en revenue”.
Por servicio
| Servicio | Squad | GMV Mensual | Severidad | Revenue at Risk/semana |
|---|---|---|---|---|
| Seller Payout Service | Payouts | $1.8M | High | ~$4.8K |
| Reconciliation Engine | Payouts | $1.8M | High | ~$2.3K |
| Split Engine | Payments Core | $4.2M | Medium | ~$1.2K |
| Payment Gateway API | Payments Core | $5.1M | Medium | ~$0.6K |
| Marketplace Connector | Onboarding | $1.1M | Low | ~$0.05K |
| AML Pipeline | Compliance | $3.4M | Low | ~$0.08K |
| Tax Withholding Service | Compliance | $0.6M | Low | ~$0.02K |
| KYC Flow | Onboarding | $0.7M | Low | ~$0.01K |
Payouts acumula ~$7.1K/semana en Revenue at Risk — el squad más crítico por lejos. Payments Core suma ~$1.8K/semana, pero con $9.3M en GMV mensual, cualquier degradación en CFR o MTTR escala rápido.
Engineering Leverage
Leverage = Revenue generado / Costo de ingeniería.
Los costos se estiman a partir del tamaño del equipo y salarios promedio de mercado para cada nivel de seniority. El revenue incremental se obtiene del equipo de finanzas.
| Squad | Costo semanal | Revenue incremental | Leverage |
|---|---|---|---|
| Payments Core | $18k | $67k | 3.7x |
| Onboarding | $14k | $38k | 2.7x |
| Compliance | $10k | $24k | 2.4x |
| Payouts | $10k | $7k | 0.7x |
Leverage no es la única métrica que importa, pero es la que más rápido alinea a ingeniería con finanzas. Cuando el CFO pregunta “¿por qué necesitamos más gente?”, este número responde.
Payouts tiene leverage menor a 1 — cuesta más de lo que genera. No es culpa del equipo. Son 2 personas con 57% del tiempo en modo reactivo (26% bugs + 31% solicitudes de clientes). Es un problema de proceso y de dotación de personal.
Distribución del tiempo desalineada
Payouts gasta solo 29% en roadmap (debería ser >50%) y 57% en trabajo reactivo. No hay proceso de entrada — todo llega sin filtro y sin priorización.
Qué escalar al CTO (y cómo)
- Payouts con leverage negativo (0.7x) — gasta más de lo que genera, ~$7.1K/semana en Revenue at Risk
- Seller Payout Service inestable — CFR de 23%, severidad High, bloquea la dispersión a sellers
- Payments Core está mal pero oculto — $9.3M en GMV mensual con flow efficiency de 27%
- Compromisos con clientes en riesgo — cycle time P75 de 19.7 días en Payouts no es compatible con los acuerdos de nivel de servicio prometidos
Primeras 4 semanas
Paso 1: Ordenar Payouts. Proceso de entrada para solicitudes de clientes. Proteger mínimo 50% del tiempo para roadmap. Identificar causas raíz de bloqueo.
Paso 2: Estabilizar Seller Payout Service. Revisar arquitectura y cobertura de tests. Feature flags para revertir rápido. Congelar deploys los viernes.
Paso 3: Investigar Payments Core. Mapear qué está generando el 27% de flow efficiency. ¿Son code reviews lentos? ¿Dependencias entre servicios? ¿Falta de responsabilidad clara sobre los componentes?
En paralelo: Evaluar si Payouts necesita más gente — qué perfil, contexto y justificación.
Cómo replicar esto
Si quieres hacer un diagnóstico similar:
- Mapea squads → servicios → GMV. Sin este análisis para enlazar impacto de negocio, no puedes medir impacto.
- Mide flow efficiency y CFR por squad. No necesitas herramientas sofisticadas — Git history + issue tracker es suficiente. Pero aquí es donde un líder de ingeniería que codea saca su verdadero poder: meterse en el código, entender qué falla, cómo funciona todo, cuánto tiempo lleva deployar algo a producción. Es importante identificar problemas, bloqueos y flujos que funcionan.
- Calcula Revenue at Risk para priorizar con datos. Puedes usar la fórmula simple que propongo aquí e ir puliéndola de a poco, según tu equipo, objetivos, contexto y otras variables que cambien con el tiempo.
- Presenta leverage como argumento de inversión, no como evaluación de desempeño. Esta métrica sirve como guía para saber hacia dónde moverse: dónde puedes generar más impacto o dónde hace falta reforzar el equipo.
Este es un primer approach con contexto reducido. Al entrar en la organización y estudiar de cerca los equipos, los servicios y el día a día, puedes detallar mucho más y mejorar las decisiones tomadas. Pero como punto de partida, este tipo de diagnóstico ya te da dirección.
El diagnóstico sirve para conectar datos de ingeniería con decisiones de negocio. Cuando puedes decir “este squad tiene leverage negativo y este servicio pone en riesgo ~$28K/mes”, la conversación con el CTO cambia completamente.
En el próximo post: cómo armar el sistema de métricas que sostiene este tipo de análisis en el tiempo.
Si quieres profundizar en las métricas que usé como referencia, revisa el framework DORA.
Comments