[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ADPBS680SB9VRX0EC11ZM8":3,"skill-same:01M6ADPBS680SB9VRX0EC11ZM8":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6ADPBS680SB9VRX0EC11ZM8","gtm-operating-cadence",null,"Design meeting rhythms, metric reporting, quarterly planning, and decision-making velocity for scaling companies. Use when decisions are slow, planning is broken, the company is growing but alignment is worse, or leadership meetings consume all time without producing decisions.","github\u002Fawesome-copilot","github","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9919?v=4","01M6AC83DS133TPXFSP1DHNCC6","GitHub","01M6AD3PBDYPK7NVFJNJ66Y8RS",41081,"MIT","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fgtm-operating-cadence\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,9],"operating cadence","cadence","gtm operating cadence","operating","gtm","velocity","when","company","metric","scaling","leadership","time","design","but","alignment","broken","decision","reporting","https","product","planning","2026-11-10 10:12:30",false,"---\nname: gtm-operating-cadence\ndescription: Design meeting rhythms, metric reporting, quarterly planning, and decision-making velocity for scaling companies. Use when decisions are slow, planning is broken, the company is growing but alignment is worse, or leadership meetings consume all time without producing decisions.\nlicense: MIT\nmetadata:\n  author: Smit Patel (https:\u002F\u002Flinkedin.com\u002Fin\u002Fsmitkpatel)\n  source: https:\u002F\u002Fgithub.com\u002Fbeingsmit\u002Ftechnical-product-gtm\n---\n\n# Operating Cadence\n\nThe 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.\n\n## When to Use\n\n**Triggers:**\n- \"Our meetings don't produce decisions\"\n- \"We're growing but alignment is getting worse\"\n- \"How often should we meet?\"\n- \"Nobody knows what's happening across functions\"\n- \"Decisions take forever\"\n- \"Leadership is in meetings all day\"\n\n**Context:**\n- Companies scaling from 20 to 300+ people\n- Post-PMF through growth stage\n- Distributed \u002F remote teams\n- Any stage where \"we need to talk about this\" has become the default\n\n---\n\n## Core Frameworks\n\n### 1. The Five-Level Meeting Architecture\n\n**The Pattern:**\n\nDifferent meetings serve different purposes. Conflating them creates either inefficiency (too much time) or confusion (unclear decisions). Separate meetings by function, frequency, and decision authority.\n\n**Level 1: Daily Standup (15 min, teams only)**\n\n- What we finished yesterday, what we're starting today, what's blocking us\n- 5-10 people max. Whole-company standups are theater\n- Anti-pattern: Status reporting (use Slack, not meetings)\n- Anti-pattern: Strategic discussion (wrong time, wrong place)\n- Success criteria: Finishes in 15 minutes, surfaces 1-2 blockers\n\n**Level 2: Weekly Functional Reviews (60 min, function leadership)**\n\nEach function gets its own weekly rhythm:\n- Product team Friday 4pm: metrics, user feedback, roadmap blockers\n- GTM team Tuesday 4pm: pipeline, customer updates, deal health\n- Engineering Wednesday 4pm: velocity, bug backlog, deployment\n\nFormat: Metric recap (10 min) → Wins\u002Fblockers (15 min) → One deep-dive (30 min) → Next week priorities (5 min)\n\nAnti-pattern: Trying to solve every problem in the meeting. Pick 1-2, delegate the rest to follow-ups.\n\n**Level 3: Weekly All-Hands (60 min, whole company)**\n\nThe single most important alignment mechanism at a scaling company.\n\n- CEO update (15 min): north star progress, week focus, what's changed\n- Metric dashboard (10 min): same format every week (consistency enables pattern recognition)\n- Deep dive (20 min): one strategic topic needing team input — not a presentation, a discussion\n- Q&A (15 min): real questions, real answers\n\nAnti-pattern: Defensive tone. All-hands should be straightforward, not spin.\nAnti-pattern: Inconsistent metrics. If you change the dashboard, the team can't track progress.\n\n**Level 4: Bi-Weekly Leadership Alignment (90 min)**\n\n- North star progress (5 min)\n- Functional updates (30 min, 5-7 min each)\n- Major decisions needing resolution (30-40 min): resource conflicts, strategic pivots, customer\u002Fproduct decisions\n- Next 2 weeks planning (15 min)\n\nThis is where cross-functional blockers get resolved. If functions operate independently, this meeting isn't working.\n\n**Level 5: Quarterly Strategic Planning (half-day to full-day)**\n\n- Previous quarter retrospective (90 min): What worked, what didn't, what we'd do differently\n- Next quarter planning (120 min): What are we optimizing for? What's the roadmap?\n- Function breakouts (90 min): Each function plans their quarter\n- Synthesis (60 min): Functions share commitments, resolve conflicts\n\nAnti-pattern: Too much \"fun activity,\" not enough substance.\nAnti-pattern: No clear decisions coming out.\n\n**Scaling Adjustments:**\n\n- **\u003C30 people**: Levels 2-3 only. Skip daily standups (you see everything). Skip bi-weekly leadership (you ARE leadership).\n- **30-100 people**: Add all 5 levels. Monthly review catches what you no longer see daily.\n- **100-300 people**: Add skip-level reviews. You're 2+ layers from execution.\n- **300+ people**: Add function-specific sub-cadences. CEO should be in *fewer* meetings than at 50 — not more.\n\n**The Rule That Makes This Work:**\n\nEvery meeting must produce decisions or be cancelled. Status updates are async. If you're in a meeting and nobody is making a decision, leave.\n\n---\n\n### 2. Weekly Metric Reporting (The Dashboard That Catches Problems Early)\n\n**The Pattern:**\n\nMonthly 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.\n\n**The Format (Same Structure Every Week):**\n\n```\nWEEK OF [DATE]\n\nNorth Star: [Metric]\nThis Week: [Value] | Last Week: [Value] | Change: [+\u002F-] [↑↓]\nContext: [One sentence — why this trend matters]\n\nFunctional Metrics:\n  Product:  7-Day Retention: 34% | Last: 33% | +1% ↑\n            Feature Adoption: 18% | Last: 16% | +2% ↑\n            Context: Onboarding improvements showing impact\n\n  GTM:      Pipeline: $8.2M | Last: $7.8M | +$400K ↑\n            New POCs: 3 | Last: 2\n            Context: Partner pipeline adding deals\n\n  Health:   Team Morale: 7.2\u002F10 (down from 7.5)\n            Context: Org restructure causing uncertainty\n```\n\n**The Discipline Rules:**\n\n1. **Same metrics every week.** Consistency enables pattern recognition. OK to add metrics, never drop them.\n2. **One context sentence per metric.** Not just the number — why does this matter? Vs plan? Vs last period?\n3. **Trend direction for every metric.** Up\u002Fdown\u002Fflat arrow. If it moved significantly: temporary or structural?\n4. **Traffic light colors.** GREEN (on track), YELLOW (watch), RED (action needed). Every RED item must have: owner, specific action, deadline.\n\n**The Escalation Rule:**\n\nIf a metric is RED two weeks in a row with the same action plan, escalate — the action plan isn't working.\n\n**How Many Metrics:**\n\nPick 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.\n\n**Common Mistake:**\n\nVanity metrics that look good but don't predict business outcomes. Total downloads without adoption context. CEO headlines without supporting metrics.\n\n---\n\n### 3. Quarterly Planning (The Process That Prevents Strategic Drift)\n\n**The Pattern:**\n\nWithout 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.\n\n**The 3-Week Planning Cycle:**\n\n**Week 1: Retrospective + Data Gathering**\n- Previous quarter results vs plan (leadership prepares)\n- Each function writes 1-page retrospective: what worked, what didn't, what we'd do differently\n- Finance prepares: revenue actuals, spend actuals, forecast\n- Market data: competitive moves, customer feedback themes, win\u002Floss analysis\n\n**Week 2: Priority Setting (Leadership Half-Day)**\n- Review retrospectives (30 min — pre-read, don't present)\n- Agree on 3-5 company-level priorities\n- For each: owner, success metric, resource requirements\n- Identify what you're *not* doing (as important as what you are)\n- Resolve cross-functional dependencies\n- Use the north star as tiebreaker: \"Does this help us hit the goal? Prioritize. Nice-to-have? Defer.\"\n\n**Week 3: OKR Cascade + Resource Allocation**\n- Each function translates company priorities into team OKRs\n- Leadership reviews for alignment\n- Resource allocation finalized (headcount, budget, tools)\n- Final plan shared company-wide\n\n**The Quarterly Commitment Format:**\n\n```\nQ2 2026 Roadmap\nNorth Star: [What we're optimizing for]\n\nPillar 1: Product (25% team effort)\n  Initiative: [Name]\n    Problem: [What we're solving]\n    Success: [Specific metric]\n    Owner: [Name]\n    Timeline: [When]\n\nPillar 2: GTM (50% team effort)\n  Initiative: [Name]\n    ...\n\nPillar 3: People (10% effort)\n  Initiative: [Name]\n    ...\n\nPillar 4: Tech Debt (15% effort)\n  Initiative: [Name]\n    ...\n```\n\n**The \"Not Doing\" List:**\n\nFor 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.\n\n**Common Mistake:**\n\nQuarterly 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.\n\n---\n\n### 4. Decision Velocity and Authority\n\n**The Pattern:**\n\nAt 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.\n\n**The fix isn't more meetings. It's clear decision rights.**\n\n**Decision Authority Matrix:**\n\n| Decision | Who Decides | Timeline | Escalation |\n|----------|------------|----------|------------|\n| Company strategy | CEO | 1 week | Board if strategic |\n| Feature priority | Product lead | 1 week | CEO if >3 eng weeks |\n| Customer support issue | CSM | Immediately | CS lead if escalated |\n| Marketing campaign | Marketing lead | 2 weeks | CMO if >$10K budget |\n| Hiring | Function leader | 2 weeks | CEO if role not approved |\n| New partnership | CEO | 2 weeks | Board if strategic |\n| Vendor selection | Function leader | 1 week | CEO if >$50K\u002Fyear |\n\n**The Problem:**\n\nScaling companies start treating reversible, low-stakes decisions like irreversible, high-stakes ones. Everything needs approval. Everything needs a meeting. Everything needs consensus.\n\n**The Fix:**\n\n**Type 1 (Irreversible, high-stakes):** Pricing model, market entry, major partnership → CEO\u002Fleadership decides with debate in one meeting. Timeline: 1-2 weeks max.\n\n**Type 2 (Reversible, low-stakes):** Campaign creative, feature prioritization, single hire → Function owner decides, informs, iterates. Timeline: same day or next day.\n\n**Make decisions with 70% information, not 100%.** Speed is a competitive advantage at every stage.\n\n**Common Mistake:**\n\nConsensus culture masquerading as collaboration. \"Let's get everyone aligned\" often means \"nobody wants to decide.\" Name the decider. Let them decide. Move on.\n\n---\n\n### 5. Async-First Communication\n\n**The Pattern:**\n\nSynchronous meetings don't scale. Default to async, escalate to sync.\n\n**Async First (No Meeting Needed):**\n- Decision documents (even major ones — write up proposal, solicit comments, 48-72 hours for feedback, decide if consensus or no material objections)\n- Progress updates (use weekly reporting, not meetings)\n- Process changes and SOPs\n- Decisions already made (inform, don't discuss)\n\n**Sync When:**\n- Real-time brainstorming needed\n- Major disagreement to work through\n- Complex topic needing whiteboard\n- Team building \u002F relationship\n\n**Documentation Discipline:**\n\nEvery decision documented: What was decided? Why? Who decided? When does it take effect? Who needs to know?\n\nStore in searchable format (wiki, shared drive). New hires onboard faster. Past decisions don't get relitigated.\n\n**Common Mistake:**\n\n\"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.\n\n---\n\n### 6. The CEO Weekly Update\n\n**The Pattern:**\n\nThe 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.\n\n**Format (Sent Sunday Night or Monday Morning):**\n\n**1. Week Focus (1 paragraph):**\nWhat's the priority this week? What should the team be focused on?\n\n**2. North Star Progress (1-2 bullets):**\nWhere are we on the key metric? Trend up\u002Fdown\u002Fflat? Why does this matter?\n\n**3. Wins This Week (3-5 bullets):**\nWhat shipped? Customer\u002Fpartner wins? Big picture implication?\n\n**4. Blockers Getting Resolved (1-2 bullets):**\nWhat are we unblocking this week? Who needs to know?\n\n**5. Ask (1 bullet, optional):**\nWhat help does the team need? Referrals, feedback, customer introductions?\n\n**The Rule:**\n\nSame day every week. Consistency signals operational discipline. If you skip a week, the team notices — and starts wondering what you're not telling them.\n\n**Common Mistake:**\n\nToo long (team doesn't read), too detailed (save that for function meetings), only good news (team loses trust), inconsistent (team stops reading).\n\n---\n\n### 7. Role Clarity > Titles\n\n**The Pattern:**\n\nThe 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.\n\n**How to Execute:**\n\n- Every initiative gets exactly one owner (with supporting teammates)\n- Metrics are tied to that owner\n- Success is measured by moving KPIs, not completing tasks\n- Eliminate initiatives without clear ownership within 48 hours\n\n**The Test:**\n\nCan you name the single person who owns this outcome? Not \"the team\" — a person. If you can't, the initiative will drift.\n\n**Common Mistake:**\n\nAssigning 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.\n\n---\n\n## Decision Trees\n\n### Which Meeting Levels Do We Need?\n\n```\nCompany size \u003C30?\n├─ Yes → Levels 2-3 only (weekly functional + all-hands)\n└─ No → Continue...\n    │\n    30-100 people?\n    ├─ Yes → All 5 levels\n    └─ No → All 5 + skip-level reviews + function sub-cadences\n```\n\n### Is This Meeting Worth Keeping?\n\n```\nDoes it produce decisions?\n├─ No → Can it be async?\n│   ├─ Yes → Make it async, cancel the meeting\n│   └─ No → Redesign with decision agenda\n└─ Yes → Are the right people in the room?\n    ├─ No → Fix attendee list (fewer > more)\n    └─ Yes → Keep it\n```\n\n---\n\n## Common Mistakes\n\n**1. Adding meetings as you grow**\nReplace them. At 200 people, the CEO should be in fewer meetings than at 50.\n\n**2. Status update meetings**\nIf it can be an email, it should be an email. Meetings are for decisions.\n\n**3. Changing metrics every quarter**\nConsistency enables trend identification. Same dashboard, every time.\n\n**4. Consensus culture**\nName the decider. Let them decide. Inform everyone else.\n\n**5. All information in Slack**\nEphemeral, noisy, unsearchable. Important decisions go in docs.\n\n**6. Quarterly planning that produces 30-page docs**\n3-5 priorities on one page. That's the output.\n\n---\n\n## Quick Reference\n\n**Meeting architecture:**\nDaily standup (15 min) → Weekly functional (60 min) → Weekly all-hands (60 min) → Bi-weekly leadership (90 min) → Quarterly planning (half-day)\n\n**Weekly metric dashboard:**\n8-12 metrics, same format every week, traffic light colors, one context sentence per metric, owner + action + deadline for every RED\n\n**Quarterly planning cycle:**\nWeek 1: Retro + data → Week 2: Priority setting (3-5 max) → Week 3: OKR cascade + resources\n\n**Decision authority:**\nType 1 (irreversible): CEO\u002Fleadership, 1-2 weeks → Type 2 (reversible): Function owner, same day\n\n**CEO weekly update:**\nWeek focus → North star progress → Wins → Blockers → Ask\n\n**Information flow:**\nDaily: Slack wins\u002Fcustomer-voice → Weekly: CEO email + function updates → Monthly: All-hands + skip-levels → Quarterly: Planning share + demos\n\n---\n\n## Related Skills\n\n- **enterprise-account-planning**: Stakeholder management and deal cadence patterns\n- **0-to-1-launch**: Launch-specific execution cadence\n- **board-and-investor-communication**: Board meeting structure and investor updates\n\n---\n\n*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.*\n","# Operating Cadence\n\nThe 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.\n\n## When to Use\n\n**Triggers:**\n- \"Our meetings don't produce decisions\"\n- \"We're growing but alignment is getting worse\"\n- \"How often should we meet?\"\n- \"Nobody knows what's happening across functions\"\n- \"Decisions take forever\"\n- \"Leadership is in meetings all day\"\n\n**Context:**\n- Companies scaling from 20 to 300+ people\n- Post-PMF through growth stage\n- Distributed \u002F remote teams\n- Any stage where \"we need to talk about this\" has become the default\n\n---\n\n## Core Frameworks\n\n### 1. The Five-Level Meeting Architecture\n\n**The Pattern:**\n\nDifferent meetings serve different purposes. Conflating them creates either inefficiency (too much time) or confusion (unclear decisions). Separate meetings by function, frequency, and decision authority.\n\n**Level 1: Daily Standup (15 min, teams only)**\n\n- What we finished yesterday, what we're starting today, what's blocking us\n- 5-10 people max. Whole-company standups are theater\n- Anti-pattern: Status reporting (use Slack, not meetings)\n- Anti-pattern: Strategic discussion (wrong time, wrong place)\n- Success criteria: Finishes in 15 minutes, surfaces 1-2 blockers\n\n**Level 2: Weekly Functional Reviews (60 min, function leadership)**\n\nEach function gets its own weekly rhythm:\n- Product team Friday 4pm: metrics, user feedback, roadmap blockers\n- GTM team Tuesday 4pm: pipeline, customer updates, deal health\n- Engineering Wednesday 4pm: velocity, bug backlog, deployment\n\nFormat: Metric recap (10 min) → Wins\u002Fblockers (15 min) → One deep-dive (30 min) → Next week priorities (5 min)\n\nAnti-pattern: Trying to solve every problem in the meeting. Pick 1-2, delegate the rest to follow-ups.\n\n**Level 3: Weekly All-Hands (60 min, whole company)**\n\nThe single most important alignment mechanism at a scaling company.\n\n- CEO update (15 min): north star progress, week focus, what's changed\n- Metric dashboard (10 min): same format every week (consistency enables pattern recognition)\n- Deep dive (20 min): one strategic topic needing team input — not a presentation, a discussion\n- Q&A (15 min): real questions, real answers\n\nAnti-pattern: Defensive tone. All-hands should be straightforward, not spin.\nAnti-pattern: Inconsistent metrics. If you change the dashboard, the team can't track progress.\n\n**Level 4: Bi-Weekly Leadership Alignment (90 min)**\n\n- North star progress (5 min)\n- Functional updates (30 min, 5-7 min each)\n- Major decisions needing resolution (30-40 min): resource conflicts, strategic pivots, customer\u002Fproduct decisions\n- Next 2 weeks planning (15 min)\n\nThis is where cross-functional blockers get resolved. If functions operate independently, this meeting isn't working.\n\n**Level 5: Quarterly Strategic Planning (half-day to full-day)**\n\n- Previous quarter retrospective (90 min): What worked, what didn't, what we'd do differently\n- Next quarter planning (120 min): What are we optimizing for? What's the roadmap?\n- Function breakouts (90 min): Each function plans their quarter\n- Synthesis (60 min): Functions share commitments, resolve conflicts\n\nAnti-pattern: Too much \"fun activity,\" not enough substance.\nAnti-pattern: No clear decisions coming out.\n\n**Scaling Adjustments:**\n\n- **\u003C30 people**: Levels 2-3 only. Skip daily standups (you see everything). Skip bi-weekly leadership (you ARE leadership).\n- **30-100 people**: Add all 5 levels. Monthly review catches what you no longer see daily.\n- **100-300 people**: Add skip-level reviews. You're 2+ layers from execution.\n- **300+ people**: Add function-specific sub-cadences. CEO should be in *fewer* meetings than at 50 — not more.\n\n**The Rule That Makes This Work:**\n\nEvery meeting must produce decisions or be cancelled. Status updates are async. If you're in a meeting and nobody is making a decision, leave.\n\n---\n\n### 2. Weekly Metric Reporting (The Dashboard That Catches Problems Early)\n\n**The Pattern:**\n\nMonthly 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.\n\n**The Format (Same Structure Every Week):**\n\n```\nWEEK OF [DATE]\n\nNorth Star: [Metric]\nThis Week: [Value] | Last Week: [Value] | Change: [+\u002F-] [↑↓]\nContext: [One sentence — why this trend matters]\n\nFunctional Metrics:\n  Product:  7-Day Retention: 34% | Last: 33% | +1% ↑\n            Feature Adoption: 18% | Last: 16% | +2% ↑\n            Context: Onboarding improvements showing impact\n\n  GTM:      Pipeline: $8.2M | Last: $7.8M | +$400K ↑\n            New POCs: 3 | Last: 2\n            Context: Partner pipeline adding deals\n\n  Health:   Team Morale: 7.2\u002F10 (down from 7.5)\n            Context: Org restructure causing uncertainty\n```\n\n**The Discipline Rules:**\n\n1. **Same metrics every week.** Consistency enables pattern recognition. OK to add metrics, never drop them.\n2. **One context sentence per metric.** Not just the number — why does this matter? Vs plan? Vs last period?\n3. **Trend direction for every metric.** Up\u002Fdown\u002Fflat arrow. If it moved significantly: temporary or structural?\n4. **Traffic light colors.** GREEN (on track), YELLOW (watch), RED (action needed). Every RED item must have: owner, specific action, deadline.\n\n**The Escalation Rule:**\n\nIf a metric is RED two weeks in a row with the same action plan, escalate — the action plan isn't working.\n\n**How Many Metrics:**\n\nPick 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.\n\n**Common Mistake:**\n\nVanity metrics that look good but don't predict business outcomes. Total downloads without adoption context. CEO headlines without supporting metrics.\n\n---\n\n### 3. Quarterly Planning (The Process That Prevents Strategic Drift)\n\n**The Pattern:**\n\nWithout 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.\n\n**The 3-Week Planning Cycle:**\n\n**Week 1: Retrospective + Data Gathering**\n- Previous quarter results vs plan (leadership prepares)\n- Each function writes 1-page retrospective: what worked, what didn't, what we'd do differently\n- Finance prepares: revenue actuals, spend actuals, forecast\n- Market data: competitive moves, customer feedback themes, win\u002Floss analysis\n\n**Week 2: Priority Setting (Leadership Half-Day)**\n- Review retrospectives (30 min — pre-read, don't present)\n- Agree on 3-5 company-level priorities\n- For each: owner, success metric, resource requirements\n- Identify what you're *not* doing (as important as what you are)\n- Resolve cross-functional dependencies\n- Use the north star as tiebreaker: \"Does this help us hit the goal? Prioritize. Nice-to-have? Defer.\"\n\n**Week 3: OKR Cascade + Resource Allocation**\n- Each function translates company priorities into team OKRs\n- Leadership reviews for alignment\n- Resource allocation finalized (headcount, budget, tools)\n- Final plan shared company-wide\n\n**The Quarterly Commitment Format:**\n\n```\nQ2 2026 Roadmap\nNorth Star: [What we're optimizing for]\n\nPillar 1: Product (25% team effort)\n  Initiative: [Name]\n    Problem: [What we're solving]\n    Success: [Specific metric]\n    Owner: [Name]\n    Timeline: [When]\n\nPillar 2: GTM (50% team effort)\n  Initiative: [Name]\n    ...\n\nPillar 3: People (10% effort)\n  Initiative: [Name]\n    ...\n\nPillar 4: Tech Debt (15% effort)\n  Initiative: [Name]\n    ...\n```\n\n**The \"Not Doing\" List:**\n\nFor 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.\n\n**Common Mistake:**\n\nQuarterly 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.\n\n---\n\n### 4. Decision Velocity and Authority\n\n**The Pattern:**\n\nAt 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.\n\n**The fix isn't more meetings. It's clear decision rights.**\n\n**Decision Authority Matrix:**\n\n| Decision | Who Decides | Timeline | Escalation |\n|----------|------------|----------|------------|\n| Company strategy | CEO | 1 week | Board if strategic |\n| Feature priority | Product lead | 1 week | CEO if >3 eng weeks |\n| Customer support issue | CSM | Immediately | CS lead if escalated |\n| Marketing campaign | Marketing lead | 2 weeks | CMO if >$10K budget |\n| Hiring | Function leader | 2 weeks | CEO if role not approved |\n| New partnership | CEO | 2 weeks | Board if strategic |\n| Vendor selection | Function leader | 1 week | CEO if >$50K\u002Fyear |\n\n**The Problem:**\n\nScaling companies start treating reversible, low-stakes decisions like irreversible, high-stakes ones. Everything needs approval. Everything needs a meeting. Everything needs consensus.\n\n**The Fix:**\n\n**Type 1 (Irreversible, high-stakes):** Pricing model, market entry, major partnership → CEO\u002Fleadership decides with debate in one meeting. Timeline: 1-2 weeks max.\n\n**Type 2 (Reversible, low-stakes):** Campaign creative, feature prioritization, single hire → Function owner decides, informs, iterates. Timeline: same day or next day.\n\n**Make decisions with 70% information, not 100%.** Speed is a competitive advantage at every stage.\n\n**Common Mistake:**\n\nConsensus culture masquerading as collaboration. \"Let's get everyone aligned\" often means \"nobody wants to decide.\" Name the decider. Let them decide. Move on.\n\n---\n\n### 5. Async-First Communication\n\n**The Pattern:**\n\nSynchronous meetings don't scale. Default to async, escalate to sync.\n\n**Async First (No Meeting Needed):**\n- Decision documents (even major ones — write up proposal, solicit comments, 48-72 hours for feedback, decide if consensus or no material objections)\n- Progress updates (use weekly reporting, not meetings)\n- Process changes and SOPs\n- Decisions already made (inform, don't discuss)\n\n**Sync When:**\n- Real-time brainstorming needed\n- Major disagreement to work through\n- Complex topic needing whiteboard\n- Team building \u002F relationship\n\n**Documentation Discipline:**\n\nEvery decision documented: What was decided? Why? Who decided? When does it take effect? Who needs to know?\n\nStore in searchable format (wiki, shared drive). New hires onboard faster. Past decisions don't get relitigated.\n\n**Common Mistake:**\n\n\"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.\n\n---\n\n### 6. The CEO Weekly Update\n\n**The Pattern:**\n\nThe 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.\n\n**Format (Sent Sunday Night or Monday Morning):**\n\n**1. Week Focus (1 paragraph):**\nWhat's the priority this week? What should the team be focused on?\n\n**2. North Star Progress (1-2 bullets):**\nWhere are we on the key metric? Trend up\u002Fdown\u002Fflat? Why does this matter?\n\n**3. Wins This Week (3-5 bullets):**\nWhat shipped? Customer\u002Fpartner wins? Big picture implication?\n\n**4. Blockers Getting Resolved (1-2 bullets):**\nWhat are we unblocking this week? Who needs to know?\n\n**5. Ask (1 bullet, optional):**\nWhat help does the team need? Referrals, feedback, customer introductions?\n\n**The Rule:**\n\nSame day every week. Consistency signals operational discipline. If you skip a week, the team notices — and starts wondering what you're not telling them.\n\n**Common Mistake:**\n\nToo long (team doesn't read), too detailed (save that for function meetings), only good news (team loses trust), inconsistent (team stops reading).\n\n---\n\n### 7. Role Clarity > Titles\n\n**The Pattern:**\n\nThe 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.\n\n**How to Execute:**\n\n- Every initiative gets exactly one owner (with supporting teammates)\n- Metrics are tied to that owner\n- Success is measured by moving KPIs, not completing tasks\n- Eliminate initiatives without clear ownership within 48 hours\n\n**The Test:**\n\nCan you name the single person who owns this outcome? Not \"the team\" — a person. If you can't, the initiative will drift.\n\n**Common Mistake:**\n\nAssigning 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.\n\n---\n\n## Decision Trees\n\n### Which Meeting Levels Do We Need?\n\n```\nCompany size \u003C30?\n├─ Yes → Levels 2-3 only (weekly functional + all-hands)\n└─ No → Continue...\n    │\n    30-100 people?\n    ├─ Yes → All 5 levels\n    └─ No → All 5 + skip-level reviews + function sub-cadences\n```\n\n### Is This Meeting Worth Keeping?\n\n```\nDoes it produce decisions?\n├─ No → Can it be async?\n│   ├─ Yes → Make it async, cancel the meeting\n│   └─ No → Redesign with decision agenda\n└─ Yes → Are the right people in the room?\n    ├─ No → Fix attendee list (fewer > more)\n    └─ Yes → Keep it\n```\n\n---\n\n## Common Mistakes\n\n**1. Adding meetings as you grow**\nReplace them. At 200 people, the CEO should be in fewer meetings than at 50.\n\n**2. Status update meetings**\nIf it can be an email, it should be an email. Meetings are for decisions.\n\n**3. Changing metrics every quarter**\nConsistency enables trend identification. Same dashboard, every time.\n\n**4. Consensus culture**\nName the decider. Let them decide. Inform everyone else.\n\n**5. All information in Slack**\nEphemeral, noisy, unsearchable. Important decisions go in docs.\n\n**6. Quarterly planning that produces 30-page docs**\n3-5 priorities on one page. That's the output.\n\n---\n\n## Quick Reference\n\n**Meeting architecture:**\nDaily standup (15 min) → Weekly functional (60 min) → Weekly all-hands (60 min) → Bi-weekly leadership (90 min) → Quarterly planning (half-day)\n\n**Weekly metric dashboard:**\n8-12 metrics, same format every week, traffic light colors, one context sentence per metric, owner + action + deadline for every RED\n\n**Quarterly planning cycle:**\nWeek 1: Retro + data → Week 2: Priority setting (3-5 max) → Week 3: OKR cascade + resources\n\n**Decision authority:**\nType 1 (irreversible): CEO\u002Fleadership, 1-2 weeks → Type 2 (reversible): Function owner, same day\n\n**CEO weekly update:**\nWeek focus → North star progress → Wins → Blockers → Ask\n\n**Information flow:**\nDaily: Slack wins\u002Fcustomer-voice → Weekly: CEO email + function updates → Monthly: All-hands + skip-levels → Quarterly: Planning share + demos\n\n---\n\n## Related Skills\n\n- **enterprise-account-planning**: Stakeholder management and deal cadence patterns\n- **0-to-1-launch**: Launch-specific execution cadence\n- **board-and-investor-communication**: Board meeting structure and investor updates\n\n---\n\n*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.*\n",{"name":5,"license":15,"metadata":45,"description":7},{"author":46,"source":47},"Smit Patel (https:\u002F\u002Flinkedin.com\u002Fin\u002Fsmitkpatel)","https:\u002F\u002Fgithub.com\u002Fbeingsmit\u002Ftechnical-product-gtm","main","5269f7ea2d6c3a9bfda5ed878b6726cf509121fd","skills\u002Fgtm-operating-cadence",5344,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot","https:\u002F\u002Fawesome-copilot.github.com\u002F","https:\u002F\u002Fgithub.com\u002Fgithub","https:\u002F\u002Fgithub.com\u002Fabout","How people build software.","2026-11-13 02:05:36",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add github\u002Fawesome-copilot --skill gtm-operating-cadence",{"tool":64,"command":65},"bunx","bunx skills add github\u002Fawesome-copilot --skill gtm-operating-cadence",{"tool":67,"command":68},"pnpm","pnpm dlx skills add github\u002Fawesome-copilot --skill gtm-operating-cadence","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fgtm-operating-cadence\u002FSKILL.md",true,[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"agents\u002Fopenai.yaml","REFERENCE","参考文档",247,"https:\u002F\u002Fgithub.com\u002Fnodetool-ai\u002Fnodetool\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fto-tickets\u002Fagents\u002Fopenai.yaml",[79,113,141,171,205,221],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":93,"publishedAt":40},"01M70KXZNX9ES38N2A8M58ZZMZ","supabase-rls-policies","Write, review, and test Supabase Row Level Security (RLS) policies so that one user cannot read or change another user's rows. Use when creating or changing tables, policies, views, or security definer functions in a Supabase project, when reviewing a migration that touches RLS, or when asked to prove user isolation with pgTAP tests that sign in as two users.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fsupabase-rls-policies\u002FSKILL.md",[85,90],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":91,"categoryName":92,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000023","Skill与智能体开发",[94,95,96,97,98,25,99,100,101,102,103,104,105,106,107,108,109,110,111,112],"supabase","rls","supabase rls","supabase rls policies","project","review","change","read","write","security","isolation","tables","as","tests","prove","use","users","functions","with",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":120,"publishedAt":40},"01M70KWA5YWXDV6V8DZ19E3T2Y","skill-distribution-audit","Audit a skill collection before release or investigate installer omissions, archived\u002Ftemplate leakage, duplicate identities, and manifest drift. Reconcile the intended public source set, distribution manifest, and actual discovery output for a specified consumer version. Includes a deterministic set-comparison helper.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fskill-distribution-audit\u002FSKILL.md",[119],{"categoryNo":91,"categoryName":92,"taxonomyType":88,"taxonomyTypeDesc":89},[121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140],"distribution","skill distribution audit","audit","SET","deterministic","installer","for","discovery","comparison","helper","manifest","version","collection","drift","output","investigate","duplicate","template","release","reconcile",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":145,"sourceHtmlUrl":146,"categories":147,"keywords":153,"publishedAt":40},"01M70KCJPFVW7PPQ49CC5R8JGK","logicapps-custom-code-net10-migration","Migrate Azure Logic Apps Standard local-function custom-code projects from .NET 8 to .NET 10. Use for legacy Logic Apps custom-code workspace upgrades, project\u002Fpackage configuration, custom-worker settings, publication, and integrated VS Code debugging. Not for ordinary .NET applications, standalone Azure Functions, Consumption workflows, or cloud deployment.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flogicapps-custom-code-net10-migration\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flogicapps-custom-code-net10-migration\u002FSKILL.md",[148],{"categoryNo":149,"categoryName":150,"taxonomyType":151,"taxonomyTypeDesc":152},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[154,155,156,157,158,159,127,98,160,161,162,163,164,165,166,109,167,168,169,170],"custom","code","logicapps custom code net10 migration","migration","projects","standalone","deployment","applications","local","azure","worker","upgrades","package","apps","Legacy","debugging","workflows",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":175,"sourceHtmlUrl":176,"categories":177,"keywords":182,"publishedAt":40},"01M6AEBN37RQMXJ3298PEY7PG1","winmd-api-search","Find and explore Windows desktop APIs. Use when building features that need platform capabilities — camera, file access, notifications, UI controls, AI\u002FML, sensors, networking, etc. Discovers the right API for a task and retrieves full type details (methods, properties, events, enumeration values).","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fwinmd-api-search\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fwinmd-api-search\u002FSKILL.md",[178,181],{"categoryNo":179,"categoryName":180,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":149,"categoryName":150,"taxonomyType":151,"taxonomyTypeDesc":152},[183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,25,198,199,200,201,202,127,203,204],"winmd api search","search","api","windows","desktop","file access","enumeration","ui","ml","file","networking","capabilities","notifications","explore","access","features","full","camera","events","platform","methods","controls",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":209,"licenseFileUrl":210,"sourceHtmlUrl":211,"categories":212,"keywords":218,"publishedAt":40},"01M6AE571R3SC1ZGE202B3NB5S","resemble-detect","Deepfake detection and media safety — detect AI-generated audio, images, video, and text, trace synthesis sources, apply watermarks, verify speaker identity, and analyze media intelligence using Resemble AI","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fresemble-detect\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fresemble-detect\u002FSKILL.md",[213,214,217],{"categoryNo":179,"categoryName":180,"taxonomyType":88,"taxonomyTypeDesc":89},{"categoryNo":215,"categoryName":216,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":91,"categoryName":92,"taxonomyType":88,"taxonomyTypeDesc":89},[219,124,192,37,220],"resemble detect","identity",{"skillNo":222,"name":223,"nameZh":6,"description":224,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":209,"licenseFileUrl":225,"sourceHtmlUrl":226,"categories":227,"keywords":232,"publishedAt":40},"01M6AE30BSK2HCY4TQQ22Z8JRD","quality-playbook","Run a complete quality engineering audit on any codebase. Derives behavioral requirements from the code, generates spec-traced functional tests, runs a three-pass code review with regression tests, executes a multi-model spec audit (Council of Three), and produces a consolidated bug report with TDD-verified patches. Finds the 35% of real defects that structural code review alone cannot catch. Works with any language. Trigger on 'quality playbook', 'spec audit', 'Council of Three', 'fitness-to-purpose', or 'coverage theater'.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquality-playbook\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquality-playbook\u002FSKILL.md",[228,231],{"categoryNo":229,"categoryName":230,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":91,"categoryName":92,"taxonomyType":88,"taxonomyTypeDesc":89},[233,234,235,236,155,99,9,123,237,238,37,239,240,241,242,243,244,245,246,247,248,249,107,250,251,252,253],"playbook","quality playbook","quality","code review","tdd","run","report","spec","bug report","council","engineering","functional","spec audit","bug","verified","multi-model","three","coverage","model","regression","structural"]