{
  "schema_version": 1,
  "skill_name": "operational-design",
  "evals": [
    {"id":"bottleneck-pilot","prompt":"A support workflow misses its 24-hour SLA. Design an improvement decision.","expected_output":"A current-state map identifies the bottleneck, compares reversible options, sets an owner, KPI, control, pilot, and stop rule.","assertions":["Maps handoffs and identifies a bottleneck","Compares simplification, staffing, vendor, or automation options","Defines owner, KPI, control, and escalation path","Uses a bounded reversible pilot","Sets measurable success and rollback criteria"]},
    {"id":"kpi-scorecard","prompt":"Build an operating scorecard for a growing service team.","expected_output":"A scorecard defines leading and lagging measures with formulas, owners, cadence, targets, and interpretation rules.","assertions":["Includes both leading and lagging indicators","Defines formulas, source, owner, and review cadence","Connects measures to service and quality outcomes","States assumptions and target rationale","Defines action thresholds rather than reporting numbers alone"]},
    {"id":"vendor-selection","prompt":"Select a vendor for a business-critical workflow with sensitive data.","expected_output":"A weighted vendor decision includes requirements, evidence, SLA and control gates, total cost assumptions, fallback, and review cadence.","assertions":["Defines weighted requirements and evidence","Evaluates SLA, security, privacy, and operational controls","Includes total-cost assumptions and a budget guardrail","Defines fallback and escalation paths","Records decision owner and review cadence"]},
    {"id":"compliance-controls","prompt":"Prepare an operations roadmap for SOC 2 readiness.","expected_output":"A control matrix maps risks to owners, evidence, test cadence, exceptions, and remediation sequence without treating certification as one-time work.","assertions":["Maps risks to preventive or detective controls","Names owners and evidence sources","Defines testing cadence and exception handling","Sequences remediation by risk and effort","Includes continuous monitoring and review"]},
    {"id":"scale-operating-model","prompt":"Our company is growing from 40 to 120 people. What operating model changes should we test?","expected_output":"A scaling decision compares topology, delegation, communication, and capacity options with measurable pilot outcomes.","assertions":["Identifies discontinuities between current and next scale","Compares topology and delegation options","Defines decision rights and accountability","Uses capacity and communication measures","Routes people design to org-design and delivery work to implementation-planning"]}
  ]
}

# Compliance and Audit Frameworks

Compliance is a system, not a project. It requires embedded controls, continuous monitoring, and periodic testing. The frameworks below cover the most common compliance regimes for SaaS and technology companies.

## SOC 2

SOC 2 (System and Organization Controls 2) is the most common compliance framework for SaaS companies. It reports on controls related to security, availability, processing integrity, confidentiality, and privacy.

### Trust Services Criteria (TSC)

| Category | Criteria | What It Covers |
|----------|----------|---------------|
| **Security** | CC1-CC9 | The system is protected against unauthorized access. The foundational criteria that everyone must meet. |
| **Availability** | A1 | The system is available for operation and use as committed or agreed. |
| **Processing Integrity** | PI1 | System processing is complete, valid, accurate, timely, and authorized. |
| **Confidentiality** | C1 | Information designated as confidential is protected. |
| **Privacy** | P1-P4 | Personal information is collected, used, retained, disclosed, and disposed in conformity with commitments. |

### SOC 2 Report Types

| Type | Description | When to Get It |
|------|-------------|----------------|
| **Type I** | Controls are designed properly at a point in time | First audit, getting started |
| **Type II** | Controls operated effectively over a period (typically 6-12 months) | Customer demands, vendor due diligence |

### Key Controls by Domain

**Security (CC1-CC9):**
- Access control policy and enforcement
- Logical access reviews (quarterly)
- Change management process
- Incident response plan and testing
- Vendor risk management
- Encryption at rest and in transit
- Physical security (office/data center)
- Monitoring and alerting
- Background checks
- Security awareness training

**Availability (A1):**
- Uptime SLAs and monitoring
- Business continuity / disaster recovery plan
- Backup and restore testing
- Capacity planning

**Processing Integrity (PI1):**
- Input validation controls
- Error handling and corrective action
- Batch job monitoring

**Confidentiality (C1):**
- Data classification policy
- Access restrictions on confidential data
- Data retention and disposal

### SOC 2 Readiness Checklist

| Phase | Activities | Timeline |
|-------|-----------|----------|
| **Scoping** | Define system boundaries, identify in-scope services and data | 2-4 weeks |
| **Risk Assessment** | Identify risks to TSC criteria, document control objectives | 2-4 weeks |
| **Control Design** | Document existing controls, design new controls for gaps | 4-8 weeks |
| **Control Implementation** | Build and deploy controls, update policies | 4-12 weeks |
| **Evidence Collection** | Run controls, collect audit evidence | 3-6 months (Type II) |
| **Audit** | External auditor reviews controls and evidence | 4-8 weeks |

---

## ISO 27001

