WHAT GOES WRONG · LESSON 08.05intermediate

Communication breakdowns — the meeting after the meeting.

When the real conversation happens in DMs, the project is in trouble.

↳ tl;dr

Communication breakdowns rarely look like a single dramatic incident. They look like a meeting that decides nothing, followed by three side conversations that decide everything. The PM's job is bringing those side conversations into the meeting before they fragment the team.

Symptoms

  • The same decision is relitigated in different forums every week.
  • Two team members are working on incompatible assumptions for two weeks before anyone notices.
  • Sponsors hear updates from multiple sources and they conflict.
  • A side-channel (DM, hallway) becomes the "real" place decisions get made.

Root causes

  • Psychological safety gap — people don't feel safe disagreeing publicly, so they disagree privately.
  • Status meetings instead of decision meetings — public meetings inform, side conversations decide.
  • Decisions without owners — nobody's on the hook to make the call, so it gets relitigated.
  • Different stakeholders hearing different stories — usually a PM problem.

the smell test

If the meeting after the meeting is more important than the meeting, your meeting is broken. The fix isn't adding another meeting — it's making the existing meeting safe enough that the real conversation happens there.

Concrete fixes

  • End every meeting with explicit decisions, owners, and dates. Written down.
  • If a decision needs more discussion, name a deadline and a decider — don't let it drift.
  • Check public meetings against your 1:1s — if 1:1s show disagreement that didn't surface in the public meeting, you have a safety gap.
  • Standardize update channels. Sponsors hear from one source; conflicting messages get resolved before they reach leadership.

// sources

Sources cited

  1. [01]
    Rapid Development: Taming Wild Software Schedules

    McConnell, S. · Microsoft Press · 1996 · retrieved 2026-04

    Catalogues 36 'classic mistakes' of software project management.

// sources

Further reading

  1. [01]
    Rapid Development: Taming Wild Software Schedules

    McConnell, S. · Microsoft Press · 1996 · retrieved 2026-04

    Catalogues 36 'classic mistakes' of software project management.