No necesitas otra reunión. Necesitas que alguien tome una decisión.

Hay una enfermedad que no consume CPU. No llena el disco. No dispara ninguna alerta. Y, sin embargo, puede paralizar una empresa entera. Se llama meetingitis. Sus síntomas son fáciles de reconocer. Calendario lleno. Teams abierto. Slack ardiendo. Una daily a primera hora. Una reunión para hablar de lo que se habló en la daily. Y otra reunión para decidir cuándo se hará la reunión en la que, quizá, alguien tome una decisión. Todo muy Agile. Todo muy colaborativo. Todo muy moderno. Y mientras tanto, el servidor sigue esperando.

---

La reunión que pudo ser un email

Todos hemos escuchado:

«Esto podía haber sido un email.»

Pero muchas veces tampoco necesitabas un email. Necesitabas que alguien tomara una decisión. Porque el problema no siempre es la comunicación. A veces el problema es que nadie quiere ser responsable de decidir. Así que convocamos una reunión. Hablamos. Opinamos. Nos alineamos. Tomamos notas. Creamos una tarea en Jira. Y no decidimos una mierda. Pero oye. La reunión ha ido muy bien.

---

La daily convertida en fichaje

Una daily debería servir para detectar bloqueos y mantener al equipo alineado. El problema aparece cuando se convierte en una prueba de presencia.

¿Qué hiciste ayer? ¿Qué vas a hacer hoy? ¿Cuánto te queda? ¿Por qué no estuviste? Y de repente una herramienta para facilitar el trabajo se convierte en una herramienta para demostrar que estás trabajando. La asistencia es fácil de medir. Puedes saber quién estuvo. Quién llegó tarde. Quién tenía la cámara encendida. Quién estuvo conectado. Lo que cuesta bastante más es medir qué salió de todo eso. Porque puedes pasar seis horas en reuniones y producir cero. También puedes pasar tres horas sin hablar con nadie y: - solucionar una incidencia; - automatizar un proceso; - mejorar un pipeline; - eliminar trabajo manual; - resolver un problema bloqueado durante semanas. Una persona tiene un calendario espectacular. La otra tiene resultados. Si no sabes distinguirlas, quizá tienes un problema de medición.

---

Bienvenidos al CI/CD de las decisiones humanas

En DevOps llevamos años automatizando todo lo que genera fricción. Builds. Tests. Despliegues. Infraestructura. Rollback. Observabilidad. Y después hacemos esto:

Cambiar configuración
       ↓
Abrir ticket
       ↓
Slack
       ↓
Daily
       ↓
Reunión técnica
       ↓
Aprobación
       ↓
Otra reunión
       ↓
Esperar respuesta
       ↓
Otra aprobación
       ↓
Cambiar configuración

Enhorabuena.

Has construido un pipeline CI/CD para tomar una decisión.

Sin automatización.

Sin métricas.

Y con ocho personas en el pipeline.

⸻

Esto también es deuda técnica

Estamos acostumbrados a hablar de deuda técnica.

Código antiguo.

Dependencias obsoletas.

Procesos manuales.

Arquitecturas difíciles de mantener.

Pero existe otra clase de deuda:

la deuda organizativa.

Aparece cuando nadie sabe quién puede decidir.

Cuando todo necesita aprobación.

Cuando cinco equipos tienen que reunirse para resolver algo que debería poder resolver uno.

Cuando una persona se convierte en cuello de botella.

Y cuando intentamos solucionar todo eso…

añadiendo otra reunión.

Tenemos una infraestructura moderna funcionando sobre una organización diseñada como si todavía estuviéramos esperando a que llegara el fax.

Eso también es arquitectura.

Solo que no aparece en el diagrama.

⸻

El ownership que necesita una reunión para existir no es ownership

Imagina que tienes una aplicación.

Tiene un problema.

Sabes cuál es.

Sabes cómo solucionarlo.

Tienes acceso.

