high-output-management

# High Output Management

Manage teams the way Andy Grove ran Intel: a manager's output is not what the manager does — it is what their organization produces. This skill turns *High Output Management* into auditable practice: production principles for knowledge work, output indicators, managerial leverage, meetings as the medium of management, clean decisions, OKRs, and a management style matched to task-relevant maturity.

## Core Principle

**A manager's output = the output of their organization + the output of the neighboring organizations under their influence.** Nothing a manager does — emails, meetings, reviews, decisions — counts in itself; it counts only through how it raises that combined output. Since managerial time is the scarce input, the craft reduces to one question asked relentlessly: of everything I could do right now, what creates the most output per hour spent? Choose high-leverage activities; eliminate negative-leverage ones.

## Scoring

**Goal: 10/10.** Rate management practices, calendars, and processes 0-10 against the principles below. State the current score and the specific changes needed to reach 10/10.

- **9-10:** Output indicators with quality pairs, subordinate-owned 1:1s on a TRM-based cadence, delegation with task-level monitoring, OKRs that stretch without driving pay, calendar built around forecasted key events
- **7-8:** Process meetings run well, but a few activity metrics, ad hoc decision meetings, or skipped training sessions remain
- **5-6:** 1:1s happen irregularly, indicators track busyness, delegation is all-or-nothing, planning produces documents instead of actions
- **3-4:** Management by interruption: status theater, decisions made by rank, reviews as annual surprises
- **0-2:** No 1:1s, no indicators, firefighting as the operating mode, output invisible and unmeasured

## Framework

### 1. Production Principles for Knowledge Work

**Core concept:** Grove's breakfast factory — deliver a three-minute egg, buttered toast, and hot coffee simultaneously, at acceptable quality and lowest cost — contains all of production: build the flow around the limiting step (the egg), fix problems at the lowest-value stage, batch where setup costs dominate, and choose deliberately between building to forecast and building to order. Every team — engineering, support, recruiting — runs a production line, whether or not anyone has drawn it.

**Why it works:** Knowledge work hides its assembly line, and invisible flow invites firefighting. Production thinking makes flow visible: once you know the limiting step, everything else gets scheduled around it; once defects are caught at the egg stage instead of on the customer's plate, fixing them costs a fraction.

**Key insights:**
- Build around the limiting step: find the longest, hardest, or most expensive stage and offset everything else from it — often code review, staging access, or one overloaded specialist
- Fix problems at the lowest-value stage: kill a flawed spec in review, not after three sprints of building on it
- Batch work with high setup cost — interviews, code reviews, interrupt handling — so the setup amortizes across the batch
- Most knowledge work is built to forecast, not to order: staff the pipeline to the forecast and accept controlled risk, as the toast goes down before the customer orders
- You cannot watch all the work: treat it as a black box and cut windows into it with a handful of indicators

**Applications:**

| Context | Application | Example |
|---------|-------------|---------|
| Sprint flow | Schedule around the limiting step | Review is the bottleneck → protect reviewer hours before starting new work |
| Quality gates | Inspect at the lowest-value stage | Spec review kills a flawed design before a three-week build |
| Hiring pipeline | Batch and build to forecast | Phone screens batched Tue/Thu; interviewer capacity staffed to the offer-date forecast |

**Ethical boundary:** Run systems hot, not humans — production thinking optimizes the work, never treats people as interchangeable machines.

See: [references/indicators-and-production.md](references/indicators-and-production.md) when finding a limiting step or building a dashboard — limiting-step analysis, worked indicator pairs, leading vs trend indicators, stagger charts, and how to run an operation review.

### 2. Indicators That Don't Lie

**Core concept:** Measure output, not activity — what the team shipped that survived, not how busy it looked. Pair every quantity indicator with a quality counterpart so neither can be optimized at the other's expense, favor leading indicators that buy time to act, and report forecasts in stagger charts that show how each forecast evolved.

**Why it works:** People do what management measures, so an unpaired indicator is an instruction to game it. The pair closes the loop: push throughput and the escape rate exposes the corner-cutting. Leading indicators and stagger charts convert measurement from autopsy to steering.

**Key insights:**
- Lines of code, hours logged, and tickets touched are activity; features alive in production and problems solved are output
- Pair quantity with quality: deploys/week with change-failure rate, ticket closes with reopens, velocity with incident count
- Leading indicators (review queue age, build flakiness, on-call page rate) warn before output drops; trend indicators compare output against your own history and forecast
- A stagger chart re-forecasts the same horizon every period; reading down a column shows whether forecasting is honest, optimistic, or sandbagged
- Administrative work measures like a factory: offers per recruiter-week, invoices processed per day — always with a quality pair

**Applications:**

| Context | Application | Example |
|---------|-------------|---------|
| Eng dashboard | Pair quantity with quality | Deploys/week paired with change-failure rate |
| Support ops | Output plus its quality shadow | Tickets resolved/day paired with reopen