Team Communications

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]

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]

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]