Reuniones que deberían haber sido un pull request

Publicado el 29 de junio de 2026  •  11 minutos  • 2189 palabras

Hay una especie de ley no escrita en nuestra profesión que dice que, si una decisión técnica se puede tomar leyendo 10 líneas de código y escribiendo un comentario en un pull request, lo responsable es encerrar a diez personas una hora en una sala sin ventilación a hablar del tema.

Si además hay PowerPoint, ya se considera gobernanza.

No es exageración. En muchos equipos, la reunión es la unidad mínima de trabajo visible: si no estás en una videollamada, no estás trabajando.

Si la decisión no pasó por una sala, no fue una decisión real. Da igual que el problema esté resuelto, que el código haya mejorado o que la persona que más sabe del tema haya mandado un mensaje de tres líneas que lo dejaba todo claro.

Lo que cuenta es el proceso: el calendario bloqueado, los diez avatares conectados, el resumen de conclusiones que nadie va a releer.

Te voy a contar cómo se ve eso desde dentro, porque lo hemos vivido todos.

La reunión del enum

Un martes cualquiera, 16:00. Tienes la cabeza medio frita, pero en el calendario aparece una joya titulada: “Reunión diseño API v2”.

Te dices: “Bueno, igual hoy sí decidimos algo importante”.

Entras en la videollamada. Hay diez personas. Dos cámaras encendidas, ocho avatares, un silencio tenso como de funeral de estado.

Al cabo de cinco minutos te das cuenta de que la “API v2” es, en realidad, decidir si en un endpoint vais a devolver "status": "active" o "status": "ENABLED".

Llevas 10 años programando para ver si ahora vas a discutir el nombre de un enum durante una hora con media plantilla.

Y pasa. Se discute. Aparecen frases tipo:

• “Yo creo que ACTIVE comunica mejor la intención.”
• “Ya, pero ENABLED está más alineado con otros servicios.”
• “Podríamos hacer un mapeo en frontend…”
• “Esto va a impactar al equipo de datos, deberíamos invitarles también.”

En ese momento entra alguien con cargo de “Head of Algo” que no ha visto el código ni en pintura y dice: “A mí me gustaría que esto quedase decidido hoy”. Como si fuera la paz de Westfalia.

Y tú piensas: “Se podría haber decidido hace tres días en un PR que ya existe, pero lo rechazasteis para montar esta versión de Sálvame”.

Lo más gracioso es que, cuando acaba la reunión, las conclusiones son: que hay que abrir un documento para recoger opciones, que alguien tiene que hacer una propuesta final, y que al final lo veremos en un PR.

Es decir: una hora de tu vida para llegar exactamente al sitio al que habrías llegado si alguien hubiese abierto un pull request desde el principio, explicando la decisión en tres párrafos y dejando que los que de verdad saben del tema comentaran cuando pudieran.

Pero claro, entonces no habría habido reunión. Y sin reunión parece que no se trabaja.

La religión del “tenemos que hablarlo”

La reunión suele ser el primer reflejo, no el último recurso.

Hay un dogma implícito que viene a decir: “si no hemos hablado de esto con al menos siete personas, no podemos avanzar”.

Da igual que el tema sea cambiar un nombre de columna, elegir entre dos librerías de logging o decidir si un servicio se llama billing o invoicing.

Se convoca reunión. Siempre hay un “por si acaso” que sirve de excusa: que si esto impacta a otros equipos, que si hay riesgos que no hemos visto, que si… bueno, por si acaso.

“Por si acaso” es la versión moderna de “porque sí”.

Y ahí te ves, en una videollamada de una hora donde, en el mejor de los casos, tres personas hablan, otras tres hacen multitarea con el correo, dos están silenciadas desde el minuto uno porque se han olvidado de que la reunión existe, y una solo ha venido porque decía “arquitectura” en el título y pensaba que había que quedar bien.

Mientras tanto, el código sigue donde estaba. El problema real, también.

La asimetría perfecta: muchos opinan, uno arregla

Hay algo casi poético en estas reuniones: el reparto del trabajo.

Diez personas opinan. Una persona, normalmente la que más sabe del tema y menos ha hablado en la reunión, se come el marrón de implementarlo después.

Durante la videollamada, se sueltan ideas con una ligereza admirable.

Alguien propone guardar una versión por cada cambio. Otro apunta que estaría bien hacerlo configurable. Y un tercero sugiere dejarlo preparado por si un día se quiere multitenancy.

