Plataforma vs. squads: cuándo separar y cómo

Sin separar bien qué es plataforma y qué es trabajo de squad, suelen aparecer tres efectos:

• Duplicación silenciosa. Cada squad resuelve lo mismo por su cuenta: integraciones, datos, automatización, infraestructura y estándares. Parece avance, hasta que llega el mantenimiento.
• Cuello de botella invisible. Todo lo crítico depende de un par de expertos o de un equipo transversal sin prioridades claras. Los squads esperan, improvisan o esquivan el estándar.
• Guerra de prioridades. Los squads empujan features. La plataforma busca estabilidad y orden. Sin reglas, se culpan y crece la fricción.

El resultado es una velocidad engañosa. Se entrega rápido en el corto plazo, y después llega la factura en incidentes, re-trabajo, reuniones de coordinación y sorpresas en producción. Si tu organización está en plena transformación, conviene integrar estas decisiones a la agenda de cambio.

Definiciones operativas: squad y plataforma

Aterriza las palabras en lenguaje de gerente:

• Squad: equipo orientado a resultados de negocio. Mide éxito por impacto en ventas, conversión, NPS, reducción de tiempos y calidad que ve el cliente o la operación.
• Plataforma: equipo orientado a habilitación. Mide éxito por habilitar a otros, con menos fricción, más confiabilidad, un “camino pavimentado” y estándares adoptados por muchos equipos.

La pregunta no es elegir entre squads o plataforma, sino decidir qué conviene separar para escalar sin fragilidad. Los squads deben ser dueños de resultados de negocio. La plataforma debe ser dueña de capacidades compartidas que habilitan a varios squads: infraestructura, datos, herramientas, estándares y componentes comunes.

Cinco gatillos para decidir la separación

Usa estos cinco gatillos. Si identificas tres o más, ya estás llegando tarde a la separación.

1. “Esto lo usan muchos” Si una capacidad la consumen tres o más squads, como autenticación, data pipelines, observabilidad, automatización o integraciones, dejarla en un solo squad resulta injusto y riesgoso. La prioridad del squad nunca será servir a los demás. La plataforma puede enfocarse en servir a varios con un servicio estable.

2. “Esto requiere estándar, no creatividad” Cuando el valor está en la consistencia y la repetibilidad, conviene plataforma: seguridad, cumplimiento, calidad de datos y patrones de integración. Si cada squad inventa su versión, terminas con un zoológico difícil de mantener.

3. “Los incidentes se repiten” Si se repiten caídas del pipeline, falta de trazabilidad o cada integración es una odisea, el problema no está en un squad aislado. Falta una capacidad compartida bien diseñada y cuidada. Una plataforma con foco en confiabilidad corta el ciclo de apagar incendios.

4. “Hay expertos irremplazables” Si el conocimiento crítico vive en una o dos personas que ayudan a todos, ya existe una plataforma informal. Es caótica y frágil. Conviene formalizarla para distribuir responsabilidad, documentar decisiones y asegurar continuidad.

5. “Los squads invierten más en base que en producto” Cuando el tiempo se va en infraestructura, herramientas y arreglos comunes, estás usando talento caro para construir piso en lugar de avanzar en outcomes. La plataforma pavimenta el camino para devolver foco de los squads al cliente y al negocio.

Cómo separar sin crear burocracia

Separar no significa armar una oficina de tickets. Diseña la plataforma para habilitar, no para frenar.

Regla 1: Plataforma no es “equipo de tickets” La plataforma existe para crear un camino estándar que un squad puede usar sin renegociar cada paso. Construye plantillas, componentes, pipelines y guías que reduzcan la fricción. Mide adopción y tiempo de entrega de los squads que usan ese camino pavimentado.

Regla 2: Define un catálogo y un contrato Ofrece capacidades como un servicio interno. Deja explícito:

• Qué provee el equipo de plataforma. Catálogo de capacidades y componentes.
• Cómo se consume. Interfaces, APIs internas, repositorios, guías paso a paso.
• Qué garantiza. Un acuerdo de nivel de servicio (SLA) básico y métricas de confiabilidad.
• Qué no hace. Límites claros para evitar expectativas irreales.

Si no existe un contrato, aparece frustración y discusiones interminables. Un catálogo transparente ordena la conversación de prioridades y evita la sensación de arbitrariedad.

Regla 3: Mantén la responsabilidad donde corresponde El squad mantiene la responsabilidad del resultado y del qué del producto. La plataforma asume la responsabilidad del cómo compartido: herramientas, componentes, estándares y confiabilidad transversal. Coordina con un mecanismo simple de prioridades. Por ejemplo, una ventana de planificación mensual con criterios públicos.

Regla 4: Evita la separación por moda No abras una plataforma solo porque “suena moderno”. Si la organización es pequeña o hay poca reutilización real, una plataforma se vuelve overhead. Una alternativa es dejar las capacidades dentro de squads con estándares definidos, documentación común y comunidades de práctica. Funciona si existe disciplina y revisión periódica.

Un último apunte de gestión. Alinea incentivos. Reconoce a los squads por resultados y por adoptar el camino estándar cuando existe. Reconoce a plataforma por reducir fricción y elevar confiabilidad. Si necesitas liberar foco de los equipos, refuerza tu práctica de delegación para que las decisiones aterrizan donde agregan más valor.

Ejercicios prácticos para esta semana

1. Mapa de capacidades compartidas Toma 30 minutos y lista capacidades que varios equipos usan: datos, integraciones, seguridad, automatización, reporting y herramientas. Marca cuántos squads dependen de cada una. Verás patrones de reutilización y puntos calientes.

2. Diagnóstico de fricción Para cada capacidad, responde tres preguntas:

• ¿Cuánto re-trabajo genera hoy?
• ¿Cuántos incidentes produce o amplifica?
• ¿Cuánto depende de “héroes” o expertos irremplazables?

3. Decisión mínima y contrato en 10 líneas Elige una capacidad compartida. Decide si se queda en squads con estándar o si se convierte en plataforma. Escribe un contrato breve:

• Qué es la capacidad y para qué sirve.
• Cómo se consume.
• Qué promete en confiabilidad y tiempos.
• Qué queda fuera del alcance.

Publica ese contrato en un lugar visible, acuerda métricas y revisa adopción cada dos semanas.

Cierre y siguiente paso

Separar plataforma y squads Una decisión sobre cómo escalar con velocidad ordenada y autonomía con estándares, no un ejercicio de organigrama. Tu desafío hoy: identifica una capacidad que varios equipos estén resolviendo en paralelo. Define si vas a convertirla en camino pavimentado o si vas a imponer un estándar real dentro de los squads. En esta serie sobre Diseño Organizacional y Arquitectura de Roles seguiremos con herramientas para que la estructura deje de ser un dibujo y se convierta en ejecución disciplinada.