---

name: team-communications description: > Design a delivery team's communication system — channel routing, meeting-load reduction, status structure, escalation SLAs, timezone norms. Use when the calendar is full, updates go unread, or blockers surface late. license: MIT + Commons Clause metadata: version: 1.0.0 author: borghei category: project-management domain: pm-execution updated: 2026-07-21 tags: [async, meeting-load, status-updates, escalation, timezones, team-operations]

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.
2. 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.
3. Run the auditor. Read three outputs: total annual cost, per-meeting verdicts, and per-person maker hours.
4. Publish the numbers before proposing any cut. Agreement that the total is too high has to precede the argument about any specific meeting.
5. Cancel every KILL outright, convert every ASYNC to a written update with a comment window, then merge the 60%+ audience overlaps.
6. Re-audit in six weeks. Expect 20-30% regrowth — that is normal, cut it again.

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.
2. 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.
3. 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.
4. Check the sync share. Above 34% the team is buying calendar time to compensate for thin written context; fix the writing, not the calendar.
5. Freeze the resulting rules into the charter template so the next routing argument resolves by reference instead of by seniority.

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.
3. Fix in the order the tool lists — completeness gaps first, because a missing ask costs more than a long sentence.
4. Anything under 70 does not get sent. Rewrite and re-score.
5. Keep the scores. A team whose median drifts below 70 over a quarter has a reporting problem, not a bad week.

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)