Startup Meeting Vocabulary

All-hands meeting vocabulary:

The all-hands (or town hall) brings together the entire company — engineering, product, sales, finance, HR — typically monthly or quarterly. It's a leadership communication ritual, not an operational meeting.

Typical structure:
1. Company update — CEO or CTO presents business health: ARR, growth, major wins
2. OKR / KPI review — progress against quarterly goals; what's on track, what's at risk
3. Product demo — engineers or PMs show what shipped recently
4. Open Q&A — employees submit and ask questions of leadership; questions can be anonymous
5. Shoutouts / recognition — public acknowledgment of individuals or teams for exceptional contributions

Vocabulary:
• all-hands — whole-company meeting (also "town hall", "company meeting")
• shoutout — public recognition; giving someone credit in front of peers ("shoutout to the infra team for zero downtime this quarter")
• open Q&A — unscripted questions from employees to leadership
• anonymous Q&A — pre-submitted questions without showing who asked (creates psychological safety)
• company update — leadership summary of business health and strategic direction
• mandatory attendance — required; not optional

War room and incident response vocabulary:

A war room is an emergent coordination space during a critical incident — a dedicated Slack channel, video call bridge, or physical conference room where all responders gather. The name reflects the urgency.

Key roles in a war room:

• IC (Incident Commander) — coordinates the response; assigns tasks; keeps the timeline; does NOT necessarily write the fix. IC separates "who is doing what" from the technical work. Often holds calls like "status check every 10 minutes"
• Comms lead — handles communication: status page updates, internal Slack messages to stakeholders, customer emails, executive updates. Shields engineers from being interrupted with "what's happening?" questions
• Responders / tech leads — engineers actively diagnosing and fixing the issue
• Observer / SME — subject matter expert on call for specific services

Common war room phrases:
• "We're on it" — acknowledgment that the team is actively working
• "Mitigation deployed" — a workaround is live; may not be the root-cause fix
• "We're rolling back" — reverting a recent deployment as a hypothesis
• "Impact radius" — scope of affected users/services
• "Status page update pushed" — public incident page updated

Vocabulary:
• war room — emergency coordination space during a critical incident
• IC (Incident Commander) — coordinates response without necessarily writing the fix
• bridge — a dedicated conference call or Slack huddle for the incident
• on-call / paged — the engineer designated to respond first to alerts
• P0 (Priority Zero) — most critical incident; production down or severe data loss
• mitigation — a temporary fix to restore service; not the root cause fix

Post-mortem (blameless) vocabulary:

A post-mortem (or incident review / retrospective) is a structured analysis of a significant incident after it is resolved. In engineering culture, the blameless format is standard.

Why blameless?
If engineers fear blame, they will hide errors and avoid reporting near-misses. Blameless culture assumes: "Given the same information and the same systems, someone else could have made the same decision." The system failed, not the person.

Typical post-mortem structure:
1. Timeline — minute-by-minute sequence of events
2. Root cause — the underlying systemic issue (not "human error")
3. Impact — duration, affected users, revenue impact, SLA breach
4. 5 Whys — iterative questioning: "why did X happen?" → answer → "why did that happen?" → 5 levels deep to find the true root cause
5. Contributing factors — factors that made the incident worse or harder to detect
6. Action items — specific tasks with owners and deadlines to prevent recurrence

Common post-mortem vocabulary:
• blameless post-mortem — analysis focused on systems, not individuals
• 5 Whys — root cause analysis technique; ask "why?" five times
• MTTR (Mean Time to Resolve) — average time from detection to resolution
• MTTD (Mean Time to Detect) — average time until the issue is noticed
• contributing factor — a condition that made the incident worse, not the root cause
• action item — specific, assigned, time-bound improvement task
• lessons learned — section of the post-mortem summarising key takeaways
• SLA breach — the incident violated a committed Service Level Agreement

OKR check-in vocabulary — status and confidence levels:

OKR check-ins are regular (weekly or biweekly) rituals to review progress. The standard vocabulary:

Status labels:
• On track — team is confident the KR will be achieved; pace is sufficient
• At risk — possible but uncertain; some blocker, dependency, or slippage exists; needs active attention
• Missed / Off track — achievement is unlikely without significant course correction; may require descoping or reprioritisation

Confidence score:
A 0-100% (or 0-10) assessment of the team's subjective belief that the KR will be achieved by quarter end. This is not a completion percentage — it's a forecast.
• 90%+ = very confident
• 65-80% = cautiously optimistic but risks exist
• 40-60% = uncertain; strong attention needed
• <40% = likely unfeasible without major change

Key distinction: confidence ≠ progress %
"KR2 is 40% numerically complete but we have 80% confidence we'll finish" (the work gets easier toward the end) — or — "KR2 is 80% complete but only 35% confidence" (a dependency is blocked and may not unblock).

OKR check-in phrases:
• "We're on track for this KR"
• "This KR is at risk — we're blocked by the data pipeline migration"
• "We're marking this as missed and carrying the learning into Q4"
• "Stretch goal" — an additional ambitious KR targeted only if the core KRs are achieved
• "Confidence moved up from 60% to 80% after the infra migration completed"

Roadmap review vocabulary:

Deprioritized
A feature is moved lower in priority relative to other work. It is NOT cancelled — it may be revisited next quarter, in v2, or when a new signal arrives. Common phrase: "We're deprioritizing X to focus on Y."

Must-have vs Nice-to-have
• Must-have — required for the core use case; without it the product does not solve the problem
• Nice-to-have — improves the experience but users can succeed without it; often deferred to a future version
• Table stakes — features expected by the market even if not differentiating (e.g., email authentication in any web app)

Scope creep
The gradual expansion of project scope beyond its original definition — often without updating timelines, resources, or priorities. Scope creep delays launches and dilutes focus.

Parking lot
A list of ideas, features, or questions set aside during a meeting or planning cycle for future review. Not a graveyard — items in the parking lot may be promoted in a future cycle.

v1 / v2 / MVP
• v1 (version 1) — the initial public release
• MVP — the smallest version that delivers core value
• v2 — the next major iteration after initial release
• "cut for v1" — a feature is explicitly excluded from the initial release

Common roadmap phrases:
• "We're shipping this quarter" — planned for release in the current quarter
• "This is in the roadmap for H2" — planned for the second half of the year, not yet scheduled
• "This is under discovery" — being researched or validated; not yet committed
• "We're killing this" — permanently cancelling, not deferring
• "Stretch goal" — a feature targeted only if the core scope ships ahead of schedule