An international standard for Information Security Management Systems (ISMS). Broader than SOC 2 — requires a management system, not just controls.

### The ISO 27001 Approach

| Component | Description |
|-----------|-------------|
| **ISMS** | A systematic approach to managing sensitive information |
| **Annex A Controls** | 93 controls across 4 domains (organizational, people, physical, technological) |
| **PDCA Cycle** | Plan-Do-Check-Act continuous improvement |
| **Risk Assessment** | Risk-based approach — controls are selected based on risk, not checklist |
| **Statement of Applicability** | Which Annex A controls apply and why |

### ISO 27001 vs SOC 2

| Dimension | SOC 2 | ISO 27001 |
|-----------|-------|-----------|
| Focus | Controls effectiveness | Management system |
| Flexibility | Fixed TSC criteria | Risk-based, choose your controls |
| Certification | Auditor's opinion letter | Certificate issued |
| Recognition | US-focused | International |
| Renewal | Annual | Three-year certification + surveillance audits |

### Key Requirements

1. **ISMS Scope** — What's included and excluded, with justification
2. **Information Security Policy** — Top-level policy, reviewed annually
3. **Risk Assessment** — Systematic risk assessment methodology
4. **Risk Treatment Plan** — How risks will be addressed
5. **Internal Audit** — Regular internal audits of the ISMS
6. **Management Review** — Top management reviews ISMS performance
7. **Continuous Improvement** — Non-conformities are tracked and resolved

---

## GDPR Readiness

The General Data Protection Regulation governs how personal data of EU residents is handled, regardless of where the company is based.

### Key Principles

| Principle | Requirement |
|-----------|-------------|
| **Lawfulness, fairness, transparency** | Legal basis for processing, clear privacy notices |
| **Purpose limitation** | Data collected for specified, explicit purposes only |
| **Data minimization** | Collect only what's necessary |
| **Accuracy** | Keep data accurate and up to date |
| **Storage limitation** | Delete data when no longer needed |
| **Integrity and confidentiality** | Appropriate security measures |
| **Accountability** | Demonstrate compliance (documentation, DPO, records) |

### Data Subject Rights

| Right | Description | Response Time |
|-------|-------------|---------------|
| **Right to be informed** | Privacy notice at collection point | At collection |
| **Right of access** | Individuals can request their data | 30 days |
| **Right to rectification** | Correct inaccurate data | 30 days |
| **Right to erasure** ("Right to be forgotten") | Delete personal data | 30 days |
| **Right to restrict processing** | Limit how data is used | 30 days |
| **Right to data portability** | Export data in machine-readable format | 30 days |
| **Right to object** | Opt out of processing (including marketing) | At any time |
| **Rights related to automated decision-making** | Explanation of algo-based decisions | Upon request |

### GDPR Compliance Roadmap

| Phase | Activities | Timeline |
|-------|-----------|----------|
| **Discovery** | Data mapping, identify all personal data processing | 4-8 weeks |
| **Gap Analysis** | Current state vs GDPR requirements | 2-4 weeks |
| **Remediation** | Update policies, implement controls, update contracts | 8-16 weeks |
| **Implementation** | DPO appointment, privacy notices, consent management | 4-8 weeks |
| **Ongoing** | DSAR handling process, breach notification procedure, annual review | Continuous |

### GDPR Breach Notification

```
Under GDPR, a breach must be reported to the supervisory authority
within 72 hours of becoming aware of it.

If the breach is likely to result in high risk to individuals,
they must also be informed without undue delay.
```

---

## Common Compliance Pitfalls

| Pitfall | Symptom | Fix |
|---------|---------|-----|
| **Compliance once, not continuous** | Controls atrophy between audits | Build continuous monitoring, automate evidence collection |
| **Documentation but not implementation** | Policies exist but aren't followed | Test controls, not just documentation |
| **Scope creep** | Trying to cover everything at once | Start narrow, expand scope over time |
| **No executive ownership** | Compliance is delegated to IT without business support | Assign executive sponsor, report compliance at board level |
| **Vendor blind spot** | Vendors have access to your data but no compliance validation | Vendor risk management program, contract reviews |
| **Over-relying on automation** | Tools replace thinking | Automation supports controls, doesn't replace judgment |

### Evidence Collection Strategy

| Evidence Type | Examples | Collection Method |
|---------------|----------|-------------------|
| **System logs** | Access logs, change logs, audit trails | Automated log aggregation |
| **Configuration** | IAM policies, encryption settings | Infrastructure-as-code, CI/CD |
| **Process artifacts** | Signed forms, approved change requests | Document management system |
| **Training records** | Completed security training | LMS reports |
| **Review evidence** | Access review sign-offs | Quarterly automated workflow |
| **Testing results** | Penetration test reports, DR test results | Scheduled external testing |

# Operational Design Decision Workflow

Use this workflow to choose a process, control, metric, or vendor operating model; route technical implementation elsewhere.

## Repeatable Method