Todo suena razonable cuando lo dices en voz alta, sin teclado delante.

Pero luego alguien, tú, tiene que irse a su editor y convertir ese “estaría bien” en horas de código, tests, refactors, migraciones. Esa parte ya no se discute tanto. Esa parte no entra en el resumen de la reunión.

Muchas veces he pensado que la frase más sincera que se podría decir antes de arrancar sería: “Todo lo que salga de aquí lo vas a implementar tú, así que asegúrate de que no se nos va la olla”.

Cambiaría bastante el tono.

Reuniones sin contexto: opinar gratis es deporte olímpico

Otro clásico del género: te invitan a una reunión sobre una decisión técnica que no has visto jamás.

No hay documento previo. No hay enlace a código. No hay nada. Solo un título vago del estilo “Revisión estrategia caching”.

Entras, te saludan, se comparte pantalla con un diagrama que alguien acaba de dibujar en Miro hace 10 minutos, y se te pide opinión.

Opinión.

De un sistema que no has tocado, con unos requerimientos que no conoces, con unas implicaciones que nadie ha tenido tiempo de explicarte.

Claro que puedes opinar. Todos podemos opinar de todo. Pero lo que sale de ahí es ruido.

Hay estudios enteros sobre cómo decisiones técnicas importantes discutidas en grandes grupos sin preparación previa se degradan en brainstormings sin sentido. No hace falta un artículo científico: con tres años de stand-ups ya te lo hueles.

Lo que funciona de verdad existe y es sencillo: mandas antes un texto.

Una página. Dos, si te pones estupendo. Un RFC ligero , documentando el problema, la propuesta, las alternativas que has descartado y por qué.

Lo mandas un par de días antes. Dejas que la gente lo lea cuando pueda. Llegas a la reunión, si es que hace falta, a resolver las partes donde realmente no hay consenso.

Pero eso requiere escribir. Y total, escribir exige pensar. Y pensar, en muchas culturas de empresa, no cuenta como trabajo si no estás en una videollamada.

El pull request silencioso que habría ahorrado todo esto

Lo más triste de todo es que, en muchos casos, cuando por fin alguien abre un pull request con la solución, ese PR se convierte en la única discusión útil que hay sobre el tema.

En el PR, curiosamente, se ve el código real. Se ve el impacto en los tests. Se ve cómo afecta a otros módulos. Y se pueden dejar comentarios en línea, directos, sobre el código.

He visto decisiones que se habían debatido durante semanas en reuniones resolverse en tres comentarios en un PR. Tres. “Oye, esto mejor así, que si no en este caso peta.” Listo.

Es difícil no pensar que si hubiéramos empezado por ahí, nos habríamos ahorrado al menos media docena de sesiones de “brainstorming” que no eran ni lluvia ni ideas.

Un pull request bien planteado es, en el fondo, una mini-RFC: tienes contexto, tienes propuesta, tienes diff.

Además se queda registrado en el propio repositorio. Puedes revisitarlo cuando seis meses después alguien pregunte “¿y por qué se hizo esto así?”, en lugar de bucear en actas de reuniones que nadie encuentra o que nunca se escribieron.

Documentar no es hacer un acta infumable

Hay cierta alergia a la palabra “documentación” porque nos vienen a la cabeza manuales larguísimos en Confluence que nadie lee. Pero aquí estamos hablando de algo mucho más humilde: decisiones.

La mayoría de decisiones técnicas importantes caben en una página. Ni siquiera hace falta un esquema académico. Basta con explicar cuál era el problema, qué opciones se barajaron, qué se eligió y qué implicaciones tiene.

Eso, en un repositorio docs/decisions, o en un sistema de ADR (Architectural Decision Records) , es oro.

Te permite, dentro de seis meses, ver que lo hiciste así porque en ese momento había estas restricciones y no otras. Te ahorra esa sensación de “esto está mal, pero igual había un motivo que no recuerdo”.

Cuando no hay ese registro, lo que queda es la memoria oral. Y la memoria oral en empresas tech funciona como el teléfono escacharrado: “esto se hizo así porque lo pidió X”, “no, no, fue cosa de Y”, “yo creo que fue por compatibilidad, pero igual me lo invento”. Misterio histórico.

Y claro, donde falta contexto escrito, sobran reuniones.

