How to keep engineers out of meeting hell
Engineers describe how excessive, poorly run meetings destroy focus and productivity, especially for “maker” roles that depend on long, uninterrupted blocks of time. Commenters argue that meetings are only valuable when they have clear agendas, defined outcomes, documented decisions, and the right attendees—and that many status updates and planning sessions should instead be handled asynchronously. Underlying the complaints are deeper issues of incentives and management style: meetings often become a visibility tool for managers or a workaround for bad email/async habits, prompting some engineers to set hard boundaries, decline low-value invites, and push for fewer but more purposeful gatherings.
Why meetings feel like “hell”
- Many see meetings as low-impact compared with coding; often nobody creates tangible value.
- Context switching is a major pain point; scattered 1‑hour meetings can wipe out whole days of productive “flow.”
- Zoom makes it trivial to add people “just in case,” inflating attendee lists and time costs.
What makes meetings effective vs useless
- Strong support for: clear agenda, desired outcomes, pre‑reads, a moderator, a note‑taker, published minutes, and explicit action items with owners.
- Without these, it’s “just a chat” and should be async or 1:1.
- Good use cases: genuinely uncertain topics, cross‑team coordination, real decisions where stakeholders must hash out unknowns.
- Bad use cases: status updates, reading documents together, vague “discuss” sessions, or offloading decisions and accountability to the group.
Strategies engineers use to protect time
- Decline or leave meetings with no agenda, unclear need, or when not adding/receiving value.
- Enforce “law of two feet”: walk out if you can’t contribute.
- Block calendar for maker time; sometimes adopt “no‑meeting” blocks, though these can ironically attract more meetings.
- Push organizers to justify attendance and send agendas; some develop a “mystique” by being selective.
Async communication vs meetings
- Many argue most meetings could be email or chat, especially decisions, status, and information sharing.
- Counterpoint: poor email hygiene (huge unread counts, low response rates) forces meetings as “insurance” to get answers.
- Filters and better email discipline are suggested but seen as ongoing work; others argue the real fix is reducing noise at the source.
Standups, agile ceremonies, and volume
- Frequent complaint: daily standups, long “ceremonial” Scrum events, and PI planning that provide little value and rapidly drift off-topic.
- Reports of 12–16 meeting hours per week for individual contributors, leaving little contiguous coding time.
- Some teams thrive with minimal process (one short weekly meeting plus ad‑hoc discussions); others rely on brief daily syncs that work well.
Pair programming debate
- Some equate scheduled pairing with “one long meeting.”
- Others strongly disagree, saying good pairing is active joint coding, highly productive in the right culture, especially for learning and knowledge sharing.
- Middle view: pairing should be used “as needed”; full‑time pairing can be tiring and must justify doubled headcount on a task.
Management, incentives, and career impact
- Several blame incentive structures: some managers gain visibility and perceived importance by generating meetings and activity.
- Others note that meetings are genuine management work for coordination and alignment, especially in complex physical‑engineering projects.
- Extreme anti‑meeting stances can backfire: if you refuse both meetings and async participation, it’s viewed as career‑limiting.
- Disagreement over whether “meetings are the only way to grow your career”; some organizations still reward delivery above all.