claude-code-arcane 1.0.0

package/skills/chro-advisor/references/comp_frameworks.md

@@ -0,0 +1,320 @@
+# Compensation Frameworks Reference
+
+Salary bands, equity design, total comp modeling, comp philosophy, and raise/refresh processes.
+
+---
+
+## Comp Philosophy — The Foundation
+
+Before building bands, define your philosophy. Ambiguity in comp philosophy = pay equity lawsuits and trust erosion.
+
+**The five decisions:**
+
+### 1. What market percentile do you target?
+- **P25 (below market):** Only viable with exceptional mission, equity, or growth opportunity. Flight risk is high after 18 months.
+- **P50 (market median):** Standard for most Series A–B companies. Competitive without premium.
+- **P75 (above market):** Premium talent strategy. Used by high-margin or talent-intensive businesses. Netflix model.
+- **P90+:** Top-of-market for specific functions (ML at AI companies, senior engineers at FAANG feeders).
+
+**Common hybrid:** P50 base + above-market equity = total comp at P65–75.
+
+### 2. What's in your total comp package?
+Define each component explicitly:
+- **Base salary** — cash, market-benchmarked
+- **Variable / bonus** — % of base, tied to what criteria
+- **Equity** — options vs. RSUs, vesting schedule, refresh cadence
+- **Benefits** — health, retirement, PTO policy
+- **Learning & development budget**
+- **Remote/location allowances**
+
+### 3. Are bands public internally?
+Recommended: Yes. Pay transparency reduces equity complaints, builds trust, and forces you to maintain clean bands.
+
+### 4. How often do you refresh bands?
+Minimum: annually. High-growth markets: every 6 months (engineering specifically in hot markets).
+
+### 5. How do you handle individual negotiation?
+Options:
+- **Fixed bands, no negotiation** (Buffer model) — simple, fair, loses some candidates
+- **Band range with manager discretion** — most common, requires calibration guardrails
+- **Individual negotiation within band** — flexible, creates pay equity drift over time
+
+---
+
+## Salary Bands: Construction
+
+### Step 1: Define levels
+
+Standard IC levels (adapt to company):
+| Level | Title example | Scope |
+|-------|--------------|-------|
+| L1 | Junior / Associate | Execution with guidance |
+| L2 | Mid-level | Independent execution |
+| L3 | Senior | Leads workstreams, mentors L1-L2 |
+| L4 | Staff / Principal | Cross-team technical leadership |
+| L5 | Distinguished / Fellow | Company-wide technical direction |
+
+Management track:
+| Level | Title | Scope |
+|-------|-------|-------|
+| M1 | Manager | Team of 4–8 ICs |
+| M2 | Senior Manager | Manager of managers or larger team |
+| M3 | Director | Function or large org |
+| M4 | VP | Business unit, company-wide |
+| M5 | SVP / C-Suite | Executive |
+
+### Step 2: Gather market data
+
+**Data sources (by quality):**
+1. **Radford / Aon** — Gold standard. Expensive ($10K+/year). Worth it at Series B+.
+2. **Levels.fyi** — Excellent for engineering. Free. Self-reported but large sample.
+3. **Glassdoor Salary** — Broad coverage. Less precise for startups.
+4. **Pave / Carta Total Comp** — VC-backed companies. Good peer benchmarking.
+5. **LinkedIn Salary** — Free tier. Reasonable signal for G&A roles.
+6. **Offer letter data** — What candidates are bringing from other companies. Real-time signal.
+
+**What to pull:** P25, P50, P75, P90 for each role × level × geography.
+
+### Step 3: Set band structure
+
+**Band width (range within a level):**
+- IC bands: 80–120% of midpoint (i.e., ±20% from center)
+- Manager bands: 85–115% of midpoint
+- Wider bands allow room for differentiation within level; narrower bands reduce pay equity drift
+
+**Band overlap between levels:**
+- 10–20% overlap is normal (top of L2 overlaps with bottom of L3)
+- > 30% overlap: your levels are too close together
+- No overlap: new hires jump too much between levels (compression risk)
+
+**Example engineering band structure (US, Series B company, P50 target):**
+
+| Level | Band Min | Midpoint | Band Max |
+|-------|----------|----------|----------|
+| L1 Software Engineer | $90K | $105K | $125K |
+| L2 Software Engineer | $115K | $135K | $160K |
+| L3 Senior SWE | $150K | $175K | $205K |
+| L4 Staff SWE | $195K | $225K $260K |
+| M1 Eng Manager | $175K | $205K | $235K |
+| M2 Sr Eng Manager | $215K | $250K | $285K |
+| M3 Director, Eng | $255K | $300K | $345K |
+
+*Adjust by 15–25% for non-SF/NYC markets. Adjust -40% to -60% for European markets.*
+
+### Step 4: Place employees in bands
+
+**Compa-ratio** = Employee salary / Band midpoint
+
+| Compa-ratio | Interpretation |
+|------------|---------------|
+| < 0.85 | Below range — immediate risk |
+| 0.85–0.95 | Developing in role |
+| 0.95–1.05 | Fully performing (target zone) |
+| 1.05–1.15 | Senior/expert in role |
+| > 1.15 | Above range — flag for review |
+
+**Audit report:** Run quarterly. Flag anyone below 0.85 (flight risk) or above 1.15 (overpaid for level, or needs promotion).
+
+---
+
+## Equity Frameworks for Startups
+
+### Option Basics
+
+**ISO vs NSO:**
+- ISO (Incentive Stock Options): For employees. Favorable tax treatment if held 1+ year post-exercise.
+- NSO (Non-Qualified Stock Options): For advisors, contractors, sometimes employees. Taxed as ordinary income on exercise.
+
+**Strike price:** Set to 409A valuation at grant. Lower is better for employees. Early employees win on strike price.
+
+**Vesting schedule standards:**
+- 4-year vest, 1-year cliff: Standard
+- 4-year vest, 6-month cliff: Startup market adapting to faster pace
+- 1-year cliff means: nothing until 12 months; monthly or quarterly after
+
+**Post-termination exercise window (PTEW):**
+- Standard: 90 days. Often too short for employees who can't afford exercise.
+- Better: 1–5 years or until IPO. Use as a talent differentiator.
+- Companies extending PTEW: Stripe, Airbnb (pre-IPO), Square, most employee-friendly startups.
+
+### Equity Grant Ranges by Stage and Level
+
+*Expressed as % of fully diluted shares at grant. Ranges vary significantly by market, stage, and funding.*
+
+**Seed stage:**
+| Role | Equity % |
+|------|----------|
+| Co-founder | 20–40% |
+| First engineering hire | 0.5–1.5% |
+| First non-technical exec hire | 0.25–0.75% |
+| IC (L2-L3) | 0.1–0.4% |
+| IC (L3-L4) | 0.2–0.6% |
+
+**Series A:**
+| Role | Equity % |
+|------|----------|
+| VP / Head of function | 0.3–0.75% |
+| Director | 0.1–0.3% |
+| Senior IC (L3) | 0.05–0.15% |
+| Mid IC (L2) | 0.02–0.08% |
+| Junior IC (L1) | 0.01–0.05% |
+
+**Series B:**
+| Role | Equity % |
+|------|----------|
+| VP / Head of function | 0.1–0.3% |
+| Director | 0.05–0.15% |
+| Senior IC (L3) | 0.02–0.07% |
+| Mid IC (L2) | 0.01–0.03% |
+
+*At Series B+, equity is increasingly expressed in dollar value (grant value = X shares × current 409A). Use Carta or Pulley to model dilution.*
+
+### Equity Refresh Program
+
+**Why it matters:** Employees hired at Series A with 4-year vesting will be fully vested by Series B. No unvested equity = no retention hook.
+
+**When to refresh:**
+- After every significant funding round
+- Annually for high performers (top 20%)
+- After promotion (role-commensurate top-up)
+- Counter-offer situations (use carefully — signals you underpaid initially)
+
+**Refresh models:**
+1. **Anniversary grant:** Annual cliff-free refresh for all employees above a performance threshold
+2. **Evergreen model:** Continuous vesting maintained — refresh annually so employee always has 2–3 years remaining
+3. **Event-based:** Refresh tied to milestones (promotion, funding, annual review cycle)
+
+**Dilution awareness:** Every refresh dilutes existing shareholders. Model pool usage quarterly. Replenish option pool before it drops below 10–12% of fully diluted shares.
+
+---
+
+## Total Comp Modeling
+
+### Components of Total Comp
+
+```
+Total Compensation = Base Salary
+                   + Annual Bonus (target %)
+                   + Equity Value (annualized grant / vesting period)
+                   + Benefits (employer-paid premiums, retirement match)
+                   + Allowances (home office, internet, L&D, commuter)
+```
+
+### Annualizing Equity Value
+
+For comparison to cash compensation:
+
+```
+Annual equity value = (Grant shares × Current 409A price) / Vesting years
+```
+
+Example: 10,000 options at $2 strike, current 409A = $8, 4-year vest
+- Grant value at current 409A = 10,000 × $8 = $80,000
+- Annual value = $80,000 / 4 = $20,000/year
+- If base is $150K, total comp is ~$170K/year
+
+*Note: For recruiting purposes, you can use last preferred share price (VC price) to show upside — but be transparent about the difference between 409A and preferred.*
+
+### Benefits Valuation
+
+Frequently undervalued in offers. Quantify explicitly:
+| Benefit | Typical employer cost |
+|---------|----------------------|
+| Health insurance (employee) | $4K–8K/year |
+| Health insurance (family) | $15K–25K/year |
+| 401K match (4% of salary) | $5K–10K/year |
+| L&D budget ($2K/year) | $2K/year |
+| Home office stipend ($500) | $500/year |
+
+A $140K offer with family health coverage + 4% 401K match is worth $165K+ total.
+
+---
+
+## Raise and Refresh Process
+
+### Annual Compensation Review Cycle
+
+**Recommended cadence:**
+- October/November: Market data refresh, band updates
+- November/December: Manager merit recommendations
+- December/January: Calibration and approvals
+- January/February: Effective date for new salaries + equity grants
+
+**Budget allocation:**
+- **Merit budget** (performance-based raises): 3–5% of total payroll typically
+- **Market adjustment budget** (fixing below-band salaries): Separate from merit. Non-negotiable to avoid attrition.
+- **Promotion budget:** Separate. Promotions should not come from merit pool.
+
+### Merit Increase Guidelines
+
+| Performance Rating | Merit Increase Range |
+|-------------------|---------------------|
+| 5 – Exceptional | 8–15% |
+| 4 – Exceeds | 5–8% |
+| 3 – Meets | 2–4% |
+| 2 – Needs improvement | 0–1% |
+| 1 – Underperforming | 0% (PIP active) |
+
+*Adjust based on compa-ratio. A high performer at P90 of their band gets a smaller increase than a high performer at P50.*
+
+### Compa-Ratio Adjustment Matrix
+
+| Performance \ Compa-Ratio | < 0.90 | 0.90–1.00 | 1.00–1.10 | > 1.10 |
+|---------------------------|--------|-----------|-----------|--------|
+| Exceptional (5) | 12–15% | 8–12% | 5–8% | 3–5% |
+| Exceeds (4) | 8–12% | 5–8% | 3–5% | 1–3% |
+| Meets (3) | 5–8% | 3–5% | 2–3% | 0–2% |
+| Needs impr (2) | 0–2% | 0–1% | 0% | 0% |
+
+### Promotion vs. Merit — Keep These Separate
+
+**Common mistake:** Using merit budget to fund promotions. This forces a choice between rewarding performance and recognizing level change.
+
+**Promotion increase guidelines:**
+- One level (e.g., L2 → L3): 10–20% increase, new equity grant
+- Two levels (rare): 20–35% increase, new equity grant at new level
+- Manager track (IC → M1): 15–25% increase, new equity grant
+
+**Promotion criteria process:**
+1. Manager nominates with written business case
+2. Calibration committee reviews cross-functionally
+3. HR validates against band (no off-band exceptions without CHRO sign-off)
+4. Employee informed before annual review — never surprised at review meeting
+
+### Off-Cycle Adjustments
+
+When to do them:
+- Counter-offer situations (see below)
+- Competitive intelligence reveals underpay for a specific role
+- New market data shows a role significantly under-benchmarked
+- Internal equity audit reveals unexplained gaps
+
+**Counter-offer policy:**
+Three options:
+1. **Match** — Risk: signals you underpay; sets precedent
+2. **Partial match** — "We can do X, which is the top of your band" — cleaner
+3. **Decline** — Accept the attrition, improve the band for the next hire
+
+**Rule:** If you're regularly in counter-offer conversations, your bands are stale. Fix the bands.
+
+---
+
+## Pay Equity Audit
+
+Run annually. Non-negotiable at Series B+.
+
+**What to audit:**
+- Pay gap by gender within each level and function
+- Pay gap by ethnicity within each level and function
+- Compa-ratio distribution across demographics
+- Time-to-promotion by demographic group
+
+**Methodology:**
+1. Pull all employee data: level, function, salary, tenure, performance ratings, gender, ethnicity
+2. Run regression controlling for level, tenure, and performance
+3. Unexplained gap after controls = the problem to fix
+4. Flag and remediate within the same review cycle
+
+**Legal exposure:** In many jurisdictions, documented pay gaps without remediation plans are litigation risk. The audit creates a record of intent; remediation closes the risk.
+
+**Remediation budget:** Set aside 0.5–1% of payroll annually for equity adjustments. If you're doing it right, this shrinks over time.

