Coo Advisor

COO Advisor

Operational frameworks and tools for turning strategy into execution, scaling processes, and building the organizational engine.

Keywords

COO, chief operating officer, operations, operational excellence, process improvement, OKRs, objectives and key results, scaling, operational efficiency, execution, bottleneck analysis, process design, operational cadence, meeting cadence, org scaling, lean operations, continuous improvement

Quick Start

python scripts/ops_efficiency_analyzer.py   # Map processes, find bottlenecks, score maturity
python scripts/okr_tracker.py               # Cascade OKRs, track progress, flag at-risk items

Core Responsibilities

1. Strategy Execution

The CEO sets direction. The COO makes it happen. Cascade company vision → annual strategy → quarterly OKRs → weekly execution. See references/ops_cadence.md for full OKR cascade framework.

2. Process Design

Map current state → find the bottleneck → design improvement → implement incrementally → standardize. See references/process_frameworks.md for Theory of Constraints, lean ops, and automation decision framework.

Process Maturity Scale:

3. Operational Cadence

Daily standups (15 min, blockers only) → Weekly leadership sync → Monthly business review → Quarterly OKR planning. See references/ops_cadence.md for full templates.

4. Scaling Operations

What breaks at each stage: Seed (tribal knowledge) → Series A (documentation) → Series B (coordination) → Series C (decision speed) → Growth (culture). See references/scaling_playbook.md for detailed playbook per stage.

5. Cross-Functional Coordination

RACI for key decisions. Escalation framework: Team lead → Dept head → COO → CEO based on impact scope.

Key Questions a COO Asks

• "What's the bottleneck? Not what's annoying — what limits throughput."
• "How many manual steps? Which break at 3x volume?"
• "Who's the single point of failure?"
• "Can every team articulate how their work connects to company goals?"
• "The same blocker appeared 3 weeks in a row. Why isn't it fixed?"

Operational Metrics

Red Flags

• OKRs consistently 1.0 (not ambitious) or < 0.3 (disconnected from reality)
• Teams can't explain how their work maps to company goals
• Leadership meetings produce no action items two weeks running
• Same blocker in three consecutive syncs
• Process exists but nobody follows it
• Departments optimize local metrics at expense of company metrics

Integration with Other C-Suite Roles

Detailed References

• references/scaling_playbook.md — what changes at each growth stage
• references/ops_cadence.md — meeting rhythms, OKR cascades, reporting
• references/process_frameworks.md — lean ops, TOC, automation decisions

Proactive Triggers

Surface these without being asked when you detect them in company context:

• Same blocker appearing 3+ weeks → process is broken, not just slow
• OKR check-in overdue → prompt quarterly review
• Team growing past a scaling threshold (10→30, 30→80) → flag what will break
• Decision cycle time increasing → authority structure needs adjustment
• Meeting cadence not established → propose rhythm before chaos sets in

Output Artifacts

Reasoning Technique: Step by Step

Map processes sequentially. Identify each step, handoff, and decision point. Find the bottleneck using throughput analysis. Propose improvements one step at a time.

Communication

All output passes the Internal Quality Loop before reaching the founder (see ../agent-protocol/SKILL.md).

• Self-verify: source attribution, assumption audit, confidence scoring
• Peer-verify: cross-functional claims validated by the owning role
• Critic pre-screen: high-stakes decisions reviewed by Executive Mentor
• Output format: Bottom Line → What (with confidence) → Why → How to Act → Your Decision
• Results only. Every finding tagged: 🟢 verified, 🟡 medium, 🔴 assumed.

Context Integration

• Always read company-context.md before responding (if it exists)
• During board meetings: Use only your own analysis in Phase 2 (no cross-pollination)
• Invocation: You can request input from other roles: [INVOKE:role|question]

Operational Cadence: Meetings, Async, Decisions, and Reporting

The rhythm of your company determines its output. Bad cadence = constant context-switching, decisions made without information, and a leadership team that's always reactive.

---

Philosophy

Meetings are a tax. Every hour in a meeting is an hour not spent building, selling, or serving customers. A good cadence minimizes meeting time while ensuring the right people have the right information at the right time.

Async is default, sync is exception. Most information sharing and routine updates should happen in writing. Reserve synchronous time for things that genuinely require real-time discussion: decisions with significant disagreement, complex problem-solving, relationship-building.

Cadence serves strategy. The calendar reflects priorities. If you're doing monthly all-hands but weekly status updates, you've inverted the importance.

---

Meeting Cadence Templates

Daily Operations

Daily Standup (Engineering / Product Teams)

Format: Async-first (Slack/Loom); sync only if blocked Sync duration: 15 minutes max Participants: Team (5–10 people) Facilitator: Team lead or rotating

