La cadencia es una función, no una reunión

La mayoría de las operaciones no se rompen por malas decisiones. Se rompen por decisiones que llegan tres días tarde. Así se diseña el timing.

Cuando la gente habla de cadencia, casi siempre piensa en el calendario: el standup del lunes, la revisión del jueves, el business review mensual. Pero la cadencia que de verdad importa no es cada cuánto te reúnes. Es qué tan rápido una decisión viaja desde que cambian los datos hasta que alguien actúa. La mayoría de los equipos amarró ese segundo reloj al primero, sin darse cuenta, y eso sale más caro que cualquier mala decisión.

Una versión que vi en el equipo de operaciones de un marketplace mediano. Una zona de entrega se queda corta de supply. El dashboard lo muestra el lunes por la mañana, clarísimo. Pero la decisión de mover incentivos a esa zona espera hasta la revisión de supply del jueves, porque ahí es donde se habla de supply. Para el jueves la brecha ya tiene tres días, y tres días de una zona floja son tres días de órdenes que se van, calladas, hacia otro lado. Pongámosle número: unas 40 órdenes al día en esa zona quedan sin cubrir, a unos $25 de contribución cada una, o sea unos $1.000 al día. Un retraso de tres días son $3.000 por incidente, y dos incidentes en una semana no es raro. Digamos $6.000 a la semana, más de $300.000 al año. Nada de eso fue una mala decisión. La decisión estaba bien. Solo llegó tres días tarde.

Este es el método que uso para resolverlo. Cuatro pasos, en orden.

1. Lista las decisiones recurrentes, no las reuniones recurrentes. La mayoría de las reuniones semanales existe para tomar dos o tres decisiones reales. Escríbelas. Todo lo demás en la agenda es estatus, y el estatus no necesita una sala.

2. Dale a cada decisión un disparador, no un horario. Una decisión debe activarse cuando se cumple una condición (una zona baja de X, una tasa de reembolsos cruza Y), no cuando llega el jueves. El calendario es un mal disparador porque el mundo no agenda sus problemas alrededor de tu standup.

3. Define un presupuesto de latencia por decisión. Hazte una sola pregunta: qué tan vieja puede ser esta decisión antes de dejar de importar. Algunas aguantan una semana. Las caras no aguantan un día. El presupuesto te dice cuáles cablear primero.

4. Conecta el disparador a los datos, no a la memoria de una persona. Esto es el pegamento de integración. La señal cruza el umbral, el responsable recibe la decisión enfrente dentro de la hora, con el contexto ya adjunto. Nadie tiene que acordarse de revisar.

El antes y el después es todo el argumento. Antes: la señal aparece el lunes, la decisión cae el jueves, y el retraso promedio a lo largo de una semana de señales queda cerca de tres días. Después: el umbral se dispara, el responsable recibe un aviso esa misma mañana con la zona, el tamaño de la brecha y el movimiento recomendado, y la decisión cae en horas. El retraso baja de tres días a menos de uno. En esa misma semana de dos incidentes recuperas más o menos dos de los tres días perdidos por incidente, unos $4.000 de los $6.000. Saca la cuenta a lo largo de un año (40 órdenes x $25 x 2 días recuperados x 2 incidentes x 50 semanas) y son unos $200.000 que se fugaban solo por timing.

¿Y la reunión? Consérvala. La revisión del jueves sigue. Solo deja de ser el lugar donde las decisiones esperan. Pasa a ser el lugar donde revisas las excepciones que marcaron los disparadores y los juicios que ninguna regla debería tomar sola. La reunión se vuelve más corta y más afilada, porque por fin hace lo único en lo que una sala de gente es realmente buena.

Ahora la parte que importa más allá de este equipo. Es el mismo muro contra el que choca todo proyecto de IA. Montar una alerta es el 30% fácil: cualquier dashboard te puede avisar por correo cuando un número se mueve. El otro 70% es lo poco glamoroso: qué decisiones merecen un disparador, cuál es el presupuesto de latencia, quién es dueño de la excepción y cómo llega la señal a la persona con el contexto para actuar. Sáltatelo y obtienes más alertas, no decisiones más rápidas, que es como los equipos terminan con 200 notificaciones y exactamente el mismo retraso de tres días.

La cadencia no es cada cuánto te reúnes. Es qué tan rápido se mueve una decisión cuando cambian los datos, y eso se construye dentro del stack, no se pone en un calendario.