1. **Frame inputs:** customer/value outcome, current workflow, volume and variability, owners, constraints, failure modes, service level, compliance obligations, and baseline measures.
2. **Map and compare:** capture handoffs and queues, identify the bottleneck, compare simplification, staffing, vendor, and automation options, and state assumptions.
3. **Decide with gates:** select an operating model only with a named accountable owner, measurable KPI, control, escalation path, capacity/cost guardrail, and review cadence.
4. **Validate:** pilot the smallest reversible change, compare throughput/quality/lead time and control exceptions to baseline, then scale or rollback.
5. **Package evidence:** retain current/future map, RACI, KPI definitions, vendor scorecard or control matrix, decision log, and review date in an artifact pyramid.

## Worked Example

A support process misses its 24-hour SLA. Mapping shows a vendor handoff queue is the constraint. The decision is to add a triage owner and vendor escalation tier for 30 days, not automate first. Success requires 95% first response within 24 hours, fewer than 2% reopens, and zero critical control exceptions; the weekly review either scales the model or reverts it.

## Reusable Artifact

```text
Operating model decision record
Outcome / process boundary / owner / date / review date
Baseline (volume, lead time, quality, cost):
Bottleneck and failure modes:
Options, assumptions, and evidence:
Decision / RACI / KPI and control:
Capacity, cost, SLA, and escalation guardrails:
Pilot, stop rule, result, and next action:
```

## Routing Matrix

| Need | Route to | Handoff in / out |
|---|---|---|
| Strategic priority | [strategy-frameworks](../../strategy-frameworks/SKILL.md) | Operating constraint in; priority choice out |
| Cost or unit economics | [financial-modeling](../../financial-modeling/SKILL.md) | Volume/cost assumptions in; scenario model out |
| Technology/vendor feasibility | [technology-radar](../../technology-radar/SKILL.md) | Capability need in; evaluated option out |
| Delivery work breakdown | [implementation-planning](../../implementation-planning/SKILL.md) | Approved model in; sequenced work out |
| Evidence structure | [artifact-pyramids](../../artifact-pyramids/SKILL.md) | Maps and measures in; indexed evidence out |
| Team topology or role design | [org-design](../../org-design/SKILL.md) | Capacity/role constraint in; people design out |

Do not create an operations sibling for a narrow tool or department: use the named tool owner or existing methodology and preserve this boundary.

# Operational Metrics

Metrics are how you know whether the operation is performing as designed. The right metrics create alignment. The wrong metrics drive the wrong behavior.

## KPI Design Framework

### Good KPIs vs Bad KPIs

| Good KPI | Bad KPI |
|----------|---------|
| Specific and measurable | Vague ("improve quality") |
| Actionable — can be influenced | Purely informative ("stock price") |
| Owner assigned | No one responsible |
| Tied to a target or threshold | No context for good/bad |
| Leading or lagging with clear relationship | Random measures without connection |
| Few in number (5-7 per department) | Too many to focus on |

### The KPI Hierarchy

**Level 1: Company North Star (1-2 metrics)**
The single metric that best captures whether the company is succeeding. Everything else supports this.

**Level 2: Departmental KPIs (3-5 per department)**
What each department must achieve to support the North Star.

**Level 3: Team/Individual Metrics (3-5 per team)**
What teams and individuals can directly influence.

**Level 4: Process Metrics (as needed)**
Real-time operational measures that feed into Level 3.

### KPI Template

```
Name: [Metric name]
Formula: [How it's calculated]
Frequency: [Daily, weekly, monthly]
Owner: [Who is accountable]
Target: [Good, acceptable, critical thresholds]
Data source: [Where the data comes from]
Lag/Lead: [Leading or lagging indicator]
```

---

## Leading vs Lagging Indicators

| Type | Definition | Examples | When to Use |
|------|-----------|----------|-------------|
| **Lagging** | Measures outcomes after they happen | Revenue, profit, churn, NPS | Strategic review, board reporting |
| **Leading** | Predicts future outcomes | Pipeline creation, demo requests, activation rate | Operational management, early warning |

### Leading Indicators by Function

| Function | Lagging Indicator | Leading Indicator |
|----------|------------------|-------------------|
| **Sales** | Revenue closed | Pipeline created, demo-to-close ratio, win rate |
| **Marketing** | Leads generated | Website traffic, content engagement, conversion rate |
| **Product** | Feature adoption | Time to value, activation rate, session frequency |
| **Engineering** | System uptime | Deployment quality, alert volume, WIP limits |
| **Support** | Customer satisfaction | First response time, resolution time, ticket volume trend |
| **HR** | Attrition rate | Engagement survey score, promotion readiness, time-to-hire |

### The Lead-Lag Chain

Build a causal model connecting leading indicators to lagging outcomes:

```
More demos (lead) → Higher pipeline (lead) → More closed deals (lag) → Revenue growth (lag)
Faster time to value (lead) → Higher activation (lead) → Lower churn (lag) → Higher LTV (lag)
Faster deployment frequency (lead) → Shorter lead time (lead) → Lower change failure rate (lag) → Higher uptime (lag)
```

