Team Communications

The operating system a delivery team runs its information on: which channel a given message belongs in, how much the recurring calendar actually costs, how a status update survives a 20-second executive skim, and what happens when someone is blocked. Most teams never design this — it accretes, one well-intentioned meeting at a time, until 30% of the week is gone and blockers still surface three days late.

When to use this skill

• The calendar is full and nobody can say why — you need the meeting load

measured in person-hours and dollars before you can argue about it

• Status updates go unread — stakeholders keep asking questions the update

already answered, which means it is not skimmable

• Blockers surface late — a problem that existed Monday first appears in

Thursday's status, because there is no escalation path with an SLA

• A team goes distributed or adds a third timezone — the sync-heavy rhythm

that worked co-located silently taxes one region

• Recurring "should this be a meeting?" arguments — you need a routing rule

the team agreed to in advance, not a per-case negotiation

• New team formation — write the charter on day one, before the calendar

fills with rituals nobody will later feel able to cancel

Inputs the skill expects

• A calendar export of recurring meetings: title, duration, cadence, attendees,

day and start time (UTC)

• The people involved with roles, timezones, and fully-loaded hourly cost
• Recent decision counts per recurring meeting (last month), plus whether each

has an agenda and written notes

• A draft status update, or a recent one that failed to land
• The team's core-hours overlap and current escalation path, if either exists
• What is currently going wrong: unread updates, late blockers, or calendar load

Clarify First

Before generating, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• ] Which failure you are fixing — load, unread updates, or late blockers — the three have opposite remedies; cutting meetings without installing written status makes late blockers worse
• ] Core-hours overlap across the team — under 3 hours the recommendation inverts from "meet on disagreement" to "sync is an escalation"
• ] Whether cancelling meetings is actually in scope — an audit you cannot act on is a grievance document; if the calendar is fixed, the leverage moves entirely to written quality
• ] Fully-loaded hourly cost, or permission to estimate it — the dollar figure is what moves stakeholders; base salary alone understates by 30-40%

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Workflows

Workflow 1 — Audit and cut the meeting load

1. Export recurring meetings into the calendar JSON shape (see

assets/sample_calendar.json): people with hourly cost and timezone, meetings with duration, cadence, attendees, day, start time.

1. Record decisions produced in the last month per meeting series, and

whether each has an agenda and written notes. This is the input the audit turns on — estimate it with the meeting owner rather than skipping it.

1. Run the auditor. Read three outputs: total annual cost, per-meeting

verdicts, and per-person maker hours.

1. Publish the numbers before proposing any cut. Agreement that the total

is too high has to precede the argument about any specific meeting.

1. Cancel every KILL outright, convert every ASYNC to a written update with

a comment window, then merge the 60%+ audience overlaps.

1. Re-audit in six weeks. Expect 20-30% regrowth — that is normal, cut it again.

bash
python3 project-management/team-communications/scripts/meeting_load_auditor.py \
  --input project-management/team-communications/assets/sample_calendar.json \
  --maker-hours-target 24 --format text

Workflow 2 — Route the week's communications

1. List the decisions, announcements and questions currently pending, one entry

each in assets/sample_messages.json shape.

1. For each, record the four routing variables: reversibility (one_way /

two_way), stakeholder count, shared context (low / medium / high), and hours until it is needed.

1. Run the router. Every message gets a channel, an urgency band, an SLA, and

the reason — which is what makes the routing defensible when someone disagrees.

1. Check the sync share. Above 34% the team is buying calendar time to

compensate for thin written context; fix the writing, not the calendar.

1. Freeze the resulting rules into the charter template so the next routing

argument resolves by reference instead of by seniority.

bash
python3 project-management/team-communications/scripts/channel_router.py \
  --input project-management/team-communications/assets/sample_messages.json \
  --core-overlap-hours 3 --format text

Workflow 3 — Score a status update before sending it

1. Draft the update against assets/status_update_template.md.
2. Score it. The tool checks the four load-bearing elements (progress, risk,

decision needed, ask), executive readability, and skimmability.

1. Fix in the order the tool lists — completeness gaps first, because a missing

ask costs more than a long sentence.

1. Anything under 70 does not get sent. Rewrite and re-score.
2. Keep the scores. A team whose median drifts below 70 over a quarter has a

reporting problem, not a bad week.

bash
python3 project-management/team-communications/scripts/status_update_scorer.py \
  --input project-management/team-communications/assets/sample_status_update.json \
  --format text

Decision frameworks

Channel routing — first rule that fires wins PROVEN]

| Rank | Condition | Channel | |------|-----------|---------| | 1 | Emotional load: performance, pay, conflict, standing | Live 1:1 | | 2 | Irreversible (one-way door) + a decision needed | Written decision record with a named approver | | 3 | 8+ people and no decision to make | Broadcast | | 4 | Low shared context + a decision needed | Live meeting with agenda and pre-read | | 5 | Decision needed within 8 hours | Live meeting — faster than one async round trip | | 6 | Everything else | Async thread |

Seniority of the requester never appears in this table. A VP wanting a meeting is not a reason; a VP lacking context is (rank 4).

