Lately, I’ve been thinking a lot about technical meetings.
You know — those syncs, standups, grooming sessions, “quick” clarifications, architecture overviews, retro deep-dives, async that turns into sync, and everything in between.
How many of them do we really need?
I say this as someone who enjoys teamwork — but I’m starting to believe we’re seriously overdoing it.
What I’ve noticed 👇
- A “quick call” often turns into a 30–45 minute rabbit hole.
- Meetings interrupt deep focus. Even a 15-minute sync at 11:30 AM can ruin an entire productive morning.
- Half the time, the same question could be resolved in 3 Slack messages or a Loom video.
- The more people in the call — the less productive it usually is.
And most importantly:
More meetings ≠ more alignment.
Often, they’re a symptom of unclear specs, weak async culture, or trust issues.
So what’s the alternative?
Here’s what has worked for me (and the teams I’ve led):
1. ✍️ Better async workflows
Write clearer tickets. Record short Loom videos. Share architecture ideas in Notion or GitHub Issues.
2. 🎯 Fewer people in the room
Not every engineer, PM, and designer needs to be in every call.
3. ⚙️ Smarter default behaviors
Ask: “Can this be a doc?” → If yes, make a doc.
Ask: “Do I really need live feedback?” → If not, write it up.
4. 🧭 Push ownership
When developers are trusted to make technical decisions and document them, calls become rare and more impactful.
Not anti-meeting, just anti-waste
Don’t get me wrong — I’ve had great technical calls.
Collaborative design sessions, real-time debugging, or architecture whiteboarding can be amazing. But they should be the exception — not the default.
If you're in meetings all day and wondering why you're shipping less — this might be your answer.
What about you?
- How many technical calls do you have each week?
- How many of them could be async?
- What helps your team reduce meeting overload?
Let’s share ideas below 💬
Top comments (0)