Liderar un equipo frontend de 5 en SaaS

Patrones concretos de liderazgo técnico, CI/CD y estandarización durante 3+ años en Extendeal — de 2 a 5 devs, 8+ integraciones y ~2 deploys/semana.

En números

Devs liderados

Años

Integraciones

2/sem

Deploys prod

De 2 a 5: el problema de escala humana

Liderar 5 ingenieros frontend en un SaaS B2B no es multiplicar output por 2.5. Sin estándares, cada dev resuelve integraciones a su manera, los PRs crecen y el onboarding se vuelve oral ("preguntale a Juan"). Mi primer movimiento: documentar decisiones en ADRs ligeros y convenciones en README del repo — no en Notion que nadie lee.

La regla 20/80 de componentes

Implementamos una librería interna solo para flujos de compra críticos: carrito, checkout, comparador de distribuidores, estados de pedido. No reemplazó todo el UI — cubrió ~20% de componentes que generaban ~80% de bugs de regresión. Resultado: −~30% bugs en checkout post-estandarización.

React · patrón de composición

// components/purchase/DistributorComparison.tsx
// Componente de librería interna — API estable, tests exhaustivos

interface DistributorComparisonProps {
  distributors: DistributorQuote[];
  onSelect: (id: string) => void;
  loading?: boolean;
}

export function DistributorComparison({
  distributors,
  onSelect,
  loading,
}: DistributorComparisonProps) {
  // Lógica de comparación centralizada
  // Todos los flujos de compra usan este componente
  // Cambio aquí → un solo PR, no 4 copias
}

CI/CD como contrato de calidad

Jenkins + AWS no son decoración. Definimos gates obligatorios en PR: lint, typecheck, tests unitarios, build. Deploy a staging automático; prod manual con aprobación pero pipeline pre-armado. Pasamos de deploys manuales (~1/semana, con miedo) a ~2/semana predecibles.

Jenkins · pipeline (simplificado)

pipeline {
  agent any
  stages {
    stage('Quality') {
      steps {
        sh 'npm run lint'
        sh 'npm run typecheck'
        sh 'npm test -- --coverage'
      }
    }
    stage('Build') {
      steps { sh 'npm run build' }
    }
    stage('Deploy Staging') {
      steps { sh './deploy.sh staging' }
    }
  }
  post {
    failure { slackSend(channel: '#frontend', message: 'Pipeline failed') }
  }
}

Ownership rotativo

Cada sprint, un dev diferente es owner de un dominio (checkout, integraciones, analítica). Owner = code review principal, documentación, punto de contacto con backend. Distribuye bus factor y evita que todo pase por el lead. Pair programming en integraciones nuevas; autonomía en features estándar.

Métricas que mirábamos

No vanity metrics. Seguimos: tiempo de PR (objetivo <48h), frecuencia de deploy, bugs post-release en checkout (objetivo descendente), y tiempo de onboarding de nuevos devs (de ~4 semanas a ~2 con docs + librería). Estas métricas justificaban inversión en CI/CD y estandarización ante producto.

Takeaways

Librería UI en el 20% crítico — no catalogar todos los componentes
Pipeline CI/CD como gate obligatorio, no como sugerencia
Ownership rotativo por dominio de negocio — reduce bus factor
Onboarding: de 4 semanas a 2 con patrones documentados
~2 deploys/semana predecibles > deploys heroicos mensuales

LeadershipReactCI/CDSaaSTeam