---

## Balanced Scorecard

A strategic planning and management system that goes beyond financial metrics to include customer, process, and learning perspectives.

### The Four Perspectives

| Perspective | Question | Typical Metrics |
|-------------|----------|-----------------|
| **Financial** | How do we look to shareholders? | Revenue growth, profitability, ROIC, cash flow |
| **Customer** | How do customers see us? | NPS, retention, satisfaction, time to value |
| **Internal Process** | What must we excel at? | Quality, cycle time, cost, throughput |
| **Learning & Growth** | Can we continue to improve? | Employee engagement, skill development, innovation pipeline |

### Building a Balanced Scorecard

1. **Define the strategy.** What is the organization's strategic objective for the next 12-24 months?
2. **Identify 3-5 objectives per perspective.** What must happen in each perspective to achieve the strategy?
3. **Define 1-2 measures per objective.** How will you know the objective is being achieved?
4. **Set targets.** What does good look like? What's the stretch target?
5. **Identify initiatives.** What projects or programs drive movement on these measures?

### Scorecard Example (SaaS Company)

| Perspective | Objective | Measure | Target | Initiative |
|-------------|-----------|---------|--------|------------|
| Financial | Grow recurring revenue | ARR growth rate | 40% YoY | Sales team expansion |
| Financial | Improve efficiency | Rule of 40 | ≥ 40% | Cost optimization program |
| Customer | Improve retention | Net Revenue Retention | ≥ 120% | Customer success automation |
| Customer | Shorten time to value | Days to first activation | < 7 days | Onboarding redesign |
| Internal | Improve delivery speed | Lead time for changes | < 1 day | CI/CD pipeline investment |
| Internal | Ensure quality | Change failure rate | < 5% | Automated testing increase |
| Learning | Develop leadership | Internal promotion rate | 40%+ | Leadership development program |
| Learning | Improve engagement | eNPS score | > 50 | Engagement action planning |

---

## Designing Operational Dashboards

### Dashboard Layers

| Layer | Audience | Refresh | Content |
|-------|----------|---------|---------|
| **Strategic** | Executives | Monthly | North Star, high-level KPIs, trend lines |
| **Tactical** | Department heads | Weekly | Departmental KPIs, variance vs plan, top issues |
| **Operational** | Team leads, ICs | Daily | Process metrics, queues, real-time status |

### Dashboard Design Principles

1. **One page, one purpose.** Don't try to serve everyone with one dashboard. Create separate views for different audiences.
2. **Show the target.** A metric without a target is just a number. Show the actual vs target and the direction.
3. **Trend over time.** A single number is meaningless without context. Show at least the last 12 periods.
4. **Highlight exceptions.** The dashboard should surface what needs attention, not just report what's normal.
5. **Limit to 7-10 metrics per view.** More than that and the dashboard becomes noise.
6. **Label everything.** Metric name, unit, frequency, owner. If someone can't understand the dashboard without asking, it's not done.

### Common Dashboard Anti-Patterns

- **Vanity metrics.** "Total registered users" sounds impressive but tells you nothing about health. Use active users, cohort retention, and conversion rates instead.
- **Data puking.** 50 charts on one page. More data is not more insight. Edit ruthlessly.
- **No drill-down.** The dashboard shows revenue is down. Can you click to see by product line? By region? By segment? Layer in drill-down capability.
- **Stale data.** A dashboard that's updated monthly for operational use is misleading. Match refresh frequency to decision frequency.
- **Automated but unowned.** Every metric needs a human owner. If a number goes red, someone should know who to call.

# Process Design

Frameworks for understanding, documenting, and improving business processes. Process design is the foundation of operational excellence — you cannot improve what you haven't mapped.

## Value Stream Mapping (VSM)

A lean-management technique for analyzing the flow of materials and information required to deliver a product or service to a customer.

### Standard VSM Elements

| Symbol | Name | Meaning |
|--------|------|---------|
| □ | Process box | A process step (department, system, person) |
| ▼ | Inventory | Work-in-progress between steps |
| → | Push arrow | Material moves without pull signal |
| ☰ | Information flow | Communication (manual or electronic) |
| ⚡ | Kaizen burst | Improvement opportunity identified |
| ⏰ | Timeline | Value-added vs non-value-added time |

### Building a Current-State VSM

1. **Define the product/service.** What's the specific product, order, or request you're mapping?
2. **Walk the process.** Physically follow the work from start to finish. Don't map from memory.
3. **Map process steps.** Each major step is a process box. Include wait states and handoffs.
4. **Collect data for each step:**
   - Cycle time (time to complete the step)
   - Changeover time (time to switch between types)
   - Uptime / reliability
   - First-pass yield (% of work done right first time)
   - Number of operators
5. **Map information flow.** How does each step know what to do? Email? System? Verbal?
6. **Add the timeline.** Calculate value-added time vs total lead time.

### Value-Added vs Non-Value-Added