ASYNC FORMAT (post in #standup channel):
Yesterday: [What I completed]
Today: [What I'm working on]
Blocked: [Anything blocking me — tag the person who can unblock]

Rules:

• No status reporting in sync standup if everyone can read the async update
• Standups are not problem-solving sessions — take issues offline
• Skip standup if the team has a full-team session that day
• Kill standup if the team consistently has nothing blocked; replace with async

Daily Leadership Check-in (COO)

Format: Async only — read, don't meet Time: 8:00–8:30 AM

COO morning read: 1. Yesterday's key metrics dashboard (5 min) 2. Overnight Slack/email escalations (5 min) 3. Today's decisions needed list (5 min) 4. Any P0/P1 incidents (check status page + on-call logs)

---

Weekly Cadence

Leadership Sync (Weekly)

Duration: 60–90 minutes Participants: C-suite + VP level Owner: COO (or CEO) Day/Time: Monday or Tuesday, morning

AGENDA TEMPLATE:
00:00–10:00  Metrics pulse (pre-read required — no presenting charts)
  - Revenue: ACV, pipeline, churn delta
  - Product: shipped last week, blockers this week
  - Engineering: incidents, velocity
  - CS: escalations, NPS delta
  - People: open reqs, attrition flag

10:00–45:00  Priority items (submitted in advance, max 3)
  - Item 1: [Owner: Name] [Decision needed / FYI / Input needed]
  - Item 2: [Owner: Name]
  - Item 3: [Owner: Name]

45:00–60:00  Parking lot / open
  - Anything not covered
  - Next week flagging

Pre-meeting requirements:

• Metrics dashboard updated by EOD Friday
• Priority items submitted by Sunday 6 PM
• Anyone who hasn't read the pre-read gets no floor time

Output: Decision log updated with outcomes, action items assigned in tracking system

1:1 (Manager ↔ Direct Report)

Duration: 30–45 minutes Frequency: Weekly (skip-levels: bi-weekly) Owner: Report (the direct report sets agenda)

1:1 STRUCTURE:
[5 min]  What's on your mind / temperature check
[15 min] Their agenda — what they want to discuss
[10 min] Manager agenda — feedback, context, decisions
[5 min]  Action items review from last week

1:1 anti-patterns to eliminate:

• Using 1:1 for status updates (that's what standups are for)
• Manager dominating the agenda
• Skipping because "things are fine"
• No written record of what was discussed

Private 1:1 doc: Every manager/report pair maintains a shared doc with running notes, action items, and career development thread.

Cross-Functional Weekly Sync

Duration: 45 minutes Participants: 2–4 team leads with shared dependencies Examples: Product + Engineering, Sales + CS, Marketing + Sales

AGENDA:
00–10  Shared metrics (things both teams care about)
10–30  Active collaboration items — what needs coordination this week
30–40  Blockers + dependencies (what do I need from your team?)
40–45  Upcoming: what's coming that the other team should know about

---

Monthly Cadence

All-Hands / Town Hall

Duration: 60–90 minutes Participants: Entire company Owner: CEO + functional heads Format: In-person preferred; video if distributed

ALL-HANDS AGENDA (60 min version):
00–05   Opening — CEO sets the tone
05–20   Business update
        - Where we are vs. plan (actuals vs. budget)
        - Key wins and learning moments from last month
        - What we're focused on this month
20–40   Functional spotlights (2 functions, 10 min each)
        - What we shipped / what we did
        - What we learned
        - What's next
40–55   Open Q&A (no screened questions — take everything)
55–60   Closing

ALL-HANDS PREP CHECKLIST:
□ CEO talking points reviewed 48h in advance
□ Metrics slides reviewed by Finance for accuracy
□ Q&A prep — leadership team briefs on likely questions
□ Recording setup confirmed
□ Async option for timezones (recording posted within 2h)
□ Action items from Q&A captured and published within 24h

Monthly Business Review (MBR)

Duration: 2 hours Participants: Leadership team Owner: COO

MBR AGENDA:
00–20   Financial review (Finance presents)
        - Revenue vs. plan, by segment
        - Burn rate, runway
        - Headcount actual vs. plan
        - Key cost drivers

20–60   Functional reviews (each VP, 8 min each)
        Standard template per function:
        - Metrics: [3 key metrics vs. prior month vs. plan]
        - Wins: [top 2-3 wins]
        - Gaps: [where we missed and why]
        - Next 30 days: [top 3 priorities]

60–90   Strategic topics (pre-submitted)
        - Items requiring cross-functional decision
        - Risks or issues needing leadership visibility

90–110  Decisions and action items
        - Document decisions made
        - Assign owners and deadlines

110–120 Retrospective
        - What's working in how we operate?
        - What needs to change?

MBR pre-read package (published 48h before):

• Financial summary (1 page)
• Each function's 1-pager (see template below)

FUNCTIONAL 1-PAGER TEMPLATE:
Function: [Name]          Month: [Month Year]
Owner: [VP Name]

TOP METRICS:
| Metric | Target | Actual | vs. LM | vs. Plan |
|--------|--------|--------|--------|----------|
| [M1]   |        |        |        |          |
| [M2]   |        |        |        |          |
| [M3]   |        |        |        |          |

WINS (2-3 bullets):
•
•

GAPS (be honest — no spin):
•
•

DEPENDENCIES (what I need from other teams):
•

NEXT 30 DAYS (top 3 priorities):
1.
2.
3.

---

Quarterly Cadence

Quarterly Business Review (QBR)

Duration: Half day (4 hours) Participants: Leadership team + key functional leads Owner: CEO + COO

QBR AGENDA (4 hours):
PART 1: Look back (90 min)
  - CEO: Business context and narrative (15 min)
  - Finance: Full quarter P&L review (20 min)
  - Each function: 10-min review against OKRs
    Format: Hit/Miss/Partial for each objective + root cause

PART 2: Look forward (90 min)
  - Product/Engineering: What ships next quarter (20 min)
  - Sales/Marketing: Pipeline and demand plan (20 min)
  - People: Headcount plan and key hires (15 min)
  - Finance: Budget and forecast (20 min)
  - Cross-functional dependencies (15 min)

PART 3: Strategic discussion (60 min)
  - 1–2 strategic topics requiring deep discussion
  - Pre-submitted and pre-read

PART 4: OKR setting for next quarter (30 min)
  - Draft OKRs reviewed and challenged
  - Final OKRs locked or assigned for next week finalization

Quarterly Leadership Off-site

Duration: 1–2 days (Series B+) Participants: C-suite + VPs Purpose: Strategy alignment, relationship building, hard conversations

Off-site agenda principles:

• No laptops during sessions (phones away)
• At least 50% discussion, max 50% presentation
• Include one session on how the leadership team is functioning (not just what the business is doing)
• Output: 1-page summary of decisions and commitments shared with the company

---

Annual Cadence

Annual Planning Cycle

Timeline: Start 8–10 weeks before fiscal year end

ANNUAL PLANNING TIMELINE:
Week -10: Company strategic priorities draft (CEO + COO)
Week -8:  Revenue model + market analysis (Finance + Sales)
Week -7:  Functional goal-setting begins
Week -6:  Headcount planning by function
Week -5:  Draft plans reviewed by COO
Week -4:  Cross-functional dependency alignment
Week -3:  Budget finalization
Week -2:  Board review (if applicable)
Week -1:  Final company OKRs published
Week 0:   Year kick-off all-hands

Year Kick-off All-Hands

Duration: 2–4 hours Participants: Entire company Purpose: Align entire company on year strategy and goals

KICK-OFF AGENDA:
- Last year retrospective: What we accomplished, what we learned
- Market context: Why now, why us
- Year strategy: The 2-3 things that matter most
- OKRs: Company-level goals, each function's goals
- Culture: How we'll work together
- Q&A: Open and honest

---

Async Communication Frameworks

The Writing-First Culture

All communication defaults to written unless real-time is genuinely necessary. This is how you scale decision-making without scaling meetings.

Written first means:

• Decisions are documented before they're communicated
• Updates are published before questions are asked
• Problems are described before solutions are proposed

Slack Channel Architecture

REQUIRED CHANNELS:
#announcements       Read-only. Major company announcements only.
#general             Company-wide conversation
#leadership-public   Leadership decisions visible to all (transparency)
#incidents           P0/P1 incidents only. Auto-resolved when incident is closed.
#metrics             Automated metric updates. No discussion here.
#wins                Customer wins, team wins. Culture channel.

FUNCTIONAL CHANNELS:
#engineering, #product, #sales, #marketing, #cs, #people, #finance

PROJECT CHANNELS:
#proj-[name]         Temporary. Archive when project ships.

DECISION CHANNELS:
#decisions           All cross-team decisions logged here with context

Anti-patterns to eliminate:

• DMs for work decisions (decisions belong in channels, visible to team)
• @channel abuse (train people — this means everyone stops what they're doing)
• Thread avoidance (all replies go in threads, period)
• Multiple channels for same function (merge aggressively)

Async Decision Template

When a decision needs input but doesn't require a meeting:

DECISION REQUEST (post in #decisions):

**Context:** [1-3 sentences on why this decision is needed]

**Options considered:**
A) [Option A] — Pros: X. Cons: Y.
B) [Option B] — Pros: X. Cons: Y.

**Recommendation:** [Your recommendation and why]

**Input needed from:** @person1, @person2 (tag specific people)

**Decide by:** [Date/Time — give at least 24 hours]

**If no response:** [Default action if no input received]

Loom / Video for Async Communication

Use async video for:

• Explaining complex technical architecture
• Walking through a design or document with context
• Giving feedback that needs tone/nuance
• Team updates that would otherwise be a meeting

Loom best practices:

• Keep under 5 minutes; break up anything longer
• Always include a summary comment with key points
• Ask viewers to leave timestamp comments for specific questions

---

Decision-Making Frameworks

RAPID

The most practical decision-making framework for startups scaling to enterprises.

How to use RAPID: 1. For every significant decision, explicitly assign R, A, P, I, D before work begins 2. The D role is always one person — never a committee 3. Agree (A) roles should be limited to 2–3 people maximum; more = paralysis 4. Post the RAPID in the decision doc so everyone knows the structure

Example application:

Decision: Migrate from PostgreSQL to distributed database
R: VP Engineering
A: CTO, COO (for cost implications)
P: Infrastructure team
I: Product leads, Finance
D: CTO

RACI

Better for ongoing processes than one-time decisions. Use RACI for recurring operational responsibilities.

RACI matrix template:

PROCESS: Customer Escalation Handling

Task                    | CS Lead | VP CS | Eng Lead | CEO
------------------------|---------|-------|----------|----
Receive escalation      | R       | I     | I        | -
Diagnose issue          | R       | C     | C        | -
Communicate to customer | R       | A     | -        | I (major)
Resolve technical issue | C       | -     | R        | -
Close escalation        | R       | A     | I        | -
Post-mortem (P0/P1)    | C       | A     | R        | I

Common RACI mistakes:

• Multiple A roles (breaks accountability)
• R and A always same person (defeats the purpose)
• Too many C roles (everyone's consulted, nothing moves)
• Not distinguishing C from I (different obligations)

DRI (Directly Responsible Individual)

Apple's framework; used widely in fast-moving tech companies. Simpler than RAPID/RACI for internal use.

The rule: Every project, deliverable, and decision has exactly one DRI. The DRI is the person who gets credit when it succeeds and gets called on when it fails. No DRI = no accountability.

DRI requirements:

• Listed by name in every project brief
• Has authority to make decisions within scope
• Is responsible for communicating status
• Cannot blame lack of resources — their job is to escalate when blocked

DRI vs. RACI: Use DRI for project ownership and RACI for process ownership. They complement each other.

Decision Log

Every significant decision gets logged. Significant = affects more than one team, costs more than $10K, or is difficult to reverse.

DECISION LOG FORMAT:

Date: [YYYY-MM-DD]
Decision: [One sentence summary]
Context: [Why was this decision needed? What was the situation?]
Options considered: [What alternatives were evaluated?]
Decision made: [What was decided?]
Rationale: [Why this option?]
Owner: [Who made the final call?]
Reversible: [Yes / No / Partially]
Review date: [When should this decision be revisited?]
Outcome: [Filled in later — what actually happened?]

---

Reporting Templates

Weekly CEO/COO Dashboard

COMPANY HEALTH — WEEK OF [DATE]

REVENUE
  ARR:                  $[X]M   (vs. plan: +/-X%, vs. LW: +/-X%)
  New ARR this week:    $[X]K
  Churned ARR:          $[X]K
  Pipeline (90-day):    $[X]M

PRODUCT
  Shipped this week:    [Brief list]
  P0/P1 incidents:      [Count] — [1-line summary if any]
  Deploy frequency:     [X per week]

CUSTOMER
  Active customers:     [X]
  NPS (rolling 30d):    [X]
  Open escalations:     [X]   (P0: [X], P1: [X])

PEOPLE
  Headcount:            [X] (vs. plan: [X])
  Open reqs:            [X]
  Attrition (30d):      [X]

CASH
  Cash on hand:         $[X]M
  Burn (last 30d):      $[X]M
  Runway:               [X] months

🔴 ISSUES (needs leadership attention):
  •
  •

🟡 WATCH (monitor, no action yet):
  •

🟢 WINS:
  •

Monthly Investor/Board Update

[COMPANY NAME] — MONTHLY UPDATE — [MONTH YEAR]

THE HEADLINE
[2-3 sentences: what was the defining story of this month?]

KEY METRICS
| Metric | [Month] | vs. Prior | vs. Plan |
|--------|---------|-----------|----------|
| ARR | | | |
| MRR Added | | | |
| Churn | | | |
| NRR | | | |
| Burn | | | |
| Runway | | | |

WINS
1. [Specific, concrete win with numbers]
2. [Second win]
3. [Third win]

CHALLENGES
1. [Honest description of challenge + what you're doing about it]
2. [Second challenge]

KEY DECISIONS MADE
• [Decision + brief rationale]

ASKS FROM INVESTORS
• [Specific ask with context — intros, advice, etc.]

NEXT MONTH PRIORITIES
1.
2.
3.

Quarterly OKR Progress Report

Q[X] OKR PROGRESS — [COMPANY NAME]

SCORING GUIDE:
🟢 On track (>70% confidence of hitting target)
🟡 At risk (50-70% confidence)
🔴 Off track (<50% confidence)

COMPANY OBJECTIVES:

O1: [Objective title]
  KR1.1: [Key Result] ............... [X]% 🟢
  KR1.2: [Key Result] ............... [X]% 🟡
  Objective confidence: 🟢 | Notes: [1 line]

O2: [Objective title]
  KR2.1: [Key Result] ............... [X]% 🔴
  KR2.2: [Key Result] ............... [X]% 🟢
  Objective confidence: 🟡 | Notes: [1 line]

FUNCTIONAL OBJECTIVES:
[Same format per function]

OVERALL QUARTER HEALTH: 🟡
Summary: [2-3 sentences on overall trajectory]

TOP 3 ACTIONS TO GET BACK ON TRACK:
1. [Action + owner + deadline]
2.
3.

---

Cadence Anti-Patterns to Eliminate

---

Cadence framework synthesized from Amazon's PR/FAQ culture, Google's OKR playbook, GitLab's remote work handbook, and operational patterns from 50+ Series A–C companies.

Process Frameworks for Startup Operations

Theory of Constraints, Lean, process mapping, automation, and change management — applied to real startup contexts, not factory floors.

---

Part 1: Theory of Constraints (TOC) Applied to Startups

What TOC Actually Says

Eliyahu Goldratt's core insight: every system has exactly one constraint that limits throughput. Improving anything other than the constraint is waste. The goal isn't to optimize every function — it's to identify the single bottleneck and exploit it until a new constraint emerges.

The Five Focusing Steps: 1. Identify the constraint — what limits the system's output? 2. Exploit it — get maximum output from the constraint without adding resources 3. Subordinate everything else — other activities serve the constraint's needs 4. Elevate it — add resources to increase constraint capacity 5. Repeat — when the constraint moves, find the new one

Finding the Constraint in Your Startup

The constraint is almost never where people think it is. Sales thinks it's Marketing. Engineering thinks it's Product. Everyone thinks it's someone else.

Method: Map your value stream (see Part 3), measure throughput at each step, find the step with the lowest throughput or the highest queue in front of it.

Common startup constraints by stage:

Applying TOC to Product Development

The five visible constraints in product development:

1. Requirements clarity Symptom: Engineering asks for clarification mid-sprint. Tickets re-opened. Scope creep. Fix: Never pull a story into sprint until acceptance criteria are written and reviewed. Product manager must be available same-day for clarification.

2. Review and approval bottleneck Symptom: PRs sit unreviewed for >24 hours. Deploys waiting for sign-off. Fix: Code review SLA: 2-hour response for small PRs (<100 lines), 4-hour for medium. Design reviews: 24-hour turnaround. Anyone waiting >SLA can escalate to manager.

3. QA throughput Symptom: "Done" pile grows faster than QA can test. Release day crunch. Fix: QA is pulled into sprint planning and sprint review. Testing starts as features finish, not all at end. Automated test coverage as a sprint exit criterion.

4. Deployment pipeline speed Symptom: Deploy takes 45+ minutes. Engineers wait. Hotfix urgency causes dangerous shortcuts. Fix: Measure deploy time weekly. Set target (10 min for most apps). Build optimization into engineering roadmap as a real ticket.

5. Feedback loop latency Symptom: You ship features and don't know if they worked for weeks. Fix: Every shipped feature has instrumented metrics reviewed within 5 business days. If no metrics exist, feature doesn't ship.

Applying TOC to Sales

The sales pipeline as a system of constraints:

Lead generation → Qualification → Demo → Proposal → Negotiation → Close
     [X]      →      [X]      →  [X]  →    [X]   →    [X]      →  [X]

Measure: conversion rate and time-in-stage at each step.
The constraint is the step with the LOWEST conversion rate × volume.

Example diagnosis:

• Lead → Qualified: 40% conversion, 2 days
• Qualified → Demo: 80% conversion, 5 days ← High conversion but slow (queue)
• Demo → Proposal: 60% conversion, 3 days
• Proposal → Close: 30% conversion, 14 days ← Constraint (lowest conversion)

Diagnosis: Proposals are being sent to wrong buyers or proposals aren't compelling. Fix: proposal template audit, champion coaching, economic buyer access earlier in process.

---

Part 2: Lean Operations for Tech Companies

The Lean Toolkit (What's Actually Useful)

Lean Manufacturing was designed for car factories. Most of the original toolkit doesn't apply to software. Here's what does:

Value Stream Mapping — Map the full flow of work from customer request to delivery. Label value-add time vs. wait time. Most processes are 90% wait time and 10% actual work.

5S — Sort, Set in order, Shine, Standardize, Sustain. Applied to digital work:

• Sort: Delete unused tools, channels, documents
• Set in order: Organize information architecture so things are findable
• Shine: Regular cleanup sprints (documentation, tech debt, tool hygiene)
• Standardize: Templates, conventions, naming standards
• Sustain: Assign owners; entropy is the default state

Pull vs. Push — Don't push work onto people's plates. Pull = people take work when they have capacity. Push = work is assigned to people regardless of capacity. Most companies push; lean companies pull.

Kaizen — Continuous small improvements. Build this into your operating rhythm:

• Weekly: each team identifies one small improvement to their process
• Monthly: review and close out improvement items
• Quarterly: broader process retrospective

Waste Categories (TIMWOODS) — Applied to Operations:

Exercise: For your most important process, walk through each waste category and estimate hours/week wasted. This exercise typically reveals 20–40% improvement opportunities in the first pass.

Cycle Time and Lead Time

Lead time: Time from when a request enters the system to when it exits (customer perspective). Cycle time: Time a unit of work is actively being worked on (team perspective).

Lead Time = Cycle Time + Wait Time

Most teams only measure cycle time. Customers only experience lead time. The gap between the two is pure waste.

Measuring in your context:

• Engineering: Lead time = ticket created → in production. Cycle time = in progress → PR merged.
• Sales: Lead time = lead created → closed won. Cycle time = demo completed → proposal sent.
• CS: Lead time = ticket opened → customer confirms resolved. Cycle time = ticket in-progress → resolution sent.

Improvement pattern: 1. Measure lead time (not just cycle time) 2. Find the steps where tickets sit waiting 3. Remove the wait (automation, reduced approval layers, clearer handoff criteria)

WIP Limits

Work-In-Progress limits prevent the multi-tasking trap. When people work on 5 things simultaneously, each thing takes 5x longer and quality drops.

Recommended WIP limits:

• Individual IC: 2–3 active items at once
• Team sprint: WIP = number of engineers × 1.5
• Leadership team: No more than 3 company-level priorities per quarter

Implementation: In Jira/Linear, add a WIP column. Set a hard limit. When the column is full, no new work starts until something ships.

---

Part 3: Process Mapping Techniques

When to Map a Process

Map a process when:

• It's done by more than 2 people
• It fails regularly (errors, rework, complaints)
• It needs to scale (you're about to add people or volume)
• You're automating it (you must understand the manual process first)
• You're onboarding someone new to it

Don't map processes that are genuinely ad-hoc, one-person, or will change significantly in the next 90 days.

The Three Levels of Process Maps

Level 1: Swim Lane Map (for cross-functional processes)

Best for: Customer onboarding, sales-to-CS handoff, escalation handling, hiring

Example: Sales to CS Handoff

        | Sales AE      | Sales Ops     | CS Manager    | CS Rep        |
--------|---------------|---------------|---------------|---------------|
Step 1  | Close deal    |               |               |               |
Step 2  | Fill handoff  |               |               |               |
        | doc           |               |               |               |
Step 3  |               | Route to CS   |               |               |
Step 4  |               |               | Review &      |               |
        |               |               | assign        |               |
Step 5  |               |               |               | Send welcome  |
Step 6  |               |               |               | Schedule kick-|
        |               |               |               | off           |

Level 2: Flowchart (for decision-heavy processes)

Best for: Escalation routing, incident response, approval workflows

Use standard symbols:

• Rectangle = action/task
• Diamond = decision (yes/no branch)
• Oval = start/end
• Parallelogram = input/output

Level 3: Work Instructions (for execution-level processes)

Best for: Checklists, SOPs, how-to guides

Format:

Process: [Name]
Owner: [Role]
Last reviewed: [Date]
Trigger: [What starts this process]

Step 1: [Action] — [Who does it] — [Tool used] — [Expected output]
Step 2: ...

Exceptions:
- If [condition], then [alternative action]

Done when: [Definition of done]

Process Audit Technique

Run this quarterly on your most critical processes:

1. Walk the process — Literally follow a unit of work from start to finish. Ask the people doing it, not the people managing it.

2. Measure three numbers:

• How long does it actually take? (lead time)
• How often does it go wrong? (error/rework rate)
• What's the cost of a failure? (downstream impact)

3. Score it:

PROCESS HEALTH SCORE:
Lead time vs. target:          [+2 on target / 0 delayed / -2 significantly delayed]
Error rate:                    [+2 <5% / 0 5-15% / -2 >15%]
Documented:                    [+1 yes / -1 no]
Owner named:                   [+1 yes / -1 no]
Last reviewed (< 6 months):    [+1 yes / -1 no]

Max: 7. Score <3 = needs immediate attention.

---

Part 4: Automation Decision Framework

The "Should I Automate This?" Test

Not everything should be automated. Bad automation of a broken process = faster broken process.

The five-question filter:

1. Is the process stable? If it changes monthly, automate later. Automating unstable processes locks in the wrong behavior.

2. How often does it happen? Weekly or more frequent = good candidate. Monthly or less = probably not worth it.

3. What's the error rate without automation? If the manual process is accurate 95%+ of the time, automation ROI is lower.

4. What's the cost of failure? Customer-facing, compliance, or financial processes deserve higher automation priority than internal reporting.

5. Is the process well-documented? If you can't describe it in a flowchart, you can't automate it. Document first.

Automation ROI Calculation

Annual hours saved = (minutes per occurrence / 60) × occurrences per year
Annual labor cost saved = hours saved × fully-loaded cost per hour
Net annual value = labor cost saved + error reduction value + speed improvement value

Build/buy cost = development time + maintenance overhead
Payback period = build/buy cost ÷ net annual value

Rule of thumb: automate if payback period < 12 months

Example:

• Process: Weekly sales report compilation
• Time: 3 hours/week manually
• Fully-loaded cost: $75/hour
• Annual manual cost: 3 × 52 × $75 = $11,700
• Automation cost: 40 hours to build = $3,000
• Payback: 3,000 ÷ 11,700 = 3 months → Automate

Automation Tiers

Tier 1: No-code automation (0–8 hours to implement)

• Tools: Zapier, Make (Integromat), n8n, HubSpot workflows
• Use for: Notification triggers, data syncs between tools, simple conditional routing
• Example: New customer in CRM → create CS ticket → send welcome Slack message

Tier 2: Low-code automation (8–40 hours to implement)

• Tools: Retool, internal scripts, Google Apps Script, Airtable Automations
• Use for: Internal dashboards, data transformation, approval workflows
• Example: Weekly metrics compilation from Salesforce + Mixpanel + HubSpot into Notion dashboard

Tier 3: Engineered automation (40+ hours to implement)

• Built by engineering team as product/infrastructure work
• Use for: Customer-facing workflows, compliance-critical processes, high-volume operations
• Example: Automated customer health score calculation → CS alert → playbook trigger

Automation Prioritization Matrix

                    HIGH FREQUENCY
                          |
          Tier 1 now      |    Tier 2-3 now
          (quick win)     |    (high-value)
                          |
LOW VALUE ________________|________________ HIGH VALUE
                          |
          Don't bother    |    Plan for later
                          |    (when it's bigger)
                          |
                    LOW FREQUENCY

Place each manual process in the quadrant. Execute top-right first, Tier 1 items second.

Automation Governance

As automation grows, it needs governance:

Automation registry: Maintain a list of all automations with:

• Name and description
• Owner (person responsible if it breaks)
• Tools used
• Trigger and action
• Last tested date
• Business impact if down

Review cadence: Quarterly review of automation registry. Kill automations nobody uses.

Failure alerting: Every production automation must have failure notifications sent to a named owner. Silent failures are worse than no automation.

---

Part 5: Change Management for Process Rollouts

Why Process Changes Fail

Most process changes fail not because the process is wrong, but because of how it's rolled out. Common failure modes:

• Top-down dictate: Process designed by leadership, announced to team, implemented poorly because people weren't involved and don't understand why.
• No training: "Here's the new process" with no demonstration or practice.
• No feedback loop: Process is rolled out and never adjusted based on what the team discovers.
• No accountability: Process is optional in practice because there are no consequences for ignoring it.
• Old behavior still possible: You introduce a new tool but don't turn off the old way.

The Change Management Framework (ADKAR)

ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) is the most practical model for operational change.

A — Awareness: Does everyone understand WHY the change is needed?

• Don't just announce the new process — explain what was broken about the old one
• Share the data: "Our current onboarding takes 45 days, customers who onboard faster have 2x better retention. The new process targets 21 days."

D — Desire: Do people want to change?

• Resistance is information. Listen to it.
• Involve front-line workers in process design. People support what they help build.
• Address WIIFM (What's In It For Me) for each affected group

K — Knowledge: Do people know HOW to do the new process?

• Write it down (work instructions format above)
• Run live demos and practice sessions
• Create a "first time" checklist

A — Ability: Can people actually do the new process?

• Identify where people get stuck (first 2 weeks of rollout)
• Have a designated expert for questions
• Remove friction: if the new process requires 3 clicks where the old required 1, people will revert

R — Reinforcement: Does the change stick?

• Measure adoption (are people actually using the new process?)
• Celebrate early adopters
• Address non-adoption promptly — call it out without shame

Change Rollout Checklist

PRE-LAUNCH:
□ Process designed and documented
□ Stakeholders identified (people affected by change)
□ Champions identified (people who will help adoption)
□ Training materials created
□ Success metrics defined (how will you know it worked?)
□ Rollback plan documented (what if it breaks something?)
□ Launch timeline set and communicated

LAUNCH WEEK:
□ Announcement sent with WHY, WHAT, and WHEN
□ Training sessions held (at least 2 options for different schedules)
□ Feedback channel opened (Slack thread, form, or dedicated meeting)
□ Champions briefed to support peers

2-WEEK CHECK:
□ Adoption rate measured
□ Friction points documented
□ Quick fixes implemented
□ Feedback reviewed and responded to

30-DAY REVIEW:
□ Success metrics reviewed vs. baseline
□ Process adjustments made based on learnings
□ Champions recognized
□ Process documentation updated with lessons learned

90-DAY CLOSE:
□ Full adoption confirmed or non-adoption addressed
□ Process owners confirmed
□ Handoff to BAU (business as usual) operations

Managing Resistance

Types of resistance and responses:

The three levers of adoption: 1. Make the new way easier than the old way (remove the old path if possible) 2. Make non-adoption visible (dashboards showing who's using the process) 3. Connect process to meaningful outcomes (show how it affects things people care about)

Process Documentation Standards

Every process should have exactly one owner responsible for keeping it current.

Minimum documentation for any process:

• Process name and one-sentence purpose
• Owner: Named individual, not a team
• Trigger: What starts this process
• Steps: Written at the level that a new employee could execute
• Exceptions: Common edge cases and how to handle them
• Done definition: How you know the process is complete
• Review date: Set a future date when this gets reviewed

Documentation debt kills scale. The most valuable time to document is right after you've run the process for the third time — you've found the edge cases, you know the real steps, and the process is still fresh.

---

Framework Selection Guide

---

Frameworks synthesized from: Eliyahu Goldratt's The Goal and Critical Chain; Womack and Jones' Lean Thinking; Prosci ADKAR model; Scaled Agile Framework (SAFe) process guidance; operational playbooks from Stripe, Airbnb, and Shopify operations teams.

Scaling Playbook: What Breaks at Each Growth Stage

Compiled from patterns across 100+ high-growth companies. Not theory — this is what actually breaks and what to do about it.

---

How to Use This Playbook

Each stage section covers: 1. What breaks — the specific failure modes that kill companies at this stage 2. Hiring — who to bring in and when 3. Process — what to formalize vs. keep loose 4. Tools — infrastructure that unlocks the next stage 5. Communication — how information flow changes 6. Culture — what to protect and what to let go

Benchmarks are medians — your mileage varies by sector, geography, and business model.

---

Stage 0: Pre-Seed / Seed ($0–$2M ARR, 1–15 people)

Key Benchmarks

What Breaks

Premature process. The #1 mistake at seed stage is adding process before you have a repeatable model. Sprint ceremonies, OKR frameworks, and performance reviews are all theater when you haven't found PMF. Every hour spent in process is an hour not spent learning.

Wrong first hires. Hiring "senior" people who've only worked in structured environments. You need people who can operate in chaos, not people who expect process to already exist.

Founder communication bottleneck. Founders try to be in every decision. Fine at 5 people, fatal at 12. No written decisions means knowledge lives in founders' heads — unscalable.

Technical debt accepted as strategy. "We'll fix it later" said about core data models, auth systems, or billing. Later comes at Series A and it costs 3x more to fix.

Hiring

• Don't hire for scale you don't have. Hire for the next 12 months.
• First 10 hires set culture permanently. Get them wrong and you'll spend years correcting.
• Hire athletes, not specialists. Generalists who can do multiple jobs outperform specialists at this stage.
• Avoid VP titles early. Inflated titles block future hires and create expectations you can't meet.
• Founder-referral bias is real. Your network is homogeneous. Force diversity early.

Who to hire first (in rough order): 1. Engineers who can ship product (2–3 generalists) 2. First sales/GTM if B2B (founder-led sales first, then one closer) 3. Designer/product (often a hybrid) 4. Customer success (often a founder at first)

Process

Formalize nothing before PMF. Literally. Run on Slack, shared docs, and founder judgment.

After PMF signals appear, formalize only:

• How you handle customer escalations
• How you deploy code (even basic CI/CD)
• How you onboard new hires (a 1-page checklist is enough)

Decision rule: If a founder has to answer the same question three times, write it down. Once.

Tools

Rule: One tool per function. No tool sprawl. Every extra tool is a coordination tax.

Communication

• Weekly all-hands (30 min max). What shipped, what's stuck, what's next.
• No status meetings. Anyone can see status in Linear/Notion.
• Founder write-ups. Every major decision gets a 1-paragraph Slack post explaining why.
• Group chat discipline. One channel per project/customer. Inbox zero mentality.

Culture

What to build deliberately:

• High ownership: everyone acts like they own the company, because they do
• Direct feedback: brutal honesty delivered with care
• Bias to ship: done > perfect
• Customer obsession: founders talk to customers weekly

What to watch for:

• "Hero culture" where one person saves everything — unsustainable
• Over-indexing on culture fit (code for homogeneity)
• Avoidance of conflict — mistaking silence for agreement

---

Stage 1: Series A ($2–$10M ARR, 15–50 people)

Key Benchmarks

What Breaks

Founder-as-manager bottleneck. At 20+ people, founders can't manage everyone. The first layer of management needs to appear — and it's usually picked wrong (best IC ≠ best manager).

Tribal knowledge explosion. "Ask Sarah" stops working when Sarah has 15 things open. Documentation becomes critical — not for bureaucracy, but because institutional knowledge is now a flight risk.

Sales process fragmentation. Without a defined sales process, every rep closes differently. You can't train, debug, or scale what you can't see.

Scope creep in product. With Series A money comes investor pressure to expand scope. Teams try to build three things at once and ship nothing well.

Compensation chaos. Early employees got equity-heavy deals. New hires get market cash. Someone compares, someone gets upset. No comp philosophy = constant re-negotiation.

Recruiting becomes a job in itself. Founders can't hire 30 people themselves. First dedicated recruiter needed by 25 people.

Hiring

Who to hire at Series A:

• Head of Engineering (if founder is CTO): needs to be an operator, not just an architect
• First Sales Manager (when you have 3+ reps): don't promote the best seller
• HR/People Ops (generalist, by 30 people): comp, compliance, recruiting coordination
• Finance (fractional CFO or strong controller): Series A board needs real numbers
• Customer Success Lead: retention is everything at this stage

Hiring mistakes to avoid:

• Hiring "big company" execs who need large teams and established process
• Assuming your Series A lead can recruit (they can intro, not close)
• Taking too long — top candidates have 2–3 offers. Move in <2 weeks from first call to offer.

Leveling: Build a simple career ladder before the compensation complaints start. 3–4 levels per function is enough.

Process

What to formalize at Series A: 1. Sprint planning (2-week sprints, public roadmap) 2. Sales process (defined stages with entry/exit criteria) 3. Onboarding (30/60/90 day plan for each function) 4. 1:1 cadence (weekly for direct reports, bi-weekly for skip-levels) 5. Incident response (P0/P1/P2 definition, on-call rotation) 6. Quarterly planning (OKRs or goals framework — keep it lightweight)

What to keep loose:

• Internal project process (let teams self-organize)
• Meeting formats (let teams evolve their own rituals)
• Tool selection within approved stack

Documentation standard: Write decisions down in a shared wiki. "Decision log" with date, decision, context, owner, and outcome. Takes 5 minutes, saves hours.

Tools

Communication

Introduce structured communication layers:

1. Company all-hands (monthly, 60 min): CEO share, metrics review, team spotlights, Q&A 2. Leadership sync (weekly, 60 min): cross-functional issues, blockers, priorities 3. Team standups (async or 15 min daily): what's in progress, what's blocked 4. 1:1s (weekly): direct report health, career, performance 5. Written updates (weekly to investors + board): CEO memo format

Information hierarchy: Everyone in the company should know: (1) company goals this quarter, (2) their team's goals, (3) what they personally own. If they don't, your communication structure is broken.

Culture

Deliberate culture work starts here. You're too big for culture to be accidental.

• Write down values. Real values with examples of what they look like in action. Not "integrity" — "we tell investors bad news before we tell them good news."
• Performance management. First PIPs (Performance Improvement Plans) happen at this stage. Handle them well — the team is watching.
• Equity culture. Make sure people understand what their equity is worth in different outcomes. Lack of transparency breeds resentment.
• First layoff plan. Even if you never use it, know the criteria. Reactive layoffs destroy trust; plan-based ones (even painful) preserve it.

---

Stage 2: Series B ($10–$30M ARR, 50–150 people)

Key Benchmarks

What Breaks

Middle management void. You now have managers managing managers. The "player-coach" model breaks — people can't be ICs and managers simultaneously at this scale. Force the choice.

Planning misalignment. Sales promises what product hasn't built. Product builds what customers didn't ask for. Engineering ships what QA didn't test. Fixing this requires cross-functional planning ceremonies.

Data fragmentation. Five different versions of "how are we doing." Sales sees Salesforce. Product sees Amplitude. Finance sees spreadsheets. Nobody agrees. You need a single source of truth.

Process debt. The Series A processes are starting to creak. Onboarding that worked for 5 hires/quarter doesn't work for 20. Customer escalation paths built for 50 customers fail at 500.

Cultural fragmentation. Engineering culture ≠ Sales culture ≠ Support culture. Sub-cultures form. The shared identity you had at 30 people requires active work to maintain at 100.

The "brilliant jerk" problem. High performers with bad behavior were tolerated early. Now they're managers with bad behavior, and it's systemic. Act decisively or lose your best people.

Hiring

Who to hire at Series B:

• COO or VP Operations: founder is overwhelmed, someone needs to run the machine
• VP Sales: first Sales Manager won't scale to 20-rep org
• VP Marketing: demand gen and brand need dedicated ownership
• Dedicated Recruiting: 2–3 recruiters minimum; you're hiring 30–50 people/year
• Data/Analytics: dedicated analyst or data engineer to consolidate reporting
• Legal counsel: fractional or in-house; contracts and compliance are getting complex

The "big company exec" trap. Series B is when companies hire their first VP from FAANG or a large SaaS company. 60% of these fail within 18 months. They're used to: large teams, established brand, existing process, political navigation. They struggle with: scrappy execution, no support staff, ambiguous direction. Vet explicitly for startup experience.

Span of control. At this stage, hold managers to 5–8 direct reports. More than 8 = no time for actual management. Less than 3 = management overhead isn't justified.

Process

What to formalize at Series B: 1. Quarterly Business Reviews (QBRs) — every function presents metrics, wins, gaps 2. Annual planning — budget, headcount plan, strategic priorities 3. Cross-functional roadmap alignment — product/sales/marketing in sync quarterly 4. Promotion criteria — written, public, applied consistently 5. Interview scorecards — structured interviews with defined rubrics 6. Change management — how major process changes get communicated and adopted 7. Vendor management — evaluation criteria, approval process, contract management

SOPs for critical processes:

• Customer onboarding (if >50 customers)
• Sales handoff from SDR to AE to CS
• Engineering release process
• Incident response playbook
• Contractor/vendor procurement

Tools

Communication

At 50+ people, informal communication breaks down. Information no longer flows naturally — it has to be architected.

Communication stack:

• Monthly all-hands (90 min): metrics deep-dive, strategy update, team Q&A
• Weekly leadership team (90 min): cross-functional priorities, decisions, escalations
• Bi-weekly skip-levels (30 min): every manager holds these with their manager's reports
• Quarterly town halls (2 hrs): broader context, financial update, roadmap preview
• Written company update (bi-weekly): CEO to all-hands via Slack/email

The information gradient problem. People at the top know too much. People at the bottom know too little. Fix this with a deliberate "broadcast" culture — any decision affecting more than 5 people gets written up and shared.

Culture

Retention becomes an existential issue. At Series B, you have 50–150 people who've been with you through something hard. They're valuable. And they have options.

• Career ladders are non-negotiable by this stage. People leave when they can't see a future.
• Manager quality determines retention. Invest in manager training. Run manager effectiveness surveys.
• Compensation benchmarking quarterly. If you're more than 10% below market, you're losing people silently.
• Culture carriers. Identify the 10–15 people who embody your culture and make them formally responsible for transmitting it. Give them a platform.

---

Stage 3: Series C ($30–$75M ARR, 150–500 people)

Key Benchmarks

What Breaks

Strategy execution gap. Leadership agrees on strategy. Middle management interprets it differently. ICs execute on their interpretation. By the time work ships, it barely resembles the original strategy. Fix: strategy must cascade in writing with explicit outcomes.

Process bureaucracy. The processes you built at Series B start generating bureaucracy. Approval chains lengthen. Simple decisions require three meetings. The antidote is explicit process owners empowered to eliminate friction.

Org design complexity. Do you have functional teams (all engineers in one org) or product teams (engineers embedded in product squads)? The answer affects everything: career paths, knowledge sharing, delivery speed. Most companies get this wrong twice before getting it right.

Geographic complexity. First international office or remote-heavy team introduces timezone, communication, and culture challenges that don't exist when everyone is in one room.

Leadership team dysfunction. Seven VPs who were all individual contributors two years ago are now running $10M+ organizations. Some have grown into it. Some haven't. This is the stage where hard leadership team changes happen.

Hiring

Series C hiring is about depth, not breadth. You have functional coverage — now hire people who go deep within functions.

• Functional leaders' deputies: VP Engineering needs a Director of Platform Engineering, Director of Product Engineering, etc.
• Internal promotions: 40–60% of leadership roles should be filled internally by now. If you're hiring externally for everything, you've failed at development.
• Specialists: Security, data science, UX research, RevOps — functions that were "shared" become dedicated.
• General Counsel: Legal volume justifies full-time counsel.

Headcount planning discipline. Every hire should have a business case. "The team is busy" is not a business case. "This role will unlock $X in revenue or save Y hours/week" is a business case.

Process

Process consolidation. Audit every process. Kill anything that doesn't have a clear owner and clear outcome. The average Series C company has 40% more process than it needs.

Key processes to have locked at Series C: 1. Annual planning cycle (strategy → goals → headcount → budget) 2. Quarterly operating review (progress against plan, forecast, adjustments) 3. Product development lifecycle (discovery → design → build → launch → measure) 4. Revenue operations (forecasting, pipeline management, territory planning) 5. People operations (performance cycles, promotion cadence, compensation philosophy) 6. Risk management (operational, security, compliance, legal)

Delegation architecture. At 200+ people, the COO cannot know about every decision. Build explicit decision rights: what decisions require CEO/COO approval vs. VP vs. Director vs. IC.

Tools

Consolidate the tech stack. By Series C, you have tool sprawl. The average 200-person company has 100+ SaaS tools. 40% are redundant. Consolidation saves $200–500K/year and reduces security surface.

Must-have by Series C:

• Enterprise SSO (Okta/Google Workspace with MFA everywhere)
• Data warehouse (Snowflake/BigQuery) + BI layer
• HRIS with performance management (Workday, Rippling, BambooHR)
• Revenue intelligence (Gong, Chorus)
• Security tooling (endpoint, SIEM basics, SOC 2 compliance)

Communication

Internal comms becomes a function. You cannot rely on ad-hoc Slack and email at 200+ people. Someone needs to own internal communications.

• Monthly CEO update (written, 500 words max): company performance, strategic context, what's next
• Quarterly all-hands (2 hrs): comprehensive business review, open Q&A
• Leadership alignment sessions (quarterly): leadership team off-site to calibrate on strategy
• Manager cascade (after every major announcement): managers brief their teams with tailored context

Culture

Culture is now a function, not an instinct. By Series C, your original culture-carriers are managers or have left. New people joining have never seen how you worked when you were small.

• Culture explicitly documented — not a values poster, a behavioral handbook
• Onboarding redesigned for culture transmission at scale
• Manager enablement — managers are your primary culture delivery mechanism; invest heavily
• Listening infrastructure — eNPS quarterly, exit interviews, skip-level feedback — all analyzed systematically

---

Stage 4: Growth Stage ($75M+ ARR, 500+ people)

Key Benchmarks

What Breaks

Execution at scale. The larger you are, the harder it is to move fast. The average decision at a 500-person company takes 3x longer than at a 50-person company. This is not inevitable — but fixing it requires explicit investment.

Internal politics. Org boundaries create fiefdoms. VPs protect headcount. Teams optimize for their metrics at the expense of company metrics. This is the #1 culture problem at scale.

Innovation starvation. The core business is optimized, but new bets are starved of resources. The people working on new initiatives are constrained by processes designed for a mature product. Structural solution required: separate P&L, separate team, different metrics.

Middle management bloat. Growth-stage companies often have too many managers and not enough ICs. A manager managing one other manager managing three ICs is a 3-level chain where 2 people add no value. Flatten aggressively.

Hiring

You're now competing for talent with FAANG. Your advantage is mission, equity, and the ability to have impact. Candidates who want to join a Fortune 500 will not join you. Stop trying to attract them.

• Leadership pipeline: promote from within at 50%+ for senior roles
• Talent density over headcount: 30 strong engineers > 50 average engineers
• Diverse hiring: by this stage, lack of diversity is a business problem, not just an ethical one

Operational Priorities at Scale

1. Operational efficiency over growth: headcount growth should lag revenue growth 2. Process ownership: every major process has a named owner accountable for outcomes 3. Quarterly operating model: budget vs. actual, full P&L transparency to VP level 4. Automation: manual operational processes that cost >40 hrs/week should be automated

---

Cross-Stage Principles

The Three Things That Kill Companies at Every Stage

1. Running out of cash before finding the next unlock — runway management is sacred 2. Hiring the wrong person for a critical role — one bad VP can set you back 18 months 3. Moving too slowly — market timing matters; perfect is the enemy of shipped

The Org Design Progression

Seed:     Flat | Everyone reports to founder | No structure
Series A: Functional pods | First-line managers | Light structure
Series B: Functional departments | VPs emerge | Defined structure
Series C: Business units or product squads | Directors + VPs | Full structure
Growth:   Divisional or matrix | EVPs/SVPs | Corporate structure

Revenue per Employee by Function (B2B SaaS benchmarks)

Revenue per employee = ARR / headcount in function

The Management Span Rule

• Individual contributors being managed: 1 manager per 6–8 ICs
• Managers being managed: 1 director per 4–6 managers
• Directors being managed: 1 VP per 3–5 directors
• VPs being managed: 1 C-level per 5–8 VPs

Violation of this creates either manager burnout (too wide) or management theater (too narrow).

---

Red Flags by Stage

---

Sources: Sequoia, a16z operating frameworks; First Round Capital COO benchmarks; SaaStr metrics databases; OpenView SaaS benchmarks; Bain operational maturity models.