package/skills/chro-advisor/references/org_design.md

@@ -0,0 +1,333 @@
+# Org Design Reference
+
+Spans of control, layering decisions, reorgs, title frameworks, career ladders, and the founder→professional management transition.
+
+---
+
+## Core Org Design Principles
+
+1. **Structure follows strategy.** Reorg after strategy shifts, not before.
+2. **Optimize for the bottleneck.** Where does work get slow? Design around that.
+3. **Minimize coordination cost.** Conway's Law: your org structure becomes your product architecture. Design intentionally.
+4. **Bias toward flatness until it breaks.** Adding layers adds cost and slows decisions.
+5. **Reorgs have transition costs.** Relationships reset. Count the cost before you restructure.
+
+---
+
+## Spans of Control
+
+Span of control = number of direct reports a manager has.
+
+### Benchmarks
+
+| Role Type | Optimal Span | Min | Max |
+|-----------|-------------|-----|-----|
+| IC manager (predictable work) | 7–10 | 5 | 12 |
+| IC manager (complex/creative work) | 5–7 | 4 | 8 |
+| Manager of managers | 4–6 | 3 | 7 |
+| VP / Director | 4–7 | 3 | 8 |
+| C-Suite | 5–9 | 4 | 10 |
+
+**Too narrow (< 4 ICs):** Over-management, high cost per output, manager becomes a bottleneck
+**Too wide (> 12 ICs):** Under-management, degraded 1:1 quality, feedback loops collapse
+
+### Factors that allow wider spans
+- Highly autonomous, senior team (L3+ ICs)
+- Predictable, well-defined work (support, ops)
+- Strong tooling and process (reduces manager overhead)
+- Experienced manager
+
+### Factors that require narrower spans
+- High-complexity, undefined problems (research, early product)
+- Junior or newly promoted team members
+- High interdependence between reports (coordination overhead)
+- Manager is also an IC contributor (player-coach)
+
+---
+
+## When to Add Management Layers
+
+**The wrong reason to add layers:** "We need to give good people somewhere to grow."
+**The right reason:** "This manager has too many direct reports to do the job well."
+
+### Layer triggers by growth stage
+
+**0 → 15 people:** No layers. Everyone reports to founders.
+
+**15 → 30 people:** First managers emerge. Usually technical leads or function leads. Should still be player-coaches.
+
+**30 → 60 people:** Second layer forms. Engineering splits into squads. Sales gets a frontline manager. Each function has a head.
+
+**60 → 150 people:** Director layer becomes necessary in large functions. Engineering VP + Engineering Directors + Team Managers.
+
+**150+ people:** VP layer fully staffed. Senior Director / Director split. Clear IC → M → Senior M → Director → VP paths.
+
+### The Rule of 7
+
+When any manager has 7 or more direct reports and:
+- 1:1s are skipped regularly
+- Feedback quality drops
+- Manager can't answer "how is each person doing?" without checking notes
+
+→ Time to split or hire a manager.
+
+### Management overhead cost
+
+Every manager layer costs 10–15% in decision speed (communication hops).
+Every management role without a team = pure overhead.
+
+**Litmus test for each management role:**
+- Does this person have at least 4 ICs under them?
+- Would removing this role improve decision speed?
+- Is this a management job or a "we ran out of IC levels" job?
+
+---
+
+## Functional vs. Product Org Structures
+
+### Functional Structure (by discipline)
+
+```
+CEO
+├── VP Engineering
+│   ├── Backend Team
+│   ├── Frontend Team
+│   └── DevOps
+├── VP Product
+│   ├── PM (Feature A)
+│   └── PM (Feature B)
+└── VP Design
+    └── UX Designers
+```
+
+**Best for:** Early stage, < 100 people, single product
+**Advantage:** Deep expertise development, clear career paths per discipline
+**Disadvantage:** Cross-functional coordination is heavy; features require synchronization across silos
+
+### Product/Pod Structure (by product area)
+
+```
+CEO
+├── Product Area A (autonomous team)
+│   ├── EM
+│   ├── PM
+│   └── Designer
+├── Product Area B (autonomous team)
+│   ├── EM
+│   ├── PM
+│   └── Designer
+└── Platform (shared services)
+    └── Platform EM + team
+```
+
+**Best for:** Multiple products or large user segments, 50+ in product/eng
+**Advantage:** Speed and autonomy; less cross-team coordination for most features
+**Disadvantage:** Duplication risk; harder to maintain technical coherence; harder career paths
+
+### When to shift from Functional → Product org
+- You have 2+ distinct product lines that rarely share features
+- Cross-functional feature delivery takes > 3 sprints of coordination overhead
+- Teams are > 8 engineers and still waiting on shared resources
+
+### Hybrid / Matrix (avoid unless necessary)
+Matrix reporting (e.g., engineer reports to EM + PM) creates accountability confusion. Avoid at < 500 people.
+
+---
+
+## Title Frameworks
+
+### The Problem with Title Inflation
+
+Early startups over-title to compete with cash. "VP of Engineering" with 2 reports. "Head of Marketing" with no team.
+
+**Consequences:**
+- Can't add leadership above inflated titles without awkward conversations
+- Candidates from mature companies expect scope commensurate with titles
+- Internal equity breaks when the same title means different things
+
+### Preventing Title Inflation
+
+**Rule 1:** VP titles require managing managers (not just ICs).
+**Rule 2:** Director titles require managing multiple ICs or a large function.
+**Rule 3:** No more than one "Head of X" per function.
+**Rule 4:** Document scope expectations per title before making offers.
+
+### Engineering Title Ladder (example)
+
+| Title | Level | Scope | Reports |
+|-------|-------|-------|---------|
+| Software Engineer I | L1 | Executes defined tasks | — |
+| Software Engineer II | L2 | Independent delivery | — |
+| Senior Software Engineer | L3 | Leads features, mentors | — |
+| Staff Software Engineer | L4 | Cross-team technical leadership | — |
+| Principal Software Engineer | L5 | Company-wide technical direction | — |
+| Distinguished Engineer | L6 | External recognition, defining practice | — |
+| Engineering Manager | M1 | Team of 4–8 engineers | 4–8 ICs |
+| Senior Engineering Manager | M2 | Larger team or manager of managers | 2–4 managers |
+| Director of Engineering | M3 | Functional area | Multiple managers |
+| VP of Engineering | M4 | Engineering org | Directors |
+| CTO | M5 | Technical organization + strategy | VPs |
+
+**IC vs. Management track:** Explicitly separate. Senior ICs should not need to move to management for career advancement. Staff/Principal/Distinguished track provides this.
+
+### Go-to-Market Title Ladder (example)
+
+| Title | Level | Focus |
+|-------|-------|-------|
+| SDR / BDR | S1 | Outbound prospecting |
+| Account Executive I | S2 | SMB closing |
+| Account Executive II | S3 | Mid-market closing |
+| Senior Account Executive | S4 | Enterprise closing |
+| Principal / Strategic AE | S5 | Named accounts, complex deals |
+| Sales Manager | M1 | 6–8 reps |
+| Director of Sales | M2 | Multiple teams or segments |
+| VP of Sales | M3 | Full sales org |
+| CRO | M4 | Revenue org (sales + CS + marketing) |
+
+---
+
+## Career Ladders
+
+A career ladder is a documented set of expectations per level. Not aspirational — behavioral. "What does a P3 engineer do that a P2 doesn't?"
+
+### Why career ladders matter for HR
+
+1. **Retention:** Employees can see where they're going
+2. **Consistency:** Managers use the same criteria for promotions
+3. **Compensation:** Bands anchor to levels; levels require definitions
+4. **Equity:** Removes "who's the manager's favorite" from promotion decisions
+
+### Career Ladder Structure
+
+For each level, define 4 dimensions:
+
+**1. Scope** — How big is the problem space? Team / cross-team / org-wide / company-wide?
+**2. Impact** — How does work connect to outcomes? (Task → Feature → Product → Business)
+**3. Craft** — Technical/functional skill expectations
+**4. Influence** — How does this person improve others? (Self → peers → team → org)
+
+**Example: Senior Software Engineer (L3) vs. Staff Software Engineer (L4)**
+
+| Dimension | L3 (Senior SWE) | L4 (Staff SWE) |
+|-----------|----------------|----------------|
+| Scope | Owns features or services | Owns technical domains across teams |
+| Impact | Ships features that improve user outcomes | Shapes technical direction for a product area |
+| Craft | Writes high-quality code, good design skills | Sets coding standards, contributes to architecture |
+| Influence | Mentors L1–L2, code reviews | Mentors L3+, identifies org-wide technical gaps |
+
+### How to build a career ladder from scratch
+
+1. **Interview your best performers** — "What do you do that your junior peers don't?" Collect behaviors, not aspirations.
+2. **Draft 3 levels** — Don't start with 6. Start with junior, mid, senior. Add staff/principal only when you have enough people to warrant it.
+3. **Manager calibration** — Every manager rates 5 current employees against the draft. Gaps surface immediately.
+4. **Publish and iterate** — Don't wait for perfection. A 70% ladder shipped is better than a 100% ladder in a drawer.
+
+---
+
+## Reorg Playbook
+
+### When reorgs are necessary
+- Strategy pivot requires different team structure (e.g., single product → multi-product)
+- Acquisition or team merger
+- Function is genuinely too slow due to coordination overhead
+- Leadership departure creates structural opportunity
+
+### When reorgs are a mistake
+- "We need to shake things up" (disruption for its own sake)
+- Avoiding a specific personnel decision (use the right tool)
+- Solving a cultural problem with a structural change
+- Reacting to one team's complaint without systemic evidence
+
+### Reorg Process (4–8 weeks)
+
+**Week 1–2: Diagnose**
+- Map current org: every role, reporting line, team output
+- Identify where work is slow, duplicated, or falling through cracks
+- Interview 5–10 people across teams: "What takes longer than it should? What decisions are hard to make?"
+
+**Week 3–4: Design options**
+- Draft 2–3 structural alternatives
+- For each: estimated coordination costs, manager span impact, open roles created
+- Validate with CEO + 1–2 trusted operators. Don't crowdsource the design.
+
+**Week 5–6: Decide and prepare**
+- Select option; finalize all reporting changes
+- Prepare communications for every affected person (individual conversations before all-hands)
+- Write the "why" — employees need to understand the business reason, not just the result
+
+**Week 7–8: Communicate and implement**
+- Individual conversations with all manager+ changes (first)
+- Team-level conversations with managers (second)
+- All-hands with full context (third)
+- Updated org chart published within 24 hours of announcement
+
+### Communication sequence (non-negotiable)
+
+1. Affected individuals first (private, before anything else)
+2. Affected managers second (to prepare for team conversations)
+3. Full team/company third (all-hands or company note)
+4. External (clients, board) only if materially impacted
+
+**Never:** Email blast first. No individual conversations. Discovered on the org chart.
+
+---
+
+## Founder → Professional Management Transition
+
+The most common scaling failure point in startups.
+
+### Stage 1: Founder-Led (0–30 people)
+
+Founders make all decisions, know everyone personally, set culture through behavior. Works because trust and context are built directly.
+
+**What breaks:**
+- Decisions bottleneck at founders
+- New hires don't get enough context (founders can't be everywhere)
+- Culture transmitted through osmosis, not documentation
+
+### Stage 2: First Managers (30–80 people)
+
+Founders can no longer manage all ICs. First manager layer typically = promoted high performers.
+
+**The "brilliant IC → struggling manager" trap:**
+- Individual contributor skills ≠ management skills
+- Promoted ICs often continue doing IC work while ignoring management work
+- No one holds them accountable to management output (1:1 quality, team health, performance feedback)
+
+**What to do:**
+- Explicit manager training before promotion (not after)
+- Management KPIs separate from IC KPIs
+- Peer community for new managers (monthly cohort session)
+- HR check-ins on manager health at 30/60/90 days
+
+### Stage 3: Professional Management (80–200 people)
+
+External hires at Director/VP level bring professional management skills but lack company context.
+
+**Common failure modes:**
+- Hired "too senior" — VP who's used to 200-person teams in a 50-person function
+- Culture clash — Big-company manager who adds process that kills startup speed
+- Authority vacuum — External VP doesn't earn trust; team ignores them; founder continues to bypass hierarchy
+
+**Mitigation:**
+- Hiring bar: Has this person scaled from this stage to 2x this stage before? Not managed a team at 2x — built a team to 2x.
+- Explicit onboarding on "how we make decisions here"
+- 90-day milestones focused on relationship-building before any structural changes
+- Founders explicitly hand off ownership and reinforce new manager's authority publicly
+
+### Stage 4: Founder Transition from Operator to Executive
+
+The hardest personal transition. Founder moves from doing to enabling.
+
+**Signs you haven't made the transition:**
+- You're still in every technical decision
+- Teams come to you instead of their manager for approvals
+- You know more about the team's work than the manager does
+- Managers feel they need to check in before acting
+
+**What the transition requires:**
+- Explicit authority delegation in writing (not just verbal)
+- Willingness to let managers make decisions you'd make differently
+- Redirecting team members to their manager consistently
+- Measuring managers on outcomes, not just process adherence
+- Letting managers hire and fire without founder override (except final call on VPs)