| Category | Definition | Examples |
|----------|-----------|----------|
| **Value-Added (VA)** | Changes the product/service in a way the customer cares about and pays for | Manufacturing, code development, customer consultation |
| **Business Non-Value-Added (BNVA)** | Required by regulation or business policy but not valued by customer | Compliance checks, reporting, approvals |
| **Non-Value-Added (NVA)** | Pure waste. Customer would not pay for this. | Rework, waiting, handoffs, unnecessary steps |

### The Efficiency Metric

```
Process Cycle Efficiency = Total Value-Added Time / Total Lead Time
```

| Efficiency | Classification |
|------------|---------------|
| > 25% | Excellent. Lean process. |
| 10-25% | Good. Room for improvement. |
| 5-10% | Typical for most organizations. Significant waste. |
| < 5% | High waste environment. Major opportunity. |

---

## BPMN (Business Process Model and Notation)

A standardized notation for process modeling. Use BPMN when you need formal, unambiguous process documentation.

### Core Elements

| Element | Notation | Meaning |
|---------|----------|---------|
| Event | Circle | Something that happens (start, end, timer, message) |
| Activity | Rounded rectangle | Work performed (task, subprocess) |
| Gateway | Diamond | Decision point (XOR, AND, OR) |
| Sequence Flow | Solid arrow | Order of activities |
| Message Flow | Dashed arrow | Communication between participants |
| Pool | Large rectangle | A participant in the process |
| Lane | Nested section within a pool | Role or department within a participant |

### Gateway Types

| Gateway | Logic | Visual | Use When |
|---------|-------|--------|----------|
| **XOR (Exclusive)** | Exactly one path | Standard diamond | Yes/No decisions, routing |
| **AND (Parallel)** | All paths execute | Diamond with + | Tasks can happen simultaneously |
| **OR (Inclusive)** | One or more paths | Diamond with O | Multiple conditions may be true |

---

## Bottleneck Analysis

In any process, the slowest step determines the throughput of the entire system. Bottleneck analysis identifies that step.

### Theory of Constraints (Goldratt)

1. **Identify** the constraint (the bottleneck). The step with the smallest capacity or longest cycle time.
2. **Exploit** the constraint. Maximize the bottleneck's throughput. Don't let it wait.
3. **Subordinate** everything else. Non-bottleneck steps should operate at the bottleneck's pace, not at their own maximum.
4. **Elevate** the constraint. If exploitation isn't enough, invest in increasing the bottleneck's capacity.
5. **Repeat.** Once the bottleneck is resolved, a new bottleneck appears. Start over.

### Finding the Bottleneck

| Method | How | Best For |
|--------|-----|----------|
| **Walk the process** | Stand where the work is. Where is the pile of work-in-progress largest? | Quick assessment, small processes |
| **Capacity analysis** | Calculate maximum throughput of each step. Lowest = bottleneck. | Manufacturing, transactional |
| **Cycle time analysis** | Measure actual time per step. Longest = bottleneck. | Knowledge work, services |
| **Queues** | Where is the longest queue? The step before the queue is the bottleneck. | All processes |

### Bottleneck Anti-Patterns

- **Optimizing non-bottlenecks.** Improving a step that isn't the bottleneck increases capacity overall by 0%. It just creates more work-in-progress queued at the bottleneck.
- **Keeping the bottleneck idle.** Lunch breaks, meetings, training. If the bottleneck stops, the whole system loses throughput. Protect the bottleneck's time.
- **Ignoring variability.** A step may not look like the bottleneck on average, but if its variability is high, it causes intermittent bottlenecks.

---

## Workflow Optimization Patterns

### The Seven Wastes (TIMWOOD)

| Waste | Description | Example in Knowledge Work |
|-------|-------------|--------------------------|
| **T**ransportation | Unnecessary movement of work | Multiple handoffs between teams |
| **I**nventory | Excess work-in-progress | Too many open tickets |
| **M**otion | Unnecessary movement of people | Context switching, finding information |
| **W**aiting | Idle time between steps | Approval queues, review backlogs |
| **O**ver-processing | Doing more than needed | Excessive documentation, over-engineering |
| **O**ver-production | Doing work before it's needed | Building features without demand |
| **D**efects | Errors requiring rework | Bugs, miscommunication, incorrect data |

### Process Improvement Heuristics

| Heuristic | When to Apply | Expected Impact |
|-----------|--------------|-----------------|
| Eliminate handoffs | Process has 5+ handoffs | High — each handoff adds delay and error |
| Parallelize independent steps | Sequential steps that don't depend on each other | Medium-High — reduces lead time significantly |
| Move decisions earlier | Late-stage approvals cause rework | High — fail fast, not late |
| Automate verification | Manual checking is slow and inconsistent | Medium — improves consistency more than speed |
| Standardize exceptions | The same exception gets handled differently every time | High — reduces cognitive load and error |
| Batch size reduction | Large batches increase lead time and variability | Medium — smoother flow, faster feedback |
| Remove sign-off layers | 3+ approvals for routine decisions | High — approvals are delays, not quality |

