claude-skills-reference/c-level-advisor/chro-advisor/references/org_design.md

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)