Porque cada vez que alguien se plantea cambiar algo, hay que volver a convocar a la mitad de la plantilla para reconstruir la historia a base de opiniones vagas y nada informadas.

La reunión que sí merece existir (spoiler: es corta y con conflicto)

No estoy diciendo que toda reunión sea el demonio.

Las hay útiles, pero comparten algo: llegan cuando ya hay una propuesta escrita, la gente la ha leído y siguen quedando desacuerdos gordos que se entienden mejor cara a cara. No cuando alguien convoca porque “hay que alinear”.

También importa quién está en la sala. Si ninguno puede decidir nada por su cuenta, la reunión acaba con un “bueno, esto hay que elevarlo al comité de arquitectura y ya nos dirán”, que es otra forma de decir que seguimos exactamente igual que antes de empezar.

Y tiene que ser clara la pregunta que hay que responder. “¿Vamos por opción A o por B?”, “¿aceptamos este trade-off o no?”.

No ese tipo de reunión vagueante de “vamos viendo”, donde nadie sabe si ha acabado o sigue, ni qué significa “cerrar el tema”.

Lo cierto es que, cuando te tomas en serio lo de preparar las cosas por escrito y dejar los PRs y RFCs hacer su trabajo, esas reuniones son menos, duran menos y cansan menos.

Y donde antes tenías una hora de diez personas aportando ruido, ahora igual tienes veinte minutos de cuatro personas resolviendo un conflicto muy concreto.

Lo uno es teatro. Lo otro es trabajo.

El coste oculto de la reuniónitis

Hay una cosa que no se ve en los calendarios: el desgaste mental que genera esta cultura.

No es solo la hora de reunión. Es el tiempo que tardas en volver a entrar en el código después, la energía que dejas en conversaciones que no van a ninguna parte y la sensación de que decides menos de lo que deberías.

Acabas el día con la agenda vacía de huecos, la cabeza llena de ruido y el código casi igual que estaba por la mañana. Ese tipo de jornada, repetida semanas, quema. Y no por trabajar demasiado, sino por la sensación constante de estar ocupadísimo sin haber hecho nada importante.

Cuando empiezas a colar más PRs con buena descripción, más discusiones asíncronas bien enfocadas, más RFCs ligeros, pasa algo curioso: hay menos reuniones, sí, pero también menos sorpresas, menos “yo esto no lo sabía”, menos decisiones tomadas en despachos invisibles.

Es más difícil hacerse el loco cuando hay un documento o un diff con tu nombre debajo.

La próxima vez que te inviten a una hora para discutir un if

No tienes por qué convertirte de repente en cruzado anti-reuniones. Pero hay un gesto pequeño que cambia bastante el guion: cuando veas una reunión en el calendario sobre algo claramente acotable, prueba a decir: “Oye, ¿y si empezamos con un PR o un doc corto y a partir de ahí vemos si hace falta hablarlo?”.

A lo mejor te miran raro. A lo mejor alguien dice “esto es muy importante, mejor lo hablamos”.

Puede que no funcione la primera vez. Pero si lo haces un par de veces y demuestras que con un buen texto y un PR decente se decide más rápido y mejor, a la tercera igual la gente empieza a pedirlo.

Al final, todo se reduce a una pregunta sencilla: ¿quieres dedicar tu tiempo a escribir código y tomar decisiones con contexto, o prefieres seguir yendo a reuniones donde diez personas discuten el nombre de un enum para acabar, inevitablemente, esperando a ver qué pone en el pull request?

Yo lo tengo bastante claro.

Y mi calendario, cuando puede, también.

Fuentes y referencias

Porque hay cosas que se entienden mejor leyendo que escuchándolas en una videollamada.

• The Science of Why Brainstorming in Groups Doesn’t Work — Melissa Schilling, Inc. Por qué las sesiones de generación de ideas en grupo producen peores resultados que el trabajo individual.
• Scaling Engineering Teams via RFCs: Writing Things Down — Gergely Orosz, The Pragmatic Engineer. Cómo usar RFCs para escalar la toma de decisiones técnicas sin multiplicar las reuniones.
• Architecture Decision Record — Martin Fowler. Qué es un ADR, por qué importa y cómo estructurarlo en un repositorio.
• Meeting Statistics: 50 Data Points on Time, Cost and Productivity — Flowtrace. Datos sobre el impacto real de las reuniones en productividad, incluyendo la investigación de Gloria Mark sobre el tiempo de recuperación tras interrupciones.