
Diseñar las interfaces entre equipos también es diseñar capacidad
A las puertas del lanzamiento, una interfaz incompleta puede inmovilizar capacidad que cada equipo sí posee.
El lanzamiento había cumplido el calendario.
Producto cerró el diseño, Operaciones preparó soporte y Comercial comenzó a comprometer fechas. La primera solicitud fuera del estándar detuvo el servicio durante dos días.
Este caso compuesto avanza desde una falla específica. Ningún equipo incumplió su procedimiento.
El trabajo quedó detenido porque nadie podía decidir una excepción que afectaba configuración, precio y riesgo operativo al mismo tiempo.
Tres clasificaciones para un mismo pedido
Comercial describió la solicitud como ajuste menor. Operaciones la recibió como configuración nueva. Producto esperaba un análisis de riesgo que no pertenecía formalmente a ninguna función.
Cada clasificación era razonable dentro de su propio marco. La incompatibilidad apareció al cruzar la frontera.
El ticket llevaba datos suficientes para registrar la demanda y no para decidirla. Una reunión adicional solo trasladó la misma ambigüedad a más personas.

Mientras el caso esperaba, Comercial dejó de prometer una fecha, Operaciones reservó capacidad que no podía utilizar y Producto abrió una revisión paralela. La falla de interfaz comenzó a consumir recursos dentro de los tres equipos.
Parte de ese costo quedó fuera del ticket. Hubo trabajo duplicado, conversaciones para reconstruir contexto y decisiones provisionales que después debieron corregirse. Medir solo los dos días de espera habría ocultado el esfuerzo absorbido por la ambigüedad.
La excepción muestra lo que el flujo estándar oculta
El equipo siguió el caso de extremo a extremo. Identificó la señal que iniciaba el traspaso, la información requerida, el tiempo máximo de espera y la decisión que nadie tenía derecho a tomar.
También distinguió el tipo de dependencia. Parte del trabajo podía avanzar en paralelo. Otra parte necesitaba una secuencia estricta. Una decisión era recíproca: cada área requería información de la otra antes de cerrar su propio criterio.
La revisión cambió la unidad de análisis. Ya no preguntó qué equipo debía “hacerse cargo”, sino qué debía contener la conexión para que las contribuciones pudieran combinarse.
Ese cambio también hizo visible el costo de decidir tarde. Mientras la excepción permanecía sin dueño, cada equipo optimizaba su propia espera y el sistema acumulaba compromisos incompatibles.
La investigación de equipos amplía el foco
Mathieu y colaboradores revisaron una década de investigación sobre efectividad de equipos. Su marco considera insumos, procesos y estados emergentes que cambian a lo largo del tiempo. No prescribe interfaces organizacionales. Sí respalda mirar coordinación e interdependencia además de atributos internos. Mathieu y colaboradores, Team Effectiveness 1997–2007, 2008 (se abre en una nueva pestaña).
El traslado útil es limitado: si el resultado depende de varios equipos, evaluar cada uno por separado no revela necesariamente la capacidad del sistema.
El rediseño ocurrió en cuatro puntos
Producto y Operaciones acordaron un criterio común para separar ajustes conocidos de configuraciones nuevas. Comercial comenzó a adjuntar un conjunto mínimo de datos antes del traspaso.
Una autoridad conjunta recibió facultad para resolver casos con impacto múltiple dentro de un umbral definido. El cierre de cada excepción devolvía una señal breve para mejorar clasificaciones futuras.
El paquete de entrada también cambió. Incluía el objetivo del pedido, la desviación frente al estándar, las restricciones conocidas y la decisión solicitada. No pretendía documentar todo el caso. Buscaba entregar lo necesario para que el siguiente equipo pudiera actuar sin reiniciar el análisis.
El umbral evitó escalar todo. Incluía impacto económico, reversibilidad y riesgo operativo. Por encima de ese límite, el caso seguía una instancia superior con información ya estructurada.
No apareció un comité permanente. La frecuencia de sincronización quedó ligada a la variabilidad y al costo de esperar.
El caso volvió a moverse
En la siguiente solicitud excepcional, los equipos conservaron sus responsabilidades. Cambió la conexión: el pedido llegó con contexto, encontró un criterio y tuvo una ruta de decisión.
La mejora no demuestra que la organización hubiera alcanzado una capacidad estable. Todavía debía observar tiempos, calidad de decisiones y nuevos tipos de excepción.
Los siguientes casos permitirían distinguir una mejora real de un episodio afortunado. Importaba revisar cuánto contexto faltaba, cuántas veces regresaba el pedido y qué excepciones seguían sin autoridad clara. La interfaz debía aprender con la variación, no congelar la primera solución.
También debía vigilar efectos laterales. Una interfaz más rápida puede trasladar presión al equipo receptor o incentivar solicitudes mal preparadas. La medida útil combina velocidad con retrabajo, claridad y distribución de carga.
Sí mostró que el problema inicial no era la ausencia de skills. Era una interfaz diseñada solo para el trabajo previsible.
Esta conclusión extiende La organización puede tener las skills correctas y el modelo operativo equivocado. El modelo operativo se vuelve tangible en los puntos donde información, autoridad y responsabilidad cruzan entre equipos.
Volvamos al caso: los equipos conservaron sus responsabilidades y el servicio volvió a moverse porque la unión cambió. La capacidad de extremo a extremo no pertenecía a una sola caja del organigrama; también vivía en la calidad de sus conexiones.
Para ampliar esta lectura, pueden consultarse De gap de skills a gap de capacidad: no siempre falta desarrollo individual y Capacidad del equipo no es el promedio de sus integrantes, que desarrollan dimensiones complementarias del problema.