### Measuring Improvement

| Metric | Pre-optimization | Post-optimization | Target |
|--------|-----------------|-------------------|--------|
| Lead time (end-to-end) | | | |
| Value-added time | | | |
| First-pass yield | | | |
| Handoff count | | | |
| Approval steps | | | |
| Rework rate | | | |
| Cost per transaction | | | |

# Scaling Frameworks

Organizational scaling is a discontinuous function. The operating model that works at 10 people breaks at 50. The model that works at 50 breaks at 200. Each stage requires deliberate redesign.

## The Scaling Stages

### Stage 1: Founding (1-10 People)

**Operating model:** Direct communication. Everyone knows everything. CEO makes most decisions.

**What works:**
- All-hands meetings, everyone talks to everyone
- CEO approves all hires and major decisions
- Informal processes, no documentation needed
- Generalists preferred over specialists

**What breaks:**
- Informal communication becomes unreliable
- CEO becomes bottleneck for decisions
- "Everyone does everything" leads to dropped balls
- Hiring starts to need structure (interview process, offer letters)

**Transition trigger:** CEO can no longer attend every meeting or review every decision. Typically at 8-15 people.

### Stage 2: The Team Phase (10-50 People)

**Operating model:** Functional teams with managers. CEO manages via team leads.

**What changes:**
- Department heads appointed (Engineering, Sales, Marketing)
- Weekly staff meetings with department leads
- Basic processes emerge (hiring, expense approval, customer support)
- First specialist hires (marketing, HR, finance)

**New challenges:**
- Communication across teams becomes a problem
- CEO is still in most decisions but now through team leads
- Hiring needs process (standardized interviews, offer approval)
- First performance management issues arise

**Transition trigger:** Team leads can't keep up with coordination. Cross-team projects fail due to poor communication. Typically at 40-60 people.

### Stage 3: The Department Phase (50-200 People)

**Operating model:** Functional departments with VP-level leaders. CEO manages the executive team.

**What changes:**
- VPs hired for each department
- Weekly exec team meeting, monthly all-hands
- Formal processes for hiring, budgeting, performance reviews
- Middle management layer added
- First attempt at OKRs or similar goal-setting

**New challenges:**
- Silos emerge between departments
- "Over the wall" syndrome — Engineering blames Sales, Sales blames Product
- Decision-making slows as more stakeholders are involved
- Culture dilution — new hires don't know the old ways
- First major process debt — too many processes or not enough

**Transition trigger:** Cross-functional coordination becomes the primary bottleneck. Silos prevent strategic initiatives. Typically at 150-250 people.

### Stage 4: The Enterprise Phase (200-1,000+ People)

**Operating model:** Business units or divisions with P&L responsibility. CEO manages business unit leaders.

**What changes:**
- Business units with their own P&L
- Shared services (IT, HR, Finance, Legal) as centralized functions
- Formal governance (board meetings, committee structure)
- Strategic planning process (annual + quarterly)
- Professional management systems (compensation bands, leveling, career frameworks)

**New challenges:**
- Maintaining startup culture at scale
- Bureaucracy and process bloat
- Innovation atrophies — everything requires a business case
- Talent density dilutes — average performers become the norm
- Coordination costs dominate operating expenses

**Survival strategies:**
- Break into autonomous units when possible
- Maintain small-team dynamics within units
- Invest in internal mobility and talent development
- Fight process creep actively — sunset unnecessary processes

---

## Delegation Patterns at Scale

### The Delegation Progression

| Stage | CEO Decisions | Delegated | Mechanisms |
|-------|--------------|-----------|------------|
| 1-10 | All major decisions | Minimal | Direct assign |
| 10-50 | Strategy, hiring, budget, product | Execution | Department leads |
| 50-200 | Strategy, exec hiring, major budget | Operations, product | VP delegation, OKRs |
| 200-1000 | Strategy, capital allocation, culture | Almost everything | Business unit P&L, governance |

### Scaling the Span of Control

| Level | Direct Reports | Notes |
|-------|---------------|-------|
| First-line manager | 4-8 | Direct contributors |
| Director/V-Level | 4-6 | Manager of managers |
| C-Suite | 4-8 | Direct reports and functional leaders |
| CEO (early) | 4-6 | Direct reports |
| CEO (scale) | 8-12 | Including functional heads |

### Span of Control Heuristics
- Technical ICs need more attention → smaller spans (4-6)
- Experienced managers → larger spans (6-10)
- Autonomous/empowered teams → larger spans
- New managers → smaller spans (3-4), grow over time

---

## Organizational Design Patterns

### Functional Structure

Pro: Deep expertise, clear career paths, efficient resource use
Con: Silos, slow cross-functional decisions, customer-blind
Best for: 10-200 person companies, stable markets

### Divisional/BU Structure

Pro: Customer-focused, fast decisions within unit, clear P&L ownership
Con: Duplication of resources, coordination across units is hard
Best for: 200+ person companies, multiple products/markets

