We Need to Schedule a Meeting to Talk About Why We Have So Many Meetings

It started as a single sentence. Nine words. "Finished the auth refactor, deploying to staging today." Clean. Informative. Done.

Then someone scheduled a standup.

The Birth of an Update

In a more innocent era — say, 2003, when developers roamed freely and Slack was just a synonym for "laziness" — that nine-word update would have been enough. You'd have shouted it across a cubicle farm, someone would have grunted in acknowledgment, and the world would have continued spinning.

Today, that same update must be processed through a gauntlet of communication rituals so elaborate that anthropologists from future civilizations will study them as evidence of a society that confused motion for progress.

First, you say it at standup. Standup, of course, is the daily ceremony where everyone stands (or pretends to stand while sitting on a WFH couch) and recites what they did yesterday, what they're doing today, and what's blocking them. The blocking part is theoretically useful. The rest is a live reading of your Jira board to people who could have just looked at your Jira board.

The Standup Recap Email

But the standup cannot simply happen. It must be documented.

Enter the Standup Recap Email — a sacred artifact created by someone who attended the standup, took notes during the standup, and then immediately wrote an email summarizing the standup for people who were also at the standup. This email will be sent to a distribution list that includes three people who left the company in 2022 and a shared inbox nobody checks.

The original nine-word update, now translated into email, reads: "Per today's sync, [Your Name] has completed work on the authentication refactoring initiative and is targeting a staging environment deployment within today's business hours, pending any unforeseen blockers. Please see the attached Confluence page for context."

The Confluence page was last updated fourteen months ago and contains a diagram that no longer reflects the actual system architecture, but it exists, and therefore it must be linked.

The Slack Thread That Ate Itself

Somewhere between the standup and the recap email, the update also lands in Slack. Not in one channel. In four.

#engineering-general, because someone wanted visibility. #deployments, because there's a bot that posts there anyway. #team-backend, because that's where your squad lives. And #random, because Dave copy-pasted the wrong thing and now the update is sandwiched between a gif of a golden retriever and a poll about lunch spots.

The Slack thread begins innocently. A thumbs-up emoji. A rocket ship. Someone typing "nice!" and then deleting it and typing "🔥" instead.

Then: "Hey, quick q — is this the auth refactor that was scoped in Q3 or the one from the technical debt sprint?"

Now there are seventeen messages in a thread. Nobody knows which auth refactor it is. The person who originally wrote the nine-word update has been tagged four times. A new Slack channel has been proposed: #auth-refactor-discussion-2024. It has been created. It has one message in it that says "testing."

The Ticket Comment Multiverse

Meanwhile, in Jira, the ticket for the auth refactor has accrued eleven comments. Three of them are from an automated bot. Two are questions that were already answered in the Slack thread. One is a comment that says "see Slack" with no further context, which future developers will find in six months and stare at like a cave painting.

The ticket's status has been moved from "In Progress" to "In Review" to "In Progress" again because someone misread the workflow. There is a sub-task. The sub-task has a sub-task. Nobody created the sub-task's sub-task intentionally. It simply appeared, the way entropy always does.

Archetypes of the Communication Apocalypse

No corporate dev team achieves this level of communicative chaos without its key players.

The Over-Documenter has written a four-page Notion doc about the deployment. It includes a background section, a decision log, an FAQ, a "future considerations" appendix, and a table of contents. It was written instead of doing the deployment. It will never be read.

The Reply-All Offender has responded to the standup recap email with "Thanks!" to all forty-seven recipients. Three people have now replied to that with "You're welcome!" The thread has achieved sentience.

The Meeting Scheduler has looked at this entire situation and concluded that what's really needed is alignment. They have sent a calendar invite for Thursday at 2 PM titled "Auth Refactor — Sync + Next Steps." The invite has no agenda. The description says "Let's connect on this." The meeting will last forty-five minutes and end with an action item to schedule a follow-up.

The Process Evangelist has seen all of this and decided the real problem is that the team doesn't have a communication framework. They are currently drafting a proposal for a communication framework. The proposal will be shared in a meeting. The meeting will be scheduled via email. The email will be discussed in Slack.

The Null Message

Here's the thing nobody wants to say out loud, the uncomfortable truth buried under all the tooling and the async-first manifestos and the "let's take this offline" energy: most of these messages should never have been sent.

The nine-word update was sufficient. The standup was optional. The email was noise. The Slack thread was a distraction wearing productivity's clothing.

There's a principle in systems design — you've probably heard it, you've probably ignored it — that the fastest operation is the one you don't perform. The most optimized query is the one that never hits the database. Apply that logic to communication and you get something radical: the most efficient message is the one never sent.

Not because transparency doesn't matter. Not because teams shouldn't communicate. But because there's a difference between information and the performance of information. One moves things forward. The other fills calendars.

A Modest Manifesto

So here, etched in the spirit of NullTerminator's founding principle that sanity begins where the code ends, is a brief productivity manifesto for the over-communicated developer:

1. If it can be a comment in the PR, it shouldn't be a Slack message.
2. If it can be a Slack message, it shouldn't be an email.
3. If it can be an email, it definitely shouldn't be a meeting.
4. If it must be a meeting, it must have an agenda, a time limit, and a person whose job it is to say "okay, we're done."
5. The standup recap email is always unnecessary.
6. "Let's take this offline" is almost never followed by taking it offline.
7. No Confluence page has ever been read by the person it was written for.
8. The best status update is a merged pull request.

The auth refactor deployed to staging at 3:47 PM. It worked fine. Nobody noticed, because they were all in the meeting about the meeting.

The nine words were right the first time.