meeting_operating_system v1.0.0

---

name: meeting_operating_system description: "Design or fix an organization's whole meeting system: audit the current calendar, choose which meetings should exist, set cadences, owners, agendas, pre-reads, decision rights, and decision logs, and install a quarterly review. Use when someone asks to reduce meetings, design a meeting cadence or rhythm of business, fix recurring meetings, create agenda or decision log templates, or decide if a meeting should be async."

---

Meeting Operating System

Purpose

Most teams fix meetings one at a time. The calendar stays broken because nobody designed the system: which meetings exist, why, at what rhythm, who owns each one, and what artifact each one must produce.

This skill designs that system end to end. It covers an audit of what exists now, a small set of meeting types at separate altitudes, clear decision rights, templates people will actually fill in, and a review loop that kills stale meetings before they become permanent.

Default stance: a meeting is a costly way to make a decision, unblock work, create something together, or build trust. If it does none of those, it should be a written update, a recording, or nothing.

Workflow

1. Audit before designing

Pull the last 4 weeks of calendars. That window shows recurring patterns without letting a holiday or an offsite distort the picture. For solo or small-team work, use the requester's own calendar plus any shared team calendars they can share.

Build an inventory with one row per recurring meeting, plus frequent ad hoc types. Fields: name, owner, cadence, duration, attendee count, type, stated purpose, output produced last time, decider if any.

Cost it. Use the bundled tool, and state the assumption out loud:

bash
python3 bin/meeting_cost.py cost --attendees 8 --minutes 60 --avg-salary 90000 --meetings-per-year 52
# Expected output: hourly approx $45.00, cost per meeting $360.00, annual cost $18,720.00

cat > /tmp/inventory.csv <<'CSV'
name,minutes,attendees,avg_salary,per_year,type,has_agenda,has_decider,has_output
Weekly status,60,12,80000,52,inform,no,no,no
Pipeline decision,45,6,95000,52,decision,yes,yes,yes
CSV
python3 bin/meeting_cost.py audit --csv /tmp/inventory.csv
python3 bin/meeting_cost.py score --csv /tmp/inventory.csv

Hourly rate is salary divided by 2000 working hours. It is a planning estimate, not payroll accounting. Say so in the report.

Classify each meeting into one type only:

• Decision: ends with a call that was not made before the meeting.
• Create: produces a draft, plan, design, or list together.
• Unblock: removes a specific blocker for specific people.
• Relationship: 1:1s, team rituals, customer trust. Real value, but name it honestly.
• Inform: one-way update. Default suspect for async replacement.
• Unclear: nobody can state the output. First cut candidate.

2. Apply the worth-it tests

For each meeting, ask in order. Stop at the first failure:

1. Output test: what artifact exists after this meeting that did not exist before? Decision log entry, updated plan, graded scorecard, unblocked ticket. If the answer is "everyone knows more", it fails.
2. Async test: could a written update, a short recording, or a comment thread produce the same output? If yes, move it async and keep a short live slot only for questions and tradeoffs.
3. People test: is every attendee either deciding, contributing evidence, or leaving with an action? Spectators get the notes.
4. Size test: decision meetings work best with a small group. The Amazon two-pizza idea is a heuristic, roughly 5 to 9 people, not a rule. Over 10 people in a decision meeting usually means it is really an inform meeting with a decision tacked on. Split it.
5. Duration test: could it be 25 or 45 minutes instead of 30 or 60? Calendar defaults are not evidence. Set the length from the agenda, not the other way round.
6. Cadence test: does the work actually change at this rhythm? Daily status for a monthly process is waste. Monthly review of a fast-moving incident queue is too slow.

Keep, shrink, convert to async, merge, or kill. Record the call and the reason in the audit table. A healthy redesign normally cuts or converts a chunk of inform and unclear meetings. Do not promise a specific percentage saving unless the inventory math shows it.

3. Design the cadence in layers

Separate meetings by altitude. Mixing altitudes is the most common design failure: a weekly meeting trying to do quarterly strategy runs long and decides neither.