Tienes permisos.

Y aun así necesitas esperar a que cinco personas se reúnan para decidir si puedes hacerlo.

Eso no es control.

Es latencia organizativa.

En DevOps queremos feedback más rápido.

Despliegues más rápidos.

Recuperaciones más rápidas.

Pero dejamos que las decisiones tarden tres días.

Tenemos pipelines capaces de desplegar en minutos y organizaciones capaces de tardar una semana en decidir si pueden desplegar.

Maravilloso.

⸻

La observabilidad también existe fuera de producción

Tenemos métricas para nuestras aplicaciones.

Latencia.

Errores.

Throughput.

Saturación.

Disponibilidad.

Entonces quizá deberíamos medir también nuestros procesos.

Por ejemplo:

• ¿Cuánto tarda una decisión?
• ¿Cuántas personas intervienen?
• ¿Cuántas reuniones necesita un cambio?
• ¿Cuántos tickets están bloqueados esperando una aprobación?
• ¿Cuánto tarda alguien en poder actuar después de detectar un problema?
• ¿Cuántas reuniones terminan sin ninguna acción?

Porque quizá descubramos algo incómodo.

Que nuestra infraestructura tiene una latencia de 200 ms.

Pero nuestra organización tiene una latencia de cuatro días.

⸻

No todo tiene que ser síncrono

A veces no necesitas una reunión.

Necesitas escribir.

Un ticket bien hecho.

Un ADR.

Una documentación decente.

Un comentario en un Pull Request.

Un registro de decisiones.

O necesitas automatizar algo.

Si alguien revisa manualmente el mismo estado todas las semanas, automatízalo.

Si alguien tiene que avisar manualmente de cada despliegue, automatiza la notificación.

Si alguien pregunta constantemente si un servicio está bien, necesitas observabilidad.

Y si siete personas tienen que reunirse para decidir si una acción rutinaria puede ejecutarse…

quizá necesitas cambiar el proceso.

No otra reunión.

⸻

El problema no son las reuniones

No.

Las reuniones no son malas.

Una reunión técnica puede resolver un problema complejo.

Una retrospectiva puede descubrir problemas reales.

Una planificación puede alinear objetivos.

Una conversación puede evitar semanas de malentendidos.

El problema aparece cuando confundimos:

comunicación

con

actividad.

Hablar no es trabajar.

Estar ocupado no es producir.

Estar conectado a Teams no significa que estés avanzando.

Y una reunión tampoco es productividad.

Es una herramienta.

Y como cualquier herramienta, depende de cómo la utilices.

⸻

La próxima vez que convoques una reunión

Hazte cuatro preguntas:

¿Qué problema vamos a resolver?

¿Qué decisión tenemos que tomar?

¿Quién puede tomarla?

¿Qué debería haber cambiado cuando terminemos?

Si nadie puede responderlas…

quizá no necesitas una reunión.

Quizá necesitas un mensaje.

Un ticket.

Documentación.

Automatización.

O simplemente que alguien tome una decisión.

⸻

La meetingitis no se cura con otra reunión

No necesitas otra ceremonia.

No necesitas otro comité.

No necesitas otra llamada para decidir si merece la pena hacer otra llamada.

Necesitas sistemas que permitan trabajar.

Procesos que reduzcan fricción.

Responsabilidades claras.

Autonomía.

Automatización.

Y reuniones que tengan una razón real para existir.

Porque una reunión no es productividad.

Una daily no es productividad.

Un calendario lleno no es productividad.

Estar disponible no es productividad.

El trabajo que sale adelante es productividad.

Y si para demostrar que alguien está trabajando necesitas contar cuántas reuniones ha atendido…

quizá el problema nunca estuvo en esa persona.

Quizá el problema estaba en el sistema.

Y, como suele ocurrir en DevOps, cuando el sistema falla constantemente…

deja de mirar al individuo y empieza a mirar la arquitectura.