gtm-operating-cadence

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Operating Cadence

运营节奏

The meeting structure that worked at 30 people collapses at 100. What worked at 100 collapses at 300. The failure mode is always the same: too many people in too many meetings making too few decisions.
在 30 人时奏效的会议结构,到了 100 人就会失灵。在 100 人时奏效的方法,到了 300 人又会失灵。失败模式始终相同:太多人参加太多会议,却做出太少决策。

When to Use

何时使用

Triggers:
  • "Our meetings don't produce decisions"
  • "We're growing but alignment is getting worse"
  • "How often should we meet?"
  • "Nobody knows what's happening across functions"
  • "Decisions take forever"
  • "Leadership is in meetings all day"
Context:
  • Companies scaling from 20 to 300+ people
  • Post-PMF through growth stage
  • Distributed / remote teams
  • Any stage where "we need to talk about this" has become the default

触发条件:
  • “我们的会议产不出决策”
  • “公司正在增长,但跨团队对齐越来越差”
  • “我们应该多久开一次会?”
  • “没人知道各个职能之间正在发生什么”
  • “决策要等太久”
  • “管理层整天都在开会”
适用情境:
  • 正在从 20 人扩张到 300 人以上的公司
  • 从 PMF 之后到增长阶段的组织
  • 分布式或远程团队
  • 任何将“我们得讨论一下”变成默认选项的阶段

Core Frameworks

核心框架

1. The Five-Level Meeting Architecture

1. 五级会议架构

The Pattern:
Different meetings serve different purposes. Conflating them creates either inefficiency (too much time) or confusion (unclear decisions). Separate meetings by function, frequency, and decision authority.
Level 1: Daily Standup (15 min, teams only)
  • What we finished yesterday, what we're starting today, what's blocking us
  • 5-10 people max. Whole-company standups are theater
  • Anti-pattern: Status reporting (use Slack, not meetings)
  • Anti-pattern: Strategic discussion (wrong time, wrong place)
  • Success criteria: Finishes in 15 minutes, surfaces 1-2 blockers
Level 2: Weekly Functional Reviews (60 min, function leadership)
Each function gets its own weekly rhythm:
  • Product team Friday 4pm: metrics, user feedback, roadmap blockers
  • GTM team Tuesday 4pm: pipeline, customer updates, deal health
  • Engineering Wednesday 4pm: velocity, bug backlog, deployment
Format: Metric recap (10 min) → Wins/blockers (15 min) → One deep-dive (30 min) → Next week priorities (5 min)
Anti-pattern: Trying to solve every problem in the meeting. Pick 1-2, delegate the rest to follow-ups.
Level 3: Weekly All-Hands (60 min, whole company)
The single most important alignment mechanism at a scaling company.
  • CEO update (15 min): north star progress, week focus, what's changed
  • Metric dashboard (10 min): same format every week (consistency enables pattern recognition)
  • Deep dive (20 min): one strategic topic needing team input — not a presentation, a discussion
  • Q&A (15 min): real questions, real answers
Anti-pattern: Defensive tone. All-hands should be straightforward, not spin. Anti-pattern: Inconsistent metrics. If you change the dashboard, the team can't track progress.
Level 4: Bi-Weekly Leadership Alignment (90 min)
  • North star progress (5 min)
  • Functional updates (30 min, 5-7 min each)
  • Major decisions needing resolution (30-40 min): resource conflicts, strategic pivots, customer/product decisions
  • Next 2 weeks planning (15 min)
This is where cross-functional blockers get resolved. If functions operate independently, this meeting isn't working.
Level 5: Quarterly Strategic Planning (half-day to full-day)
  • Previous quarter retrospective (90 min): What worked, what didn't, what we'd do differently
  • Next quarter planning (120 min): What are we optimizing for? What's the roadmap?
  • Function breakouts (90 min): Each function plans their quarter
  • Synthesis (60 min): Functions share commitments, resolve conflicts
Anti-pattern: Too much "fun activity," not enough substance. Anti-pattern: No clear decisions coming out.
Scaling Adjustments:
  • <30 people: Levels 2-3 only. Skip daily standups (you see everything). Skip bi-weekly leadership (you ARE leadership).
  • 30-100 people: Add all 5 levels. Monthly review catches what you no longer see daily.
  • 100-300 people: Add skip-level reviews. You're 2+ layers from execution.
  • 300+ people: Add function-specific sub-cadences. CEO should be in fewer meetings than at 50 — not more.