### Matrix Structure

Pro: Combines functional expertise with project focus
Con: Dual reporting is confusing, slow decisions, "two bosses" problem
Best for: Project-based organizations (consulting, construction)

### Team Topologies (Conway's Law Applied)

Designed to align team structure with communication needs:

| Team Type | Purpose | Size | Interactions |
|-----------|---------|------|--------------|
| **Stream-aligned** | Owns a full value stream (feature, service, product area) | 6-8 | Collaborates with enabling teams |
| **Enabling** | Helps stream-aligned teams learn and adopt new capabilities | 4-6 | Collaborates, facilitates |
| **Complicated-subsystem** | Owns a domain that requires deep specialized knowledge | 4-8 | Provides, X-as-a-Service |
| **Platform** | Builds internal products that other teams use | 6-10 | Provides, X-as-a-Service |

---

## Conway's Law Applied

> "Organizations design systems that mirror their communication structure."

### The Principle

If you have 3 teams that need to coordinate to ship a feature, the system will have 3 components that need to coordinate to work. The architecture reflects the org chart.

**Implications:**
- To change the architecture, first change the team structure
- A microservices architecture requires a team structure that supports autonomous services
- A monolith is fine if the team is a monolith (small, colocated)

### Inverse Conway Maneuver

Restructure teams to match the desired architecture, then let the architecture follow.

1. Define the target architecture (e.g., 3 services: payments, inventory, orders)
2. Create 3 stream-aligned teams, each owning one service
3. The architecture will naturally converge on the target because teams can independently deliver

**Risk:** If the architecture isn't right, you've locked in a bad design. Test the architecture hypothesis before restructuring.

---

## Dunbar's Number

150 is the theoretical maximum number of stable social relationships a human can maintain.

### Applications to Organizational Design

| Number | Social Dynamic | Organizational Implication |
|--------|---------------|---------------------------|
| 5 | Intimate team | Everyone knows everyone deeply. Full trust. |
| 15 | Band | Can maintain shared context without process. |
| 50 | Tribe | Need some structure. Most people know most people. |
| 150 | Clan | Dunbar's number. Start of anonymity. Need formal systems. |
| 500 | Crowd | Cannot know everyone. Need full management hierarchy. |

### Practical Rules

- **Keep teams under 10** (preferably 6-8)
- **Keep departments under 150** — once a department exceeds 150, split it
- **All-hands becomes impractical > 150** — use cascading communication
- **Culture is carried by the 150 core** — the first 150 employees define the culture. After that, culture must be actively managed through systems and stories.

# Vendor Management

Vendors are partners, not transactions. A well-managed vendor relationship reduces risk, improves service quality, and creates leverage for cost negotiations.

## RFP Process

Request for Proposal (RFP) is a structured process for evaluating vendor options. Use RFPs for significant investments where comparison across multiple vendors is needed.

### RFP Lifecycle

1. **Requirements Definition** — What must the vendor do? What's nice-to-have?
2. **Vendor Shortlist** — 3-5 vendors who can meet requirements
3. **RFP Issuance** — Formal document sent to shortlisted vendors
4. **Vendor Q&A** — Clarify questions, ensure all vendors have same information
5. **Proposal Evaluation** — Score proposals against weighted criteria
6. **Vendor Demos / POCs** — Shortlisted vendors demonstrate capability
7. **Reference Calls** — Check with existing customers
8. **Negotiation & Selection** — Final terms and selection

### RFP Template

```
1. Executive Summary
   - Project overview, timeline, budget range

2. Company Background
   - About us, our needs, current state

3. Scope of Work
   - Detailed requirements (must-have, should-have, nice-to-have)
   - Deliverables, milestones, success criteria

4. Vendor Qualification Requirements
   - Company size, experience, certifications
   - Security and compliance (SOC 2, ISO 27001, GDPR)
   - References required

5. Commercial Terms
   - Pricing model requested (per seat, flat, usage-based)
   - Contract term, SLA requirements
   - Payment terms

6. Submission Requirements
   - Format, deadline, point of contact
   - Questions for vendor to answer

7. Evaluation Criteria
   - How proposals will be scored
   - Weight for each dimension
```

### RFP Evaluation Matrix

| Criterion | Weight | Vendor A | Vendor B | Vendor C |
|-----------|--------|----------|----------|----------|
| Functional fit | 25% | | | |
| Technical architecture | 15% | | | |
| Security & compliance | 15% | | | |
| Total cost (3-year TCO) | 20% | | | |
| Support & service | 10% | | | |
| Company stability | 10% | | | |
| References | 5% | | | |
| **Total** | **100%** | | | |

### RFP Anti-Patterns

- **RFPs for commodity purchases.** An RFP for a $500/month email tool wastes everyone's time. Use RFPs for significant, strategic decisions.
- **Too many vendors.** Evaluating 10 vendors comprehensively is unrealistic. Limit to 3-5.
- **Unequal information.** One vendor gets a question answered, others don't. Share Q&A with all vendors equally.
- **Death by requirements.** A 200-item requirements list buries the important ones. Distinguish must-have from nice-to-have.

