La reunión existe porque falta una interfaz

Jueves, tres de la tarde. Seis personas entran a la misma llamada de la semana pasada. Alguien comparte una hoja de cálculo; otra persona comparte otra distinta. Los siguientes cuarenta minutos se van en averiguar cuál de las dos es la correcta.

Nadie diría que esta reunión es un fracaso. Tiene agenda, empieza a tiempo y casi siempre termina con todos de acuerdo. Dos equipos construyen una misma funcionalidad: Checkout se encarga de la pantalla donde el cliente paga y Pagos, del servicio que realmente cobra la tarjeta. Cada semana, la reunión de seguimiento responde las mismas preguntas. ¿Ya está la nueva versión del servicio de pagos en el ambiente de pruebas? ¿Quién arregla el error por el que una tarjeta rechazada muestra un mensaje de éxito? ¿«Terminado» significa que el código se integró o que ya funciona en producción? ¿Cuál es la hoja vigente?

La reunión responde cada una de esas preguntas, y ahí está el problema. El próximo jueves volverá a responderlas, porque nada de lo que resuelve queda guardado en un lugar que haga innecesaria la pregunta. Una reunión así no demuestra una cultura colaborativa. Demuestra que falta una interfaz que nadie construyó, y que la organización convirtió a las personas en la capa de integración.

Qué es, en realidad, una interfaz

Piensa en un restaurante con mucho movimiento. El salón y la cocina son dos equipos con tareas, presiones y vocabularios distintos. No se reúnen antes de servir cada mesa. El mesero anota una comanda (número de mesa, platos, cambios, alergias) en un formato que la cocina ya sabe leer. Nadie en la cocina tiene que preguntar qué significa «sin cebolla» ni quién llevará el plato. Esas preguntas se respondieron una sola vez, cuando el restaurante definió cómo funciona una comanda.

Esa comanda es una interfaz: un acuerdo sobre qué cruza la frontera entre dos partes, con qué forma y con qué puede contar cada lado una vez que cruza. En software, la versión conocida es la API, una forma publicada para que un programa le pida algo a otro sin saber cómo funciona por dentro. Un servicio de pagos puede prometer lo siguiente: envíame un monto, una moneda y una referencia de tarjeta, y en menos de dos segundos te responderé aprobado, rechazado o error, nunca otra cosa. El equipo que lo usa puede construir sobre esa promesa sin convocar a nadie.

Las organizaciones necesitan lo mismo entre personas, y la mayoría de las interfaces que les faltan no son técnicas. Una interfaz puede ser un responsable con nombre para el espacio entre dos equipos, una definición escrita de «terminado» que ambos usan o una regla que indica qué despliegues requieren aprobación humana y cuáles no. También puede ser un nivel de servicio que fija en cuánto tiempo se atiende una solicitud, una ruta de escalamiento para cuando no se atiende o un único lugar acordado donde vive el estado actual. Todas comparten la propiedad que importa: una vez que el contrato existe, una parte puede contar con la otra sin reabrir la conversación.

Si se quita la comanda, el restaurante no deja de servir. Los meseros entran a la cocina y explican cada pedido en voz alta. Funciona, lento, hasta la hora pico. Eso son muchas reuniones recurrentes de coordinación: la conversación en la cocina que reemplazó una comanda que nadie diseñó.

La reunión como middleware

El software tiene un nombre para la capa que conecta sistemas que nunca se diseñaron para hablar entre sí: middleware. Mueve datos de un lado al otro, traduce formatos y absorbe incompatibilidades para que cada parte se comporte como si la conexión fuera nativa. Mira otra vez la agenda del jueves con esa palabra en mente. Informar el estado de una herramienta que solo un equipo puede ver es transporte de datos. Traducir el «terminado» de un equipo al del otro es conversión de formato. Conciliar dos hojas de cálculo es resolver un conflicto entre dos copias de la verdad. Decidir quién se hace cargo del error de la tarjeta rechazada es enrutamiento. Sin los saludos ni la pantalla compartida, lo que queda es una capa de integración que se ejecuta sobre seis personas.

Vista así, la reunión puede evaluarse como un ingeniero evaluaría cualquier integración, y no sale bien parada en ninguno de estos cinco criterios:

