Anoche cerró la última convocatoria para organizar Side Events oficiales en TechCrunch Disrupt 2026: el límite era el 11 de septiembre a las 23:59 PT, según el anuncio de TechCrunch. Lo que sigue abierto, por una semana más, es la reserva de mesas de exhibición, con corte el 18 de septiembre y stock limitado (nota original). Y el mismo día, GitHub publicó cómo su equipo de marketing en Japón y Corea convirtió la operación completa de eventos en código: Marketing ops as code.
Por qué importa
Los dos deadlines son ruido de calendario. La señal está en la coincidencia: cada evento al que aplicás arrastra una cola de trabajo mecánico que nadie presupuesta. Duplicar una landing, generar links con UTM por canal, redactar la invitación, sincronizar dos boards, bajar la lista de registrados todas las mañanas, exportar asistentes, reformatear para el CRM, escribir el reporte. Nada de eso es difícil. Todo eso es exactamente donde se pega el link equivocado o se escribe mal el nombre de campaña del que dependen quince reportes aguas abajo.
La tesis del post de GitHub me parece más interesante que el caso de uso: si podés escribir cómo hacés tu trabajo, podés automatizarlo. El autor —ex ingeniero, DBA en Linux— dice explícitamente que no escribió el código: escribió sus runbooks, se los pasó a Copilot y hizo crecer la automatización conversando. Eso mueve el cuello de botella. Antes el límite era saber programar; ahora el límite es tener el proceso escrito con precisión suficiente. Y ahí es donde la mayoría de los equipos fallan, porque el runbook vive en la cabeza de una persona.
Qué cambia en la práctica
Lo que hace que esto funcione no es el modelo, son tres primitivas viejas y aburridas usadas con criterio:
- Issue forms como contrato de entrada. En vez de un textarea vacío, campos estructurados: título, fecha, región, nombre de campaña. Eso es validación en el borde. El mismo movimiento que hacés cuando dejás de aceptar un JSON libre y definís un schema.
- El issue como unidad de trabajo y de estado. El plan, la discusión y el avance viven en el mismo lugar. No hay un Sheet paralelo que se desincroniza.
- La automatización como código revisable. Si el flujo está en un repo, se lee en un PR, se versiona y se corrige. Si está en un doc de Notion, se degrada solo.
┌─────────────────────┐
│ Issue form │ fecha, región, campaña
└──────────┬──────────┘
│ un evento = un issue
▼
┌─────────────────────┐
│ Automatización │ ─► landing + links UTM
│ (runbook en código) │ ─► boards + pedido de mail
└──────────┬──────────┘
│ corrida diaria
▼
┌─────────────────────┐
│ Issue como estado │ ─► registrados + reporte
└─────────────────────┘La lectura para quien escribe software todos los días: este patrón no es de marketing. Es el mismo que aplicás a onboarding de clientes, a releases, a auditorías mensuales. Cualquier proceso que toque herramientas con API o, como aclara el propio artículo, aunque sea solamente un CLI.
| Aspecto | Runbook en un doc | Runbook como código |
|---|---|---|
| Fuente de verdad | Interpretación de quien lee | Ejecución |
| Errores típicos | Paso salteado, dato mal copiado | Falla visible y reproducible |
| Cambios | Sin historia clara | Diff y revisión |
| Transferencia | Depende de una persona | Depende del repo |
| Costo inicial | Bajo | Alto, se amortiza con repetición |
Cuándo NO usarlo
Acá va la parte honesta, porque el artículo cuenta el final feliz y no publica ni el código completo ni números de ahorro o de mantenimiento. Sin esos datos, cualquier promesa de ROI es mía o tuya, no de la fuente.
- Procesos que corrés una o dos veces. Si vas a aplicar a un Side Event por año, automatizarlo es peor negocio que hacerlo a mano. La amortización necesita repetición real, no repetición imaginada.
- Procesos que todavía cambian de forma. Automatizar un flujo inestable te obliga a rehacer el código cada vez que cambia la política interna. Primero estabilizás, después codificás.
- Cuando no tenés el runbook escrito. Acá el riesgo es el peor de todos: le pedís a un modelo que automatice un proceso que vos mismo no sabés describir, y terminás con un sistema que hace algo parecido a lo que necesitabas, sin que nadie pueda auditar la diferencia.
- Datos personales. Listas de registrados y asistentes son datos de terceros. Si tu automatización los descarga, los transforma y los postea como actualización de estado, tenés que pensar antes dónde queda ese material: logs de ejecución, artefactos, comentarios del issue. El post no entra en ese detalle y es justo lo que yo revisaría primero.
- Código generado que nadie lee. Crecer la automatización conversando con un asistente funciona mientras alguien entienda lo que quedó escrito. El día que falle a las 8 de la mañana, antes de un evento, el que la mantiene sos vos.
Qué haría hoy
No empezaría por el código. Elegiría un proceso que ya corrí al menos cinco veces, lo escribiría paso por paso como si se lo tuviera que dejar a alguien que se suma mañana, y recién ahí automatizaría el pedazo más mecánico y menos riesgoso: la generación de links y el armado de la estructura inicial. Las partes que tocan datos de personas las dejaría manuales hasta tener resuelto dónde vive cada archivo.
El deadline de las mesas de exhibición vence el 18. Ese es trabajo de calendario. Lo otro —dejar de perder dos días por evento en tareas que ya sabés de memoria— es trabajo de arquitectura, y no tiene fecha de cierre.