The Rule That Makes This Work:
Every meeting must produce decisions or be cancelled. Status updates are async. If you're in a meeting and nobody is making a decision, leave.

模式:
不同会议服务于不同目的。将它们混在一起,要么造成效率低下(耗费过多时间),要么造成认知混乱(决策不清晰)。应按照职能、频率和决策权限区分会议。
第 1 级:每日站会(15 分钟,仅限团队)
  • 昨天完成了什么,今天准备做什么,什么事项正在阻碍我们
  • 最多 5-10 人。全公司站会就是一场表演
  • 反模式:状态汇报(使用 Slack,不要开会)
  • 反模式:战略讨论(时间不对,地点也不对)
  • 成功标准:15 分钟内结束,识别出 1-2 个阻塞项
第 2 级:每周职能评审(60 分钟,职能负责人参与)
每个职能建立自己的每周节奏:
  • 产品团队周五下午 4 点:指标、用户反馈、路线图阻塞项
  • GTM 团队周二下午 4 点:销售管道、客户动态、交易健康度
  • 工程团队周三下午 4 点:交付速度、Bug 积压、部署情况
格式:指标回顾(10 分钟)→ 成果与阻塞项(15 分钟)→ 一项深度讨论(30 分钟)→ 下周优先事项(5 分钟)
反模式:试图在会上解决每一个问题。只选择 1-2 个问题,其余交由后续跟进处理。
第 3 级:每周 All-Hands(60 分钟,全公司)
这是规模化公司建立共同认知最重要的机制。
  • CEO 更新(15 分钟):North Star 进展、本周重点、发生了什么变化
  • 指标看板(10 分钟):每周采用相同格式(一致性有助于识别规律)
  • 深度讨论(20 分钟):一个需要团队参与的战略话题——不是单向演示,而是讨论
  • Q&A(15 分钟):真实的问题,真实的回答
反模式:防御性语气。All-Hands 应当直截了当,而不是粉饰信息。 反模式:指标不统一。如果不断更换看板,团队就无法追踪进展。
第 4 级:双周领导层对齐会(90 分钟)
  • North Star 进展(5 分钟)
  • 职能更新(30 分钟,每个职能 5-7 分钟)
  • 需要解决的重要决策(30-40 分钟):资源冲突、战略转向、客户或产品决策
  • 未来两周规划(15 分钟)
这里是解决跨职能阻塞项的地方。如果各个职能仍然各自为政,说明这个会议没有发挥作用。
第 5 级:季度战略规划(半天至一天)
  • 上一季度复盘(90 分钟):哪些做法有效、哪些无效、下次要如何改进
  • 下一季度规划(120 分钟):我们正在优化什么?路线图是什么?
  • 职能分组讨论(90 分钟):各职能规划自己的季度目标
  • 综合汇总(60 分钟):各职能共享承诺并解决冲突
反模式:“趣味活动”太多,实质内容太少。 反模式:没有产出明确决策。
规模调整建议:
  • 少于 30 人: 仅采用第 2-3 级。无需每日站会(所有情况都一览无余)。无需双周领导层会议(你自己就是管理层)。
  • 30-100 人: 加入全部 5 个层级。通过月度复盘捕捉那些无法再每天看到的情况。
  • 100-300 人: 加入 skip-level review(跨层级评审)。你与执行层之间已经相隔至少两层。
  • 300 人以上: 增加各职能专属的子节奏。CEO 参加的会议应该比公司只有 50 人时更少,而不是更多。
让这套体系奏效的规则:
每场会议都必须产出决策,否则就取消。状态更新采用异步方式。如果你身处会议,却没有人能作出决策,就离开。

2. Weekly Metric Reporting (The Dashboard That Catches Problems Early)

2. 每周指标汇报(提前发现问题的看板)

The Pattern:
Monthly reporting catches problems 30 days late. By then, a bad month is baked. Weekly reporting catches problems in week 2, when you can still save the month.
The Format (Same Structure Every Week):
WEEK OF [DATE]

North Star: [Metric]
This Week: [Value] | Last Week: [Value] | Change: [+/-] [↑↓]
Context: [One sentence — why this trend matters]

