Last night the final call closed for organizing official Side Events at TechCrunch Disrupt 2026: the cutoff was September 11 at 11:59 PM PT, according to TechCrunch's announcement. What's still open, for one more week, is booking exhibit tables, with a September 18 cutoff and limited stock (original post). And that same day, GitHub published how its marketing team in Japan and Korea turned their entire event operation into code: Marketing ops as code.
Why it matters
The two deadlines are calendar noise. The signal is in the overlap: every event you apply to drags along a tail of mechanical work nobody budgets for. Duplicating a landing page, generating UTM links per channel, drafting the invitation, syncing two boards, pulling the registrant list every morning, exporting attendees, reformatting for the CRM, writing the report. None of it is hard. All of it is exactly where you paste the wrong link or misspell the campaign name that fifteen downstream reports depend on.
I find the thesis of GitHub's post more interesting than the use case itself: if you can write down how you do your job, you can automate it. The author — a former engineer, a Linux DBA — says explicitly that he didn't write the code: he wrote his runbooks, handed them to Copilot, and grew the automation through conversation. That moves the bottleneck. The limit used to be knowing how to program; now the limit is having the process written down with enough precision. And that's where most teams fail, because the runbook lives inside one person's head.
What changes in practice
What makes this work isn't the model, it's three old, boring primitives used with judgment:
- Issue forms as an input contract. Instead of an empty textarea, structured fields: title, date, region, campaign name. That's validation at the edge. The same move you make when you stop accepting free-form JSON and define a schema.
- The issue as the unit of work and of state. The plan, the discussion and the progress all live in the same place. There's no parallel Sheet drifting out of sync.
- Automation as reviewable code. If the flow lives in a repo, it gets read in a PR, versioned and fixed. If it lives in a Notion doc, it rots on its own.
┌─────────────────────┐
│ Issue form │ date, region, campaign
└──────────┬──────────┘
│ one event = one issue
▼
┌─────────────────────┐
│ Automation │ ─► landing + UTM links
│ (runbook as code) │ ─► boards + email request
└──────────┬──────────┘
│ daily run
▼
┌─────────────────────┐
│ Issue as state │ ─► registrants + report
└─────────────────────┘The takeaway for anyone who writes software every day: this pattern isn't a marketing thing. It's the same one you apply to customer onboarding, to releases, to monthly audits. Any process that touches tools with an API or, as the article itself points out, even just a CLI.
| Aspect | Runbook in a doc | Runbook as code |
|---|---|---|
| Source of truth | Whatever the reader interprets | Execution |
| Typical errors | Skipped step, mis-copied data | Visible, reproducible failure |
| Changes | No clear history | Diff and review |
| Handoff | Depends on one person | Depends on the repo |
| Upfront cost | Low | High, pays off with repetition |
When NOT to use it
Here's the honest part, because the article tells the happy ending and publishes neither the full code nor any numbers on savings or maintenance. Without that data, any ROI promise is mine or yours, not the source's.
- Processes you run once or twice. If you apply to one Side Event a year, automating it is a worse deal than doing it by hand. Amortization needs real repetition, not imagined repetition.
- Processes whose shape is still changing. Automating an unstable flow forces you to redo the code every time internal policy shifts. Stabilize first, codify after.
- When you don't have the runbook written down. This is the worst risk of all: you ask a model to automate a process you yourself can't describe, and you end up with a system that does something resembling what you needed, with nobody able to audit the difference.
- Personal data. Registrant and attendee lists are third-party data. If your automation downloads them, transforms them and posts them as a status update, you have to think first about where that material ends up: execution logs, artifacts, issue comments. The post doesn't get into that detail, and it's exactly what I'd review first.
- Generated code nobody reads. Growing the automation by chatting with an assistant works as long as someone understands what got written. The day it breaks at 8 in the morning, right before an event, you're the one maintaining it.
What I'd do today
I wouldn't start with the code. I'd pick a process I've already run at least five times, write it out step by step as if I had to hand it to someone joining tomorrow, and only then automate the most mechanical, least risky piece: generating links and setting up the initial structure. The parts that touch people's data I'd leave manual until I'd settled where every file lives.
The exhibit table deadline hits on the 18th. That's calendar work. The other thing — no longer losing two days per event on tasks you already know by heart — is architecture work, and it has no closing date.