Meeting verdicts — decisions per month is the test PROVEN]

| Verdict | Trigger | Action | |---------|---------|--------| | KEEP | Produces decisions, has agenda and notes | Leave it alone | | TRIM | Produces decisions but leaks structure | Fix the agenda or notes, or cut duration 25% | | ASYNC | Under 1 decision/month, or 8+ people in a "working session" | Written update + comment window | | KILL | Under 1 decision/month and no agenda | Cancel; announce the replacement channel |

Decisions per month is the best available proxy for value: countable, hard to game without actually deciding things, and it correctly kills status meetings, which produce zero decisions by design.

Load and readability thresholds RECOMMENDED]

| Metric | Healthy | Danger | |--------|---------|--------| | IC meeting hours per week | under 6h (15%) | over 10h (25%) | | Uninterrupted maker hours per week | 24h+ | under 20h | | Sync share of routed traffic | under 34% | over 50% | | Status update length | under 400 words | over 600 words | | Average sentence length | 18-22 words | over 28 words | | Quantified claims per update | 3+ | 0 |

Escalation

Acknowledgement is not resolution — "seen it, answer Thursday" fully satisfies an acknowledge SLA and stops the requester re-pinging. Escalation is a process failure signal, not an interpersonal act; say so in the charter, or the team develops silent blockers, which cost far more than the discomfort they avoid.

The full SLA ladder by urgency band and the three-strike escalation rule are in references/channel-selection-and-meeting-load.md; the charter template ships them ready to fill in.

Anti-Patterns

Watermelon Status

Mistake: Reporting green week after week, then going red two weeks before the deadline. Why it happens: Each individual week genuinely feels recoverable, and a yellow invites questions the author does not yet have answers to. Optimism compounds silently. Instead: Go yellow the week a risk becomes plausible, not the week it becomes certain, and attach an owner and a mitigation date. One defensible red buys more credibility than a quarter of unearned greens — and the scorer's risk element exists precisely to force the disclosure.

Cutting Meetings Without Installing the Written Channel

Mistake: Cancelling the status meeting and the alignment sync in the same week the audit lands, with nothing replacing them. Why it happens: The audit makes the waste vivid and the cuts feel like the whole intervention. The written replacement is unglamorous and gets deferred. Instead: Install the weekly written status first, run both for one cycle, then cancel. The meetings were carrying real information badly; removing the carrier before building a new one converts a load problem into a late-blocker problem, which is more expensive.

Escalation Treated as Aggression

Mistake: A team where going to a manager about a blocker is read as tattling, so people wait and hint instead. Why it happens: Nobody wrote down what escalation is for, so everyone infers it from the one time it went badly. Instead: Write in the charter that escalation is a process failure signal, not an interpersonal act, and specify the three strikes by role. Making the ladder public converts strike 3 into a paperwork step rather than a confrontation, because the record already exists.

Async Adopted Without Teaching Writing

Mistake: Declaring the team async-first, then watching decisions take two weeks and quietly reinstating the meetings. Why it happens: Async is treated as a channel choice rather than a skill. High Slack volume is mistaken for async maturity, when it is often level-1 verbal culture conducted in writing. Instead: Standardise the decision record shape — decision, approver, options with costs, consequences, comment deadline — before removing sync time. Escalate to a 20-minute call after two unresolved comment rounds, and post the outcome back into the doc.

The Immortal Recurring Meeting

Mistake: A meeting created for a launch three years ago that still runs weekly with six attendees. Why it happens: Nobody has standing to cancel someone else's meeting, and the original owner has left, so it has no one to defend or kill it. Instead: Give every recurring meeting an expiry date 3-6 months out at creation, plus a named owner. At expiry it is re-justified or it dies by default. Where one already exists with no owner, trial-cancel it for four weeks and ask what broke — roughly two-thirds never come back.

Files

| File | Purpose | |------|---------| | scripts/meeting_load_auditor.py | Person-hours, annual cost, KEEP/TRIM/ASYNC/KILL verdicts, double bookings, consolidation proposal | | scripts/channel_router.py | Routes each message to sync / async / written decision / 1:1 / broadcast with reasons and an SLA | | scripts/status_update_scorer.py | Scores a draft 0-100 on completeness, executive readability and skimmability | | references/channel-selection-and-meeting-load.md | Routing model, cost arithmetic, verdict rubric, consolidation, timezone regimes, escalation ladder, status thresholds, instrumentation | | references/operating-rhythm-and-charter.md | Six-ritual minimum rhythm, ritual design rules, async writing standards, channel taxonomy, maturity model, rollout sequence, failure modes | | assets/communication_charter_template.md | One-page charter: core hours, channel and meeting rules, SLAs, escalation, decision protocol, timezone norms | | assets/status_update_template.md | Update skeleton built for a 20-second executive skim | | assets/sample_calendar.json | Runnable 8-person, 8-meeting calendar export | | assets/sample_messages.json | Runnable set of 7 pending communications | | assets/sample_status_update.json | Runnable mid-quality draft (scores 50 — REVISE) |