Functional Metrics:
  Product:  7-Day Retention: 34% | Last: 33% | +1% ↑
            Feature Adoption: 18% | Last: 16% | +2% ↑
            Context: Onboarding improvements showing impact

  GTM:      Pipeline: $8.2M | Last: $7.8M | +$400K ↑
            New POCs: 3 | Last: 2
            Context: Partner pipeline adding deals

  Health:   Team Morale: 7.2/10 (down from 7.5)
            Context: Org restructure causing uncertainty
The Discipline Rules:
  1. Same metrics every week. Consistency enables pattern recognition. OK to add metrics, never drop them.
  2. One context sentence per metric. Not just the number — why does this matter? Vs plan? Vs last period?
  3. Trend direction for every metric. Up/down/flat arrow. If it moved significantly: temporary or structural?
  4. Traffic light colors. GREEN (on track), YELLOW (watch), RED (action needed). Every RED item must have: owner, specific action, deadline.
The Escalation Rule:
If a metric is RED two weeks in a row with the same action plan, escalate — the action plan isn't working.
How Many Metrics:
Pick 8-12 total. If a metric doesn't change your behavior when it moves, remove it. Dashboards with 40 metrics are decoration, not decision tools.
Common Mistake:
Vanity metrics that look good but don't predict business outcomes. Total downloads without adoption context. CEO headlines without supporting metrics.

模式:
月度汇报会在问题出现 30 天后才被发现。到那时,糟糕的月份已经基本定型。每周汇报则能在第 2 周发现问题,此时仍有机会扭转结果。
格式(每周保持相同结构):
WEEK OF [DATE]

North Star: [Metric]
This Week: [Value] | Last Week: [Value] | Change: [+/-] [↑↓]
Context: [One sentence — why this trend matters]

Functional Metrics:
  Product:  7-Day Retention: 34% | Last: 33% | +1% ↑
            Feature Adoption: 18% | Last: 16% | +2% ↑
            Context: Onboarding improvements showing impact

  GTM:      Pipeline: $8.2M | Last: $7.8M | +$400K ↑
            New POCs: 3 | Last: 2
            Context: Partner pipeline adding deals

  Health:   Team Morale: 7.2/10 (down from 7.5)
            Context: Org restructure causing uncertainty
纪律规则:
  1. 每周使用相同指标。 一致性有助于识别规律。可以增加指标,但绝不能删除指标。
  2. 每个指标配一句背景说明。 不只是数字——它为什么重要?与计划相比如何?与上一周期相比如何?
  3. 为每个指标标注趋势方向。 使用上升、下降或持平箭头。如果变化显著,应判断它是暂时性的还是结构性的。
  4. 使用交通灯颜色。 GREEN(进展正常)、YELLOW(需要关注)、RED(需要行动)。每个 RED 项都必须包含:负责人、具体行动和截止时间。
升级规则:
如果某个指标连续两周为 RED,并且仍在执行同一个行动计划,就升级处理——这说明行动计划没有奏效。
指标数量:
总共选择 8-12 个。如果一个指标发生变化时不会改变你的行为,就将其删除。包含 40 个指标的看板只是装饰,不是决策工具。
常见错误:
使用看起来漂亮,却无法预测业务结果的虚荣指标。只关注总下载量,却不关注采用情况。只展示 CEO 层面的亮眼数字,却没有支撑指标。

3. Quarterly Planning (The Process That Prevents Strategic Drift)

3. 季度规划(防止战略漂移的流程)

The Pattern:
Without quarterly planning, companies drift. Each function optimizes locally. Sales chases deals outside ICP. Product builds features for one customer. Marketing runs campaigns that don't connect to pipeline.
The 3-Week Planning Cycle:
Week 1: Retrospective + Data Gathering
  • Previous quarter results vs plan (leadership prepares)
  • Each function writes 1-page retrospective: what worked, what didn't, what we'd do differently
  • Finance prepares: revenue actuals, spend actuals, forecast
  • Market data: competitive moves, customer feedback themes, win/loss analysis