• Consulta en lugar de reaccionar. Una interfaz bien construida avisa del cambio cuando ocurre: falla la compilación, se actualiza el estado, se notifica al responsable. Una reunión semanal revisa una vez cada siete días. Lo que cambia el viernes espera hasta el jueves siguiente, de modo que el tiempo de reacción de la organización lo fija una invitación recurrente y no el trabajo.
• Pierde información. Los datos viajan de palabra, se resumen de memoria y terminan en notas que nadie relee. No hay un esquema, una forma acordada para los datos, así que la misma palabra llega con significados distintos a cada lado. El «listo» que dice Checkout y el «listo» que entiende Pagos no describen el mismo estado.
• No deja un registro confiable. Un middleware de verdad guarda una bitácora de qué se envió, cuándo y si llegó. La reunión guarda lo que alguien se acordó de anotar. Tres semanas después, nadie puede decir con seguridad cuándo se tomó una decisión, ni si de verdad se tomó.
• Depende de un solo nodo. Muchas de estas reuniones se sostienen sobre una persona que de verdad entiende cómo encajan ambos lados. Cuando esa persona sale de vacaciones, la reunión se cancela y la integración se cae en silencio con ella.
• No escala. Cada equipo nuevo que depende de la misma frontera suma asistentes, no capacidad. La reunión se alarga y, al poco tiempo, necesita una reunión previa.

Nada de esto aparece como partida en un presupuesto. Seis personas durante una hora a la semana suman más de trescientas horas-persona al año, sin contar la preparación, los pendientes que deja ni el cambio de contexto antes y después de la llamada. El costo mayor ni siquiera tiene factura: toda decisión que pudo tomarse el lunes espera al jueves, y todo dato que la reunión transporta llega con hasta una semana de antigüedad.

Por qué el parche sobrevive tanto

Si la reunión es una interfaz tan pobre, ¿por qué dura años? Porque es lo más barato de empezar y lo más caro de detener.

Crear una reunión cuesta una invitación de calendario y no requiere permiso de nadie. Construir la interfaz exige negociar. Alguien tiene que acordar qué significa «terminado», asumir la responsabilidad del vacío, financiar la página de estado compartida o escribir la regla que elimina una aprobación manual. Ese trabajo vive en la misma frontera donde vive la reunión, y por eso mismo nadie lo asume. Mientras tanto, la reunión hace un trabajo real y visible. La gente sale de ella informada y alineada, y esa sensación no es falsa; simplemente se vuelve a pagar cada semana.

Debajo de esto hay una idea más antigua. En 1968, Melvin Conway planteó que los sistemas que diseña una organización tienden a copiar su estructura de comunicación. Leída al revés, la idea convierte las reuniones recurrentes en un mapa. Una reunión fija entre dos equipos señala un punto donde la forma de la organización y la forma de sus sistemas no coinciden: el diagrama de arquitectura muestra una frontera limpia y las personas saben que no la hay. La reunión es donde se paga ese desacuerdo.

Team Topologies ofrece un vocabulario más preciso para el mismo vacío. Trata la colaboración estrecha entre equipos como un modo deliberado, valioso mientras ambos todavía descubren cómo encaja su trabajo y conveniente solo por un tiempo. La contrasta con consumir algo como servicio, donde un equipo provee una capacidad y el otro confía en una frontera clara. Desde esa perspectiva, una colaboración que nunca termina suele ser una frontera de servicio que nadie terminó de definir.

No toda reunión indica que falta una interfaz

La versión perezosa de este argumento dice que las reuniones son desperdicio y que la meta es un calendario vacío. Eso es absurdo, y fracasa en la práctica la primera vez que ocurre algo realmente nuevo.

Algunas reuniones hacen un trabajo que ninguna interfaz puede absorber. La deliberación, la negociación y el trabajo creativo de verdad exigen que varias personas piensen juntas. Las decisiones bajo incertidumbre real necesitan criterio, no una consulta. Un incidente que nadie anticipó requiere el intercambio rápido y flexible que solo da una conversación en vivo. Una revisión de riesgos puede repetirse porque las condiciones cambian, no porque falte un contrato. Las reuniones también hacen cosas que ninguna interfaz debería intentar: construyen confianza entre personas que se van a necesitar bajo presión y sacan a la luz el problema que a nadie se le ocurrió registrar en un campo.

La distinción útil está entre una reunión que crea algo y otra que transporta algo. La primera produce una decisión, un plan o un entendimiento que no existía antes de reunirse. La segunda mueve información que ya existía, o resuelve una ambigüedad que debió aclararse una vez y quedar por escrito. Hay una forma sencilla de distinguirlas: leer las minutas. Si las del mes pasado pudieran pegarse en las de esta semana cambiando solo las fechas, la reunión transporta estado. Si cada minuta registra una decisión distinta, la reunión hace aquello para lo que sirven las reuniones.

Guía de decisión

Cómo clasificar una reunión fija