| Layer | Typical rhythm | Question it answers | Required output | |---|---|---|---| | Daily sync | 10 to 15 min, daily or a few times a week | Is anything blocked today? | Blockers named, owner for each, no status tour | | Team weekly | 45 to 60 min, weekly | Are we on plan this week, and what are the top priorities? | Scorecard reviewed by exception, 1 to 3 priorities, decisions logged | | Cross-functional review | 45 to 60 min, weekly or biweekly | Where do teams block each other? | Tradeoffs decided, handoffs with owners and dates | | Monthly operating review | 2 to 3 hours, monthly | Are the trends real, and is the plan still right? | Targets adjusted, initiatives funded, paused, or killed | | Quarterly planning | Half day to full day, quarterly | Are we working on the right things at all? | Next quarter goals, owners, explicit not-doing list | | Annual planning | 1 to 3 days, yearly | What is next year's direction and resource bet? | Strategy, annual goals, headcount and budget envelope | | 1:1 | 25 to 50 min, weekly or biweekly | How is this person doing, and what do they need? | Notes kept by the pair, actions for both sides | | Retrospective | 45 to 60 min, per cycle or monthly | What will we change in how we work? | 1 to 3 changes with owners and a check date |

These durations are starting points from common practice, not standards. Adjust to team size and work type, and write down why when you depart from them.

Rules for the stack:

• Each layer feeds the next. Weekly exceptions that repeat become monthly topics. Monthly trends become quarterly direction questions.
• No layer repeats the layer below. Monthly reviews look at trends and variances, not a replay of four weekly scorecards.
• Every layer has one owner for the system itself, often a chief of staff, ops lead, or team lead. That person guards the templates, chases pre-reads, and runs the quarterly audit.
• Publish a one-page cadence map: every recurring meeting, its layer, day and time, owner, and output. If a meeting is not on the map, it is ad hoc and needs a reason each time.

4. Charter every surviving meeting

No recurring meeting survives without a charter. One short page, stored where attendees can find it. Use the template in references/templates.md. A charter names:

• Purpose in one sentence that ends with an outcome: "By the end, we will have decided X" or "produced Y". Ban purpose lines that end with discuss, review, or update unless the output is named right after.
• Product: the artifact, every time. Decision log entries, a graded scorecard, a prioritized list, a draft.
• People: required roles, optional roles, and who gets notes instead. Invite by role first, name second.
• Process: timeboxed agenda blocks, facilitator, decider, note taker.
• Proof: pre-read or data pack, when it lands, and how long it takes to read. Decision meetings need the pre-read at least one working day ahead, or silent reading time built into the meeting itself.
• Sunset: an end date or a review date. Recurring meetings expire. Renewal is a decision, not a default.

Apply the 5P gate before each session: Purpose, Product, People, Process, Proof. If any one is missing or fuzzy for this session, cancel that session or convert it to async. A non-zero cancel rate is a sign the gate works.

5. Fix decision rights

Slow meetings are often a decision rights problem wearing a calendar costume.

• Name one decider per decision. Use DACI for decisions: Driver runs the process, Approver makes the final call (one person), Contributors give evidence and options, Informed get the result. Use RACI for execution work that follows: Responsible does it, Accountable owns the outcome (one person), Consulted advise before, Informed hear after.
• Sort decisions by reversibility. Reversible calls, often called two-way doors, go to a small group or one owner and move fast on partial information. Irreversible or high-cost calls, one-way doors, get wider consultation, a written case, and a slower clock. Write which type each recurring decision is in the charter.
• Give many people a voice and few people a vote. Contributors can argue hard before the call. After the call, the norm is disagree and commit: execute the decision fully, and revisit only if new evidence hits a trigger named in the log.
• Escalation path: if a meeting cannot decide because the decider is absent or the tradeoff sits one level up, the output is an escalation note with options and a recommendation, sent the same day. It is never "we discussed it again next week" by default.

6. Set the pre-read and agenda standard

Two workable patterns. Pick per meeting type and write the pick into the charter:

• Pre-read ahead: pack lands at least one working day before, attendees confirm or comment ahead, live time starts at questions and tradeoffs. Best for monthly and quarterly reviews and for distributed teams.
• Silent start: for big decision meetings, open with silent reading of a short narrative memo in the room, then discuss. Amazon has used a six-page narrative memo read in silence since 2004. The point worth copying is the discipline, full sentences that expose weak logic and shared reading time so nobody bluffs, not the exact page count. Use 1 to 2 pages for most teams.

Agenda standard for every meeting, either way:

