Meetings

Meetings

Before Starting

Check for EM context first. If .agents/em-context.md exists, read it.

If .agents/em-context.md does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.

If a specific person is central to the conversation and .agents/reports/[name].md does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update .agents/em-context.md or .agents/reports/[name].md automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

Response Style

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.

Default to:

• State the likely diagnosis or recommendation first
• Ask at most 2-3 targeted questions only if the missing context changes the advice
• Give the next concrete action and, when useful, exact wording the manager can use
• Mention the relevant framework briefly, but do not explain every part of it
• Offer a deeper version only after the direct answer

---

How to Use This Skill

• Wondering if something should be a meeting → Is This a Meeting?
• Running a specific meeting: who to invite, how to prep, how to facilitate → Running a Good Meeting
• Too many meetings, team can't focus, calendar fragmented → Reducing Meetings
• A recurring meeting nobody can explain → Killing Meetings That Have Outlived Their Purpose
• User shares a transcript or describes how a meeting went → Reviewing a Meeting
• Engineers always distracted, can never get into flow → Why Meetings Are Expensive (then Reducing Meetings)

---

Default Response Shape

When helping with meetings, produce a decision and operating plan:

1. Meeting decision: keep, kill, shorten, async, split, or redesign.
2. Purpose: decision, problem-solving, alignment, relationship, or information sharing.
3. Agenda / async alternative: concrete structure or written replacement.
4. Participants: who must attend and who can be informed afterward.
5. Follow-up mechanism: owner, decisions, notes, and review date.

For transcripts or past meetings, diagnose what failed and give a revised version.

---

Why Meetings Are Expensive

Your engineers are on a maker's schedule — meaningful work needs half-day blocks, not one-hour slots. A meeting at 11am doesn't cost an hour; it costs the morning, because the block before it is too short to get deep work done. When you schedule a meeting, it's routine for you and expensive for them.

Research on 600K+ pull requests shows engineers are truly productive during two windows: 9–11am and 2–4pm. Scheduling a meeting inside those windows — even a short one — kills the productive block. Put meetings at 8:30, 11:30, 1:00, or 4:00+. The difference is not marginal.

---

Is This a Meeting?

Before scheduling, identify what type of meeting this is:

• Problem-solving — the group needs to work through a problem together
• Decision-making — a decision needs to be made and requires the right people present
• Getting buy-in — you've already decided; you need alignment and commitment
• Information sharing — you're communicating something

Information sharing almost never needs a meeting. Record a Loom, send a doc, post in Slack. Reserve synchronous time for things that require real back-and-forth.

Does the decision-maker need to be there? If they can't attend, reschedule. A meeting without the decision-maker that was supposed to produce a decision produces nothing.

More than 7 people in a decision meeting is almost always too many. Every extra person adds social complexity, slows discussion, and often derails focus. People who need to be "in the loop" can get a summary.

---

Running a Good Meeting

Prepare. Every meeting needs a written agenda sent in advance — not "catch up," but a specific list of what will be covered and what outcome is expected. For complex topics, send reading material 24–48 hours ahead and ask people to arrive with a position. Meetings where everyone reads the material in the room are preparation failures.

Run it. Start on time — always. Assign a facilitator and a note-taker. When the conversation drifts, name it: "That's important — let's park it and come back." A parking lot keeps the meeting on track without dismissing valid concerns.

Drive to decisions, not discussions. A meeting that ends with "we should think more about this" has failed. End with: a decision made, a next step assigned, or an explicit statement of what information is needed and who will get it.

If you reach the goal in 20 of 60 minutes, end it.

Follow through. Send a written summary within 24 hours: decisions made, action items with owners and deadlines, open questions. Even if the meeting felt obvious, people remember it differently. The written record is the truth.

---