Async-First Communication
Meetings are the #1 productivity killer in consulting teams. Our goal: reduce meetings by 80% and replace them with structured async communication in GitLab.
The Meeting Budget
| Meeting | Frequency | Duration | Attendees | Purpose |
|---|---|---|---|---|
| Weekly Sync | Monday AM | 15 min max | Entire team | Review milestone progress (from GitLab board — no status updates, just blockers). Set priorities for the week. |
| Spec Review | On-demand | 30 min max | Spec author + Tech Lead + 1 dev | Only for complex/ambiguous specs. Most specs are reviewed async via GitLab comments. |
| Demo | End of cycle (bi-weekly) | 30 min | Team + stakeholders | Show what shipped. Celebrate wins. Collect feedback. |
| Retro | Monthly | 45 min | Entire team | What worked, what didn't, what to change. Decisions logged in GitLab wiki. |
That's it. ~2 hours of meetings per week for the entire team. Everything else happens in GitLab issues, MR comments, and the team chat channel.
Async Communication Rules
- Questions about a feature? Comment on the GitLab issue. Ping the spec author with
@name. - Code discussion? Comment on the Merge Request — in the code, at the exact line.
- Architecture question? Create a GitLab issue with label
type::spikeand write your question as a structured doc. Others respond async. - Urgent blocker? Team chat channel. But if it's a real blocker, it should also be a GitLab issue with
priority::critical. - "Can I get a quick call?" Sure — but document the outcome in the relevant GitLab issue within 1 hour. If it's not worth documenting, it probably wasn't worth the call.
Why This Works
Written communication forces clarity. You can't hand-wave in a GitLab comment the way you can in a meeting. And everything is searchable, linkable, and permanent. New team members can read the history. AI can consume the context. Future you will thank present you.