Cancelar reuniones sin criterio solo traslada la coordinación a hilos de chat y conversaciones de pasillo. Conviene, en cambio, tomar cada punto recurrente de la agenda y pasarlo por estas preguntas, en orden, hasta llegar a la primera que aplique:

1. ¿Produce una decisión que antes no existía? Consérvalo y dale lo que una decisión necesita: insumos definidos, alguien con autoridad para decidir y una cadencia acorde con la velocidad a la que cambia la situación.
2. ¿Transporta un dato que ya existe en otro lugar? Haz visible ese dato donde vive, en el gestor de tareas, en el registro de despliegues o en una página de estado en la que ambos equipos confíen, para que nadie tenga que leerlo en voz alta. La interfaz que falta es una fuente única de verdad.
3. ¿Resuelve la misma pregunta que resolvió la vez anterior? Deja la respuesta por escrito una sola vez, como definición, regla o responsable con nombre. La interfaz que falta es una política.
4. ¿Espera un compromiso de otro equipo? Convierte el compromiso en un contrato: qué se entrega, en qué forma, para cuándo y qué pasa si se retrasa. La interfaz que falta es un acuerdo de servicio.
5. ¿Sigue sin estar claro? Suspende ese punto durante dos ciclos y anota qué se rompe. En operaciones lo llaman «prueba del grito»: apagar algo y ver quién se queja. Lo que se rompa le pone nombre a la interfaz que la reunión estaba supliendo.

Aplica la guía a la agenda del jueves. La pregunta sobre el ambiente de pruebas desaparece cuando el pipeline de despliegue publica qué versión corre en cada lugar. La conciliación de hojas desaparece cuando una se retira y la otra se declara la oficial. La definición de «terminado» se escribe una vez y se enlaza desde los tableros de ambos equipos. El error de la tarjeta rechazada revela el vacío real: nadie responde por las fallas que cruzan de un servicio al otro, y eso exige un responsable con nombre y una ruta de escalamiento, no una conversación semanal. Lo que queda, decidir si conviene cambiar cómo se reintentan los pagos fallidos antes de la temporada de fiestas, es una decisión genuina que necesita a ambos equipos. Esa sí merece una reunión, probablemente más corta.

El reemplazo también puede salir mal

Una interfaz no es mejor por el solo hecho de reemplazar una reunión. Automatizar una ambigüedad no la elimina; solo la acelera. Aplicar una regla rígida a una decisión que de verdad exige criterio produce peores decisiones y devuelve a todos a una reunión para saltarse la regla. Un panel en el que nadie confía se convierte en otra pestaña que se abre antes de la llamada de estado. Y un contrato que nadie puede cumplir solo muda la reunión de lugar: el seguimiento semanal se convierte en una revisión semanal de excepciones.

El trabajo consiste en separar dos cosas que la reunión venía mezclando. La información que transporta debe pasar a un sistema que la lleve de forma confiable, continua y con registro. El criterio que ejerce con legitimidad debe quedarse con personas concretas, que ahora pueden dedicar su atención a ese criterio en vez de reconstruir cómo están las cosas. Mover lo primero sin perder lo segundo es todo el trabajo.

Volvamos al jueves a las tres. Si las interfaces existen, la llamada no tiene por qué desaparecer. Puede convertirse en veinte minutos sobre la única pregunta que de verdad necesita a ambos equipos, con todos llegando ya enterados de cómo están las cosas, porque el estado actual dejó de ser algo que alguien tiene que cargar a mano de un lado al otro. Esa es la prueba para cualquier reunión fija: ¿crea algo o compensa algo que la organización debió construir una sola vez? Lo primero hay que protegerlo. Lo segundo no es colaboración, sino una decisión de diseño que se pospone una invitación de calendario a la vez.

Notas de fuentes

Estas fuentes respaldan los conceptos sobre fronteras organizacionales. La reunión del jueves entre Checkout y Pagos y la comanda del restaurante son ejemplos hipotéticos. El encuadre de «middleware humano», la comparación con una integración y la guía de decisión son una síntesis del artículo y no se atribuyen a ninguna de las dos fuentes.

• Modos de interacción y fronteras entre equipos. Skelton y Pais describen modos explícitos de interacción entre equipos, entre ellos la colaboración y el consumo de una capacidad como servicio, y presentan la colaboración sostenida como costosa y más adecuada para etapas de descubrimiento. Fuente: Matthew Skelton y Manuel Pais, Team Topologies.
• Los sistemas reflejan las estructuras de comunicación. Conway sostiene que las organizaciones que diseñan sistemas producen diseños que copian sus propias estructuras de comunicación. Fuente: Melvin E. Conway, «How Do Committees Invent?», 1968.