Skip to main content

No agenda, no meeting

2 min read
: Announcing noagendanomeeting.net — a single-page site advocating that every meeting deserves an agenda, and most meetings deserve to be a document instead.
Table of contents

You get the invite. No description. No agenda. No attached document. Just a title like “Quick sync” and a 30-minute calendar hold. You accept it anyway, because what else are you going to do — decline a meeting with your skip-level?

I’ve written before about how meetings should be a point of escalation, not a starting point. But the agenda-free meeting is an even more fundamental failure mode: it’s a meeting that hasn’t even bothered to justify its own existence.

So I made a site about it: noagendanomeeting.net.

Why this matters#

A meeting without an agenda is like calling a function without documentation — sure, it might do what you expect, but you’re forcing every caller to read the implementation to find out. Meetings without agendas force everyone to context-switch twice: once to figure out what it’s about, and again in the meeting itself when they arrive unprepared.

The average knowledge worker already spends 40% of their workweek in meetings. Without clear goals, those meetings drift, no decisions get made, and everyone leaves wondering if that could’ve been an email. (It could’ve.)

The thesis#

The site’s core argument: writing scales; meetings don’t. Before you send that invite, ask yourself: can this start as a document instead?

If the answer is yes — and it almost always is — write first, meet second. If you do need a meeting, include an agenda, attach a read-ahead, and state the decision you’re trying to make. This isn’t radical advice. It’s basic async-first communication hygiene.

What to do about it#

Next time you get a meeting invite without an agenda, try something wild: decline it. Or better yet, reply asking for one. You can even send them the link — noagendanomeeting.net is a lot more diplomatic than “I’m not attending your agenda-free ambush.”

If you manage like an engineer, you already know that undefined inputs produce undefined outputs. Meetings are no different. Define the problem before you schedule the standup.

Check it out at noagendanomeeting.net, and the next time someone sends you a mystery meeting, you’ll know exactly what link to send back.

Originally published April 6, 2026 View revision history
Share

More to explore

Our code deserves better

5 min read

I've seen multi-million dollar contracts in government, the final deliverable for which, is a CD-ROM, in triplicate. That's not how modern software development works, and our code deserves better.

Merge by committee

7 min read

Reviewing pull requests in weekly committee meetings is an anti-pattern that kills open source projects. Decentralize governance and minimize information imbalance instead.

If you liked it then you should have put a URL on it

8 min read

Every decision should have its own URL — one that captures not just what was decided, but who made the call, what arguments were weighed, and why. Your content deserves a permanent home.

The store that sells only one thing.

3 min read

Tech consultants who define themselves by a single language or framework are like a store that only sells one product. Customers come in with problems, not solutions.

Ben Balter

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world's largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub's on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform's Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub's Product team, Ben served as GitHub's Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source Help improve this article on GitHub