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

This is a standard code review comment. Sarah isn't proposing a new solution; she's providing feedback on existing code style. The focus here is on consistency and adherence to team guidelines, which are crucial for maintainability and collaboration. Using the correct terminology like 'naming convention' highlights this specific type of feedback.

'Activation rate' measures how effectively new users are converting into active, engaged customers. It's typically defined as the percentage of users who complete key onboarding milestones – like setting up their profile or taking a core action – indicating they intend to use the product regularly. Option A is too broad; options C and D relate to different support metrics.

A '500 error' is a standard HTTP status code representing an internal server error. This signifies that the legacy system encountered an unexpected problem while processing the request – it wasn't a client-side issue (like a bad URL) or network problem, but rather something within the server itself.

'False positives' in this scenario means the system is incorrectly flagging legitimate login attempts as errors. This could happen if intermittent network problems are misinterpreted as failed logins, leading to users being unable to access their accounts. Option A describes a security vulnerability; options C and D are related to server issues.

Emily is raising concerns about the 'performance overhead' caused by extensive logging. Detailed error logging can significantly slow down a service by adding extra processing steps – parsing logs, writing them to disk, etc. While monitoring and security are important considerations, Emily's immediate focus is on the impact of increased logging on performance.

'User engagement' in this context refers to how actively and deeply users are using a product's key features. It goes beyond simply logging in; it measures the frequency and duration of interactions with core functionalities – like creating content, sharing information, or completing tasks. Option A is just daily logins; options B and D relate to other metrics.