Week 2: Priority Setting (Leadership Half-Day)
  • Review retrospectives (30 min — pre-read, don't present)
  • Agree on 3-5 company-level priorities
  • For each: owner, success metric, resource requirements
  • Identify what you're not doing (as important as what you are)
  • Resolve cross-functional dependencies
  • Use the north star as tiebreaker: "Does this help us hit the goal? Prioritize. Nice-to-have? Defer."
Week 3: OKR Cascade + Resource Allocation
  • Each function translates company priorities into team OKRs
  • Leadership reviews for alignment
  • Resource allocation finalized (headcount, budget, tools)
  • Final plan shared company-wide
The Quarterly Commitment Format:
Q2 2026 Roadmap
North Star: [What we're optimizing for]

Pillar 1: Product (25% team effort)
  Initiative: [Name]
    Problem: [What we're solving]
    Success: [Specific metric]
    Owner: [Name]
    Timeline: [When]

Pillar 2: GTM (50% team effort)
  Initiative: [Name]
    ...

Pillar 3: People (10% effort)
  Initiative: [Name]
    ...

Pillar 4: Tech Debt (15% effort)
  Initiative: [Name]
    ...
The "Not Doing" List:
For every priority you add, identify one thing you're stopping. If you can't name what you're not doing, you have too many priorities.
Common Mistake:
Quarterly planning that produces a 30-page doc nobody reads. The output should be: 3-5 priorities on one page, each with owner and metric. That's it.

模式:
没有季度规划,公司就会逐渐偏离方向。每个职能都在局部优化。销售追逐 ICP 之外的机会;产品为单个客户开发功能;营销开展与销售管道无关的活动。
三周规划周期:
第 1 周:复盘与数据收集
  • 上一季度结果与计划的对比(由管理层准备)
  • 各职能撰写 1 页复盘:哪些做法有效、哪些无效、下次要如何改进
  • 财务准备:实际营收、实际支出和预测
  • 市场数据:竞争动作、客户反馈主题、赢单与丢单分析
第 2 周:确定优先级(管理层半天会议)
  • 审阅复盘材料(30 分钟——提前阅读,不要现场演示)
  • 确定 3-5 个公司级优先事项
  • 为每项优先事项明确负责人、成功指标和资源需求
  • 明确哪些事情不做(与决定做什么同样重要)
  • 解决跨职能依赖关系
  • 使用 North Star 作为决胜标准:“这能帮助我们达成目标吗?优先处理。只是一项锦上添花的事?推迟。”
第 3 周:OKR cascade 与资源分配
  • 各职能将公司优先事项转化为团队 OKR
  • 管理层审阅并检查对齐情况
  • 最终确定资源分配(人员编制、预算、工具)
  • 向全公司分享最终计划
季度承诺格式:
Q2 2026 Roadmap
North Star: [What we're optimizing for]

Pillar 1: Product (25% team effort)
  Initiative: [Name]
    Problem: [What we're solving]
    Success: [Specific metric]
    Owner: [Name]
    Timeline: [When]

Pillar 2: GTM (50% team effort)
  Initiative: [Name]
    ...

Pillar 3: People (10% effort)
  Initiative: [Name]
    ...

Pillar 4: Tech Debt (15% effort)
  Initiative: [Name]
    ...
“不做事项”清单:
每增加一个优先事项,都要确定一件停止做的事情。如果无法明确不做什么,就说明优先事项太多。
常见错误:
季度规划最终产出一份 30 页、无人阅读的文档。正确的输出应该是:一页纸列出 3-5 个优先事项,每个事项都附有负责人和指标,仅此而已。

4. Decision Velocity and Authority

4. 决策速度与授权

The Pattern:
At 20 people, the CEO makes every decision in real-time. Fast. At 100 people, decisions require alignment. Slow. At 300, decisions require alignment, approval, and documentation. Glacial.
The fix isn't more meetings. It's clear decision rights.
Decision Authority Matrix:
DecisionWho DecidesTimelineEscalation
Company strategyCEO1 weekBoard if strategic
Feature priorityProduct lead1 weekCEO if >3 eng weeks
Customer support issueCSMImmediatelyCS lead if escalated
Marketing campaignMarketing lead2 weeksCMO if >$10K budget
HiringFunction leader2 weeksCEO if role not approved
New partnershipCEO2 weeksBoard if strategic
Vendor selectionFunction leader1 weekCEO if >$50K/year
The Problem:
Scaling companies start treating reversible, low-stakes decisions like irreversible, high-stakes ones. Everything needs approval. Everything needs a meeting. Everything needs consensus.
The Fix:
Type 1 (Irreversible, high-stakes): Pricing model, market entry, major partnership → CEO/leadership decides with debate in one meeting. Timeline: 1-2 weeks max.
Type 2 (Reversible, low-stakes): Campaign creative, feature prioritization, single hire → Function owner decides, informs, iterates. Timeline: same day or next day.
Make decisions with 70% information, not 100%. Speed is a competitive advantage at every stage.
Common Mistake:
Consensus culture masquerading as collaboration. "Let's get everyone aligned" often means "nobody wants to decide." Name the decider. Let them decide. Move on.

模式:
公司只有 20 人时,CEO 可以实时作出所有决策,速度很快。到了 100 人,决策需要对齐,速度变慢。到了 300 人,决策需要对齐、审批和留痕,流程慢得惊人。
解决办法不是增加更多会议,而是明确决策权。
决策授权矩阵:
决策事项决策者时限升级机制
公司战略CEO1 周战略事项升级至董事会
功能优先级产品负责人1 周超过 3 个工程周则由 CEO 决定
客户支持问题CSM立即问题升级后由 CS 负责人决定
营销活动营销负责人2 周预算超过 $10K 则由 CMO 决定
招聘职能负责人2 周岗位未获批准则由 CEO 决定
新合作CEO2 周战略事项升级至董事会
供应商选型职能负责人1 周年费超过 $50K 则由 CEO 决定
问题:
规模化公司开始把可逆、低风险的决策当成不可逆、高风险的决策。所有事情都需要审批,所有事情都需要开会,所有事情都需要达成共识。
解决办法:
Type 1(不可逆、高风险): 定价模式、市场进入、重大合作 → CEO 或管理层通过一次会议展开辩论并作出决定。时限最多 1-2 周。
Type 2(可逆、低风险): 活动创意、功能优先级排序、招聘一名员工 → 职能负责人决定,告知相关方并持续迭代。时限:当天或次日。
掌握 70% 的信息就作出决策,而不是等待 100%。 在任何发展阶段,速度都是竞争优势。
常见错误:
披着协作外衣的共识文化。“让大家先对齐”往往意味着“没有人愿意作决定”。明确决策者,让其作出决定,然后继续推进。

5. Async-First Communication

5. 异步优先的沟通方式

The Pattern:
Synchronous meetings don't scale. Default to async, escalate to sync.
Async First (No Meeting Needed):
  • Decision documents (even major ones — write up proposal, solicit comments, 48-72 hours for feedback, decide if consensus or no material objections)
  • Progress updates (use weekly reporting, not meetings)
  • Process changes and SOPs
  • Decisions already made (inform, don't discuss)
Sync When:
  • Real-time brainstorming needed
  • Major disagreement to work through
  • Complex topic needing whiteboard
  • Team building / relationship
Documentation Discipline:
Every decision documented: What was decided? Why? Who decided? When does it take effect? Who needs to know?
Store in searchable format (wiki, shared drive). New hires onboard faster. Past decisions don't get relitigated.
Common Mistake:
"Quick sync" meetings that grow to consume 10 hours per week. Over-communicating in Slack (ephemeral, noisy) and under-communicating in persistent formats (docs, emails). The important stuff should be searchable 6 months later.

模式:
同步会议无法规模化。默认采用异步方式,必要时再升级为同步沟通。
异步优先(Async First,无需召开会议):
  • 决策文档(即使是重大决策,也先撰写提案、征求意见,并留出 48-72 小时收集反馈;形成共识或没有实质性反对后再作决定)
  • 进展更新(使用每周汇报,不要开会)
  • 流程变更和 SOP
  • 已经完成的决策(告知相关方,不要重新讨论)
何时采用同步沟通:
  • 需要实时头脑风暴
  • 需要解决重大分歧
  • 需要使用白板讨论复杂主题
  • 团队建设或关系维护
文档纪律:
每项决策都要记录:决定了什么?为什么?谁作出的决定?何时生效?哪些人需要知道?
以可搜索的形式存储(wiki、共享云盘)。新员工可以更快完成入职,过去作出的决策也不会被反复翻案。
常见错误:
所谓“快速同步”的会议不断膨胀,每周占用 10 个小时。在 Slack 中过度沟通(内容短暂、嘈杂),在持久化载体(文档、邮件)中沟通不足。重要信息在 6 个月后仍应可以搜索到。

6. The CEO Weekly Update

6. CEO 每周更新

The Pattern:
The single highest-leverage communication tool at a scaling company. 5-10 minutes to write. Everyone reads it. It sets context, celebrates wins, names priorities, and creates shared understanding.
Format (Sent Sunday Night or Monday Morning):
1. Week Focus (1 paragraph): What's the priority this week? What should the team be focused on?
2. North Star Progress (1-2 bullets): Where are we on the key metric? Trend up/down/flat? Why does this matter?
3. Wins This Week (3-5 bullets): What shipped? Customer/partner wins? Big picture implication?
4. Blockers Getting Resolved (1-2 bullets): What are we unblocking this week? Who needs to know?
5. Ask (1 bullet, optional): What help does the team need? Referrals, feedback, customer introductions?
The Rule:
Same day every week. Consistency signals operational discipline. If you skip a week, the team notices — and starts wondering what you're not telling them.
Common Mistake:
Too long (team doesn't read), too detailed (save that for function meetings), only good news (team loses trust), inconsistent (team stops reading).

模式:
这是规模化公司杠杆效应最高的沟通工具。只需 5-10 分钟即可写完,所有人都会阅读。它可以设定背景、庆祝成果、明确优先事项,并建立共同理解。
格式(周日晚间或周一早晨发送):
1. 本周重点(1 段): 本周的优先事项是什么?团队应该聚焦什么?
2. North Star 进展(1-2 个要点): 关键指标目前处于什么位置?趋势是上升、下降还是持平?为什么这件事很重要?
3. 本周成果(3-5 个要点): 发布了什么?取得了哪些客户或合作伙伴层面的成果?对整体目标有什么意义?
4. 正在解决的阻塞项(1-2 个要点): 本周将解除哪些阻塞?哪些人需要知道?
5. 请求(1 个要点,可选): 团队需要什么帮助?例如推荐、反馈或客户引荐?
规则:
每周固定在同一天发送。一致性意味着运营纪律。如果跳过一周,团队会注意到,并开始猜测你还有什么没有告诉他们。
常见错误:
篇幅过长(团队不会阅读)、细节过多(这些内容应留给职能会议)、只报喜不报忧(团队会失去信任)、发送时间不固定(团队会停止阅读)。

7. Role Clarity > Titles

7. 角色清晰度比头衔更重要

The Pattern:
The most powerful tool for speed isn't hierarchy — it's explicit role clarity. When someone knows exactly what they own and can't delegate it away, decisions happen faster.
How to Execute:
  • Every initiative gets exactly one owner (with supporting teammates)
  • Metrics are tied to that owner
  • Success is measured by moving KPIs, not completing tasks
  • Eliminate initiatives without clear ownership within 48 hours
The Test:
Can you name the single person who owns this outcome? Not "the team" — a person. If you can't, the initiative will drift.
Common Mistake:
Assigning projects to multiple people ("everyone owns it" = nobody owns it). Measuring activity instead of impact. Burn rate going up without clear ROI tracking per initiative.

模式:
提升决策速度最有力的工具不是层级,而是明确的角色边界。当一个人清楚自己负责什么,并且不能把责任转嫁给别人时,决策就会更快。
执行方式:
  • 每项计划只能有一位负责人(可以配有支持成员)
  • 指标与该负责人直接关联
  • 成功以 KPI 的改善来衡量,而不是以任务完成为衡量标准
  • 48 小时内淘汰没有明确负责人的计划
检验方法:
你能否指出对这个结果负责的那一个人?不能是“团队”,而必须是一个人。如果无法指出,这项计划就会逐渐失控。
常见错误:
将项目分配给多个人(“所有人都负责”等于“没有人负责”)。用活动量而不是结果影响来衡量工作。在没有按计划追踪 ROI 的情况下,资金消耗率不断上升。

Decision Trees

决策树

Which Meeting Levels Do We Need?

我们需要哪些会议层级?

Company size <30?
├─ Yes → Levels 2-3 only (weekly functional + all-hands)
└─ No → Continue...
    │
    30-100 people?
    ├─ Yes → All 5 levels
    └─ No → All 5 + skip-level reviews + function sub-cadences
Company size <30?
├─ Yes → Levels 2-3 only (weekly functional + all-hands)
└─ No → Continue...
    │
    30-100 people?
    ├─ Yes → All 5 levels
    └─ No → All 5 + skip-level reviews + function sub-cadences

Is This Meeting Worth Keeping?

这场会议值得保留吗?

Does it produce decisions?
├─ No → Can it be async?
│   ├─ Yes → Make it async, cancel the meeting
│   └─ No → Redesign with decision agenda
└─ Yes → Are the right people in the room?
    ├─ No → Fix attendee list (fewer > more)
    └─ Yes → Keep it

Does it produce decisions?
├─ No → Can it be async?
│   ├─ Yes → Make it async, cancel the meeting
│   └─ No → Redesign with decision agenda
└─ Yes → Are the right people in the room?
    ├─ No → Fix attendee list (fewer > more)
    └─ Yes → Keep it

Common Mistakes

常见错误

1. Adding meetings as you grow Replace them. At 200 people, the CEO should be in fewer meetings than at 50.
2. Status update meetings If it can be an email, it should be an email. Meetings are for decisions.
3. Changing metrics every quarter Consistency enables trend identification. Same dashboard, every time.
4. Consensus culture Name the decider. Let them decide. Inform everyone else.
5. All information in Slack Ephemeral, noisy, unsearchable. Important decisions go in docs.
6. Quarterly planning that produces 30-page docs 3-5 priorities on one page. That's the output.

1. 随着公司增长不断增加会议 应当替换原有会议。到了 200 人时,CEO 参加的会议应该比公司只有 50 人时更少。
2. 状态更新会议 如果能够通过邮件解决,就应该使用邮件。会议是用来作决策的。
3. 每季度更换指标 一致性有助于识别趋势。每次都应使用同一份看板。
4. 共识文化 明确决策者,让其作出决定,然后告知其他所有人。
5. 所有信息都放在 Slack 中 这些信息短暂、嘈杂且无法搜索。重要决策应记录在文档中。
6. 产出 30 页文档的季度规划 一页纸列出 3-5 个优先事项。这才是最终输出。

Quick Reference

快速参考

Meeting architecture: Daily standup (15 min) → Weekly functional (60 min) → Weekly all-hands (60 min) → Bi-weekly leadership (90 min) → Quarterly planning (half-day)
Weekly metric dashboard: 8-12 metrics, same format every week, traffic light colors, one context sentence per metric, owner + action + deadline for every RED
Quarterly planning cycle: Week 1: Retro + data → Week 2: Priority setting (3-5 max) → Week 3: OKR cascade + resources
Decision authority: Type 1 (irreversible): CEO/leadership, 1-2 weeks → Type 2 (reversible): Function owner, same day
CEO weekly update: Week focus → North star progress → Wins → Blockers → Ask
Information flow: Daily: Slack wins/customer-voice → Weekly: CEO email + function updates → Monthly: All-hands + skip-levels → Quarterly: Planning share + demos

会议架构: 每日站会(15 分钟)→ 每周职能评审(60 分钟)→ 每周 All-Hands(60 分钟)→ 双周领导层对齐会(90 分钟)→ 季度规划(半天)
每周指标看板: 8-12 个指标,每周格式一致,使用交通灯颜色,每个指标配一句背景说明,每个 RED 项都要有负责人、行动和截止时间
季度规划周期: 第 1 周:复盘 + 数据 → 第 2 周:确定优先级(最多 3-5 个)→ 第 3 周:OKR cascade + 资源分配
决策授权: Type 1(不可逆):CEO 或管理层,1-2 周 → Type 2(可逆):职能负责人,当天完成
CEO 每周更新: 本周重点 → North Star 进展 → 成果 → 阻塞项 → 请求支持
信息流: 每日:Slack 中的成果与客户之声 → 每周:CEO 邮件 + 职能更新 → 每月:All-Hands + skip-level review → 季度:规划分享 + 演示

Related Skills

相关 Skills

  • enterprise-account-planning: Stakeholder management and deal cadence patterns
  • 0-to-1-launch: Launch-specific execution cadence
  • board-and-investor-communication: Board meeting structure and investor updates

Based on operating cadence design across companies scaling from 20 to 1,000+ employees, including the five-level meeting architecture that survived 3x headcount growth, the weekly reporting format that caught pipeline problems 3 weeks earlier than monthly reviews, and the CEO weekly update format refined across multiple companies. Not theory — patterns from building operating systems through hypergrowth and teaching them to the next team.
  • enterprise-account-planning:利益相关者管理和交易推进节奏模式
  • 0-to-1-launch:发布阶段专用执行节奏
  • board-and-investor-communication:董事会会议结构和投资者更新

基于对 20 至 1,000 多名员工规模扩张公司的运营节奏设计,其中包括一套经受住 3 倍人员增长考验的五级会议架构、一套比月度复盘早 3 周发现管道问题的每周汇报格式,以及在多家公司持续打磨的 CEO 每周更新格式。这不是理论——而是在超高速增长中构建运营体系,并将其传授给下一支团队所总结出的实践模式。