• Each item has a timebox, a lead, and a wanted outcome: decide, advise, create, or inform.
• Items are ordered by decision value, not by who shouted first. Put the hardest decision early while attention is fresh.
• The final 5 minutes are protected: read back decisions, actions, owners, and due dates out loud, and log them before anyone leaves.

7. Install the decision log and action log

One log for the whole organization or team, not one per meeting tool. Fields and examples are in references/templates.md. Minimum fields: decision ID, date, decision in one sentence, options considered, decider, contributors, rationale in 2 to 3 lines, reversibility, review trigger or date, owner for follow-through, status, link to pre-read or notes.

Habits that make the log real:

• Log in the meeting, in real time, on screen when possible.
• Open each recurring meeting by reviewing open actions and any decisions whose review date has arrived. Keep it to exceptions, not a full read-through.
• Send notes and new log entries within 24 hours. Late notes lose half their value because people act on their own memory in the meantime.
• Search the log before relitigating. If a settled decision comes back, the person reopening it brings the new evidence named in the review trigger.

8. Roll it out in four weeks

• Week 1: inventory, cost, classification. Share the numbers without blame. The calendar is a system output, not a character flaw.
• Week 2: design the cadence map and charters with the owners. Kill and convert list agreed by the deciders for each area.
• Week 3: delete, shrink, and rewrite the calendar invites. New invites carry the charter link, agenda, and pre-read deadline in the body. Protect the reclaimed time with named focus blocks or it will refill by itself.
• Week 4: run the new system, collect friction notes, fix templates fast. Tell people plainly that week 4 is a trial and what will be judged at the first quarterly review.

9. Review quarterly, or the system rots

Every quarter the system owner re-runs the audit on the last 4 weeks and reports: total meeting hours per person, cost estimate, share of hours that are recurring, agenda and decider coverage, decisions logged, actions closed on time, and any meeting with no output in 3 straight sessions. Any meeting in that last group is cancelled or redesigned on the spot.

Also ask attendees two questions per major meeting, in a form or a quick poll: did this meeting produce its stated output, and could your part have been async? Track the trend, not single bad weeks.

Output Contract

Deliver, in this order:

1. Audit table: each current meeting, type, cost estimate with the salary assumption stated, verdict (keep, shrink, async, merge, kill), and one-line reason.
2. Cadence map: one page or one table with layer, meeting, rhythm, day and time, duration, owner, required attendees by role, and output.
3. Charters for every surviving recurring meeting, using the template in references/templates.md.
4. Agenda and pre-read standard: which pattern each meeting type uses, deadlines, and the agenda format.
5. Decision log and action log: set up with fields from the template, first entries filled from the redesign decisions themselves.
6. Rollout plan: the four-week sequence with owners and dates, plus the quarterly review date and the metrics that review will check.

If the requester only wants one piece, a single meeting fixed or a template, deliver that piece and name which system step it came from. Do not force a full redesign on a narrow ask.

Operating Rules

1. Every factual claim about an outside practice must be verified or framed as practice-based opinion. Page counts, dates, and survey numbers in this skill come from the sources file kept with the production run. Do not invent new statistics about meeting waste to make a case land harder. Use the requester's own audit numbers instead. They persuade better anyway.
2. Never recommend keeping a recurring meeting with no named output, no owner, or no review date.
3. One decider per decision, one accountable owner per action. Shared ownership in the log means no ownership.
4. Status goes async by default. Live time is for decisions, tradeoffs, creation, and trust.
5. Protect the close. If a meeting runs over, it borrows from discussion, never from the final read-back of decisions and actions.
6. Do not design a cadence the team cannot staff. If nobody can own the system, shrink the system until someone can: fewer layers, simpler templates.
7. Small teams, under about 10 people, should start with three layers only: weekly, monthly, quarterly, plus 1:1s. Add layers when a real coordination pain appears, not in advance.
8. Accessibility and time zones are design inputs, not afterthoughts: rotate painful time slots for global teams, default to written pre-reads that work for people who process better in text, and keep captions and notes on for recorded sessions.
9. No em dashes in any deliverable. Use commas, periods, or colons instead.

References

• references/templates.md - charter, agenda, pre-read, decision log, action log, audit worksheet, cadence map, and cancellation note templates, with a filled example.
• bin/meeting_cost.py - cost calculator and inventory audit scorer. Run with --help on each subcommand.