Why Small Teams Need Fewer Meetings and Better Artifacts

We used to have a Monday standup, a Wednesday sync, and a Friday retro. Three people. Four, counting the contractor who joined every other week because nobody remembered to tell her she didn't need to.

None of those meetings were bad meetings. People showed up. People talked. The problem was what happened after: nothing. The decision made on Monday lived in someone's head until Wednesday, when it got re-explained slightly differently, which meant Friday's retro spent fifteen minutes figuring out which version was true.

We didn't fix this by canceling meetings. We fixed it by asking a dumber question: what, exactly, needs to still be true on Saturday, when nobody is in the room to re-explain it?

The anti-meeting crowd gets the diagnosis right and the prescription wrong

There's a whole genre of advice that says meetings are the enemy, async is the cure, and if you just replace your calendar with a Slack channel you'll ship twice as fast. We tried a version of that. It was worse, not better. Chat is fast at the moment of writing and terrible six weeks later — nobody scrolls back three hundred messages to find out why a decision got made, so they ask again, which is the same chasing-people problem meetings were supposed to solve, just wearing a different outfit.

Silence isn't the alternative to a meeting. A record is. The actual question was never "meeting or no meeting" — it was "does anything survive this conversation, or does the conversation have to happen again next week because it evaporated."

Five things that have to survive the weekend

We stopped asking "should this be a meeting" and started asking "what artifact comes out the other side." If a conversation doesn't produce one of these, we've started treating that as a signal the conversation probably didn't need to happen at all.

• A decision, written down with the reasoning attached, not just the outcome — so the next person who disagrees with it can see what was already considered
• A handoff, specific enough that the person receiving it doesn't have to schedule a call to understand it
• Task context, living with the task itself rather than in the meeting where someone explained it once
• A progress report on anything that's been running more than a day or two, so "how's it going" stops being a question anyone has to ask out loud
• A deployment or change note, written at the moment something shipped, by the person who shipped it, while they still remember why

Notice what's not on that list. Status updates that just restate the board. Brainstorms with no decision at the end. Check-ins where the honest content is "still working on it," which the task itself should already say. Those don't need to survive anything, because there's nothing in them worth preserving. We still have some of those meetings. We just stopped pretending they were productive.

Where the artifact actually has to live

This is the part most advice skips: it's not enough to write things down, because a decision pasted into a chat thread is already half-lost. It's searchable in theory and unfindable in practice, buried under a hundred other messages from the same week. A document titled "Q3 decisions" that nobody opens again is barely better.

The artifact has to live next to the thing it's about, or it doesn't get found when it's needed. The deploy note belongs with the task that shipped, not in a channel that also has lunch jokes in it. The handoff belongs on the task being handed off, not in a DM that the new owner has to dig for. The decision belongs where the work it affects actually sits, so the person doing the work three weeks later trips over the reasoning instead of having to go looking for it.

This is the actual argument for keeping chat scoped to a project or a task instead of running one giant channel for everything: a task comment and a company-wide announcement are not the same kind of memory, and merging them into one stream is how both get lost. We keep task chat on the task and project chat on the project, deliberately, because a decision that's one scroll away from the work gets read, and a decision that's two apps away does not.

The honest concession: sometimes a status call is faster

I'm not going to pretend every artifact beats every conversation. If something's genuinely ambiguous — a client relationship going sideways, a technical approach nobody agrees on — five minutes of real-time back-and-forth resolves it faster than three people drafting careful paragraphs at each other over two days. Sometimes a quick call is the efficient path, and writing a document to avoid having one is its own kind of theater.

The rule we settled on isn't "never meet." It's: if the meeting produces a decision, someone writes it down before the call ends, in the place the decision affects, not after, when memory has already started to drift. The meeting can stay. The amnesia can't.

Why we built it this way instead of bolting on a wiki

When we were designing how work should be tracked, this was the actual debate: do we add a generic notes feature, or do we make sure context has a home that matches its scope. We went with scope. A task comment is not the same artifact as a project document, which is not the same artifact as an organization-wide file, and treating them as interchangeable is exactly how retrieval fails six weeks later. In Team and Tricks, documents can live at the organization, project, or task level on purpose — a deploy note goes where the deploy happened, not in a drawer that only the person who wrote it remembers exists.

Status itself was the other place we kept running into this. A simple To Do / Doing / Done field can't hold "waiting on the client," "blocked on a dependency," or "70% done but the hard part is left." That's why checklist rows carry their own attention markers — Question, Attention, Blocked — and why Classic tasks carry progress reports instead of forcing a status dropdown to lie by omission. Those aren't meeting replacements exactly. They're what makes the meeting unnecessary in the first place, because the question someone would have asked out loud is already answered on the task.

None of this requires more process. It requires fewer places for the important sentence to go missing.

The distinction worth keeping

The failure was never that we talked too much. It was that we kept having the same conversation, because nothing from the last one made it to the next one. Cutting the meeting without fixing that just moves the forgetting somewhere quieter.

What we actually did was smaller than an anti-meeting policy: before anyone leaves a conversation, something has to be true that wasn't true before — written down, attached to the work, in a place the next person will actually look. The meeting is optional. The sentence that survives it is not.