---

## SLA Design

Service Level Agreements define what the vendor guarantees and what happens if they fail.

### SLA Components

| Component | Definition | Example |
|-----------|-----------|---------|
| **Service Definition** | What exactly is covered | "Core platform API availability" |
| **Uptime Commitment** | % of time service is available | 99.9% uptime (excluding planned maintenance) |
| **Measurement Period** | How availability is calculated | Monthly average, quarterly true-up |
| **Exclusions** | What's not covered | Scheduled maintenance, force majeure, customer-side issues |
| **Credits** | Penalty for missed SLA | 5% credit per 0.1% below target, max 25% |

### Credit Structure

| Uptime % | Credit (Typical) |
|----------|------------------|
| 99.9-100% | No credit |
| 99.0-99.9% | 5% of monthly fee |
| 95.0-99.0% | 10% of monthly fee |
| < 95.0% | 25% of monthly fee + termination rights |

### Beyond Uptime: Multi-Dimensional SLAs

| Dimension | Definition | Typical Target |
|-----------|-----------|---------------|
| **Availability** | Service is accessible | 99.9% (standard), 99.99% (critical) |
| **Performance** | Response times within threshold | P95 < 500ms |
| **Support response** | Time to first response | Critical: < 1hr, High: < 4hrs, Normal: < 24hrs |
| **Support resolution** | Time to resolution | Critical: < 4hrs, High: < 8hrs, Normal: < 5 days |

### SLA Pitfalls

- **Measuring what's easy, not what matters.** Dashboard uptime is easy to measure. API latency at P95, data freshness, and error rates matter more.
- **No measurement transparency.** If you can't independently verify uptime, the SLA is unenforceable. Require a status page and monthly reports.
- **Credits that don't hurt.** A 5% credit on a $1K/month contract is $50. That's not enough to incentivize performance.
- **Ignoring the exit.** If SLA violations accumulate, there should be a termination-for-cause clause with a data migration assistance obligation.

---

## Vendor Scorecards

Scorecards provide ongoing evaluation of vendor performance. They should be reviewed quarterly and factored into renewal decisions.

### Scorecard Template

| Category | Weight | Metric | Target | Actual | Score |
|----------|--------|--------|--------|--------|-------|
| **Service Quality** | 25% | Uptime SLA | 99.9% | | |
| | | Response time (P95) | < 500ms | | |
| **Support** | 20% | P1 response time | < 1hr | | |
| | | Ticket satisfaction | > 4.0/5.0 | | |
| **Security** | 15% | SOC 2 valid | Yes | | |
| | | Pen test results | No critical findings | | |
| **Value** | 20% | Cost variance vs budget | < 5% | | |
| | | Feature delivery vs roadmap | On track | | |
| **Relationship** | 10% | Executive engagement | Quarterly | | |
| | | Escalation responsiveness | < 24hrs | | |

### Vendor Tiering

| Tier | Criticality | Management Cadence | Exit Plan |
|------|-------------|-------------------|-----------|
| **Tier 1: Strategic** | Core to business operations | Monthly review, quarterly business review, annual contract | Maintained, updated semi-annually |
| **Tier 2: Important** | Significant but replaceable | Quarterly performance review | Maintained, reviewed annually |
| **Tier 3: Operational** | Useful but non-critical | Annual review | Documented, not maintained as active plan |
| **Tier 4: Commodity** | Easily replaceable | Monitor via SOW | No formal exit plan needed |

### Vendor Scorecard Pitfalls

- **No consequence for poor scores.** If a vendor consistently scores low but keeps the contract, the scorecard is theater. Tie scorecards to renewal decisions.
- **Annual review cadence for everyone.** Annual review is too infrequent for critical vendors and too frequent for commodity vendors. Match cadence to criticality.
- **Scoring without conversation.** Don't just send the scorecard. Review it with the vendor. Their response to the data is as informative as the data itself.

---

## Vendor Management Heuristics

| Heuristic | Why |
|-----------|-----|
| **Never be a vendor's only customer.** | If they go under, you're stranded. |
| **Always have an exit plan.** | The cost of switching is highest when you can't switch. Know the exit cost before you sign. |
| **Data portability is non-negotiable.** | Ensure you can export your data in a standard format at any time. |
| **Negotiate the renewal before signing.** | Know the renewal process and escalation structure. A vendor that's helpful during sales may be adversarial during renewal. |
| **Vendor concentration is risk.** | If one vendor accounts for > 30% of a capability, you have concentration risk. Identify alternatives. |
| **The cheapest option is rarely the cheapest.** | Hidden costs (integration, training, workarounds) make cheap vendors expensive. Calculate real TCO. |
| **Multi-year contracts need price protection.** | Lock in pricing or maximum annual increases. Without protection, you're at the vendor's pricing mercy. |