High Output Management — Andy Grove's case that managing is a production problem, not a people problem

Andy Grove fled Hungary at 20, arrived in the United States speaking no English, worked his way through City College of New York, got a PhD in chemical engineering from UC Berkeley in 1963, and joined a semiconductor startup with eight employees called Fairchild. Six years later he was one of three co-founders of Intel. By the time High Output Management appeared in 1983, Grove had already led Intel through the transition from memory chips to microprocessors — a bet that probably saved the company — and had built it into a $1.9 billion enterprise. By the time he stepped down as CEO in 1998, that number was $26 billion. 1

The book Grove wrote in 1983 was not a memoir or a manifesto. It was a manual. The question he tried to answer was narrow and operational: what does a manager actually do that produces output? Not how does a manager feel, or what values should a manager hold — but what are the specific, repeatable activities that cause a team to generate more work of higher quality? Grove was a process engineer by training, and the book treats management accordingly: as a production system with inputs, transformations, outputs, leverage points, and failure modes.

The title, High Output Management, is accurate in a way most business book titles aren't. The book is about output. Not culture, not leadership presence, not psychological safety. Output — the measurable, deliverable results that a team produces.

The thesis: a manager's output is not what they do, it's what their team does

The intellectual spine of the book runs through a single equation Grove states in Chapter 3:

A manager's output = the output of their organization + the output of the neighboring organizations under their influence.

This formula is short and it takes a while to absorb. The implication is that a manager's personal activity — their individual work product, their to-do list, their hours — is not their output. Their output is what their team produces. A manager who writes brilliant code and whose team ships nothing has zero output. A manager who sits in meetings all day and whose team ships reliably has high output.

Grove builds on this to define what managers should actually spend time on: only activities that increase that team output. Everything else is overhead. He calls these activities managerial leverage and distinguishes them sharply from the manager's own "hands on" work (individual contributor work that feels productive but doesn't compound through the team).

Cedric Chin (Commoncog), who spent eight months reading one chapter per month and applying each before moving on, describes how transformative this reframe was in practice: "One of the most profound things I learnt near the start of my management journey was the idea that 'the manager's job is to increase the output of the team.'" 2 Chin applied the formula directly at his startup, building to S$4.5 million in revenue in two years "without ridiculous team scaling costs." His retained test: each week, ask "Have I increased or decreased the output of my team this past week? What may I do differently next week?" 2

The breakfast factory analogy that opens the book is Grove's scaffolding for this production-system model. He describes a simple operation producing a three-minute soft-boiled egg, toast, and coffee simultaneously for a customer who arrives in ten minutes. To do this at scale and reliably, you need to identify the limiting step — the constraint that determines the pace of the whole system. The egg takes the longest to cook, so it must start first. Every other task is scheduled backward from the egg.

Grove's point: before any manager starts scheduling, planning, or coordinating, they should identify the analogous limiting step in their team's production process. The rest of the work, and the meeting cadence, and the reporting structure, is all organized around not blocking that step.

The named frameworks

Managerial leverage

Grove's formal definition of leverage is the ratio of output produced to manager-hours invested. High-leverage activities include: training a team member (one hour of teaching can change how 200 hours of future work gets done); writing a decision memo that resolves ambiguity for a dozen parallel workstreams; running a meeting that simultaneously informs and aligns all the people who need to know the same thing. Low-leverage activities include: attending a meeting where your presence adds nothing, doing tasks your team can already do without you, and generating reports nobody reads.

The leverage framework has a practical corollary for PMs: the most valuable thing a PM often does is not roadmap prioritization or spec writing. It is making and communicating a decision clearly enough that six engineers, three designers, and two data analysts don't each resolve the ambiguity in a different direction. The meeting that establishes this takes one hour. The divergent work it prevents might take six weeks to discover and untangle.

1:1 meetings

Grove's chapter on 1:1 meetings is specific enough to be awkward for managers who have been running theirs as status check-ins. His definition: "The 1:1 meeting is the subordinate's meeting. Its agenda is set by the subordinate." 3

The purpose is not for the manager to receive a report. The purpose is to let the manager understand what is actually happening in the subordinate's work at a level of detail that would otherwise require the manager to micromanage everything. The subordinate's "management information" — problems, blockers, decisions pending, things they're uncertain about — surfaces in this meeting and only here. Grove's recommended cadence: roughly 1:1 per week for each direct report, with an ideal duration of around one hour.

GitLab, which has one of the most public statements of HOM's institutional influence, credits this format directly: its Handbook states that the 1:1 should be subordinate-driven with an ~1-hour format focused on teaching and information exchange. 4 The Handbook adds bluntly: "A lot of GitLab policies are directly from the book." 4

Task-Relevant Maturity (TRM)

This is the framework practitioners most consistently call out as immediately applicable. Grove's argument: the right management style for any given task depends on the subordinate's experience and judgment on that specific task, not their general seniority or capability. He calls this Task-Relevant Maturity.

The three positions:

Low TRM: subordinate is new to this type of work → manager should be highly structured, specific, and directive. Tell what, when, and how.
Medium TRM: subordinate has some relevant experience but not full judgment → manager coaches. Clear on what; the subordinate figures out how with guidance.
High TRM: subordinate has deep experience and good judgment on this task → manager sets goals and gets out of the way. Monitor outcomes, not process.

Task-Relevant Maturity management approach table showing Low, Medium, and High maturity with corresponding directive, coaching, and delegating management styles — Grove's TRM model mapped to management style, as summarized by Lighthouse. 5

The critical word in Grove's formulation is task-specific. A principal engineer with fifteen years of experience has high TRM on technical design and low TRM on giving performance feedback to a junior colleague. Treating them with the same management style across both would be wrong in both directions.

Ameet Ranadive (now CPO at GetYourGuide, former product leadership at Twitter and Instagram) applied this framework extensively in product management contexts, condensing Grove's logic into a "Skill/Will" shorthand. He emphasizes the distinction Grove makes between delegation and abdication: "Regardless of what the TRM may be, the manager should always monitor a subordinate's work closely enough to avoid surprises. The presence or absence of monitoring… is the difference between a supervisor's delegating a task and abdicating it." 6

Aaron Suggs, an engineering manager with experience at Lattice, Glossier, and Kickstarter, applied TRM in 2025 across six distinct task types in software teams: tech plan design, cross-functional collaboration, interviewing, team charters, personnel problems, and project execution. His report: "Grove's model served me well to effectively support teammates with low task-oriented maturity to grow new competencies, and to stay out of the way of those who already had expertise." 7

OKRs: the framework Grove built and didn't name

Grove created what we now call OKRs at Intel in the 1970s. He based them on Peter Drucker's 1954 Management by Objectives (MBO), with three specific departures: objectives are always paired with measurable key results (a pairing Grove treated as non-negotiable), the cycle is quarterly rather than annual, and the system is deliberately separated from compensation. 8

He called them iMBOs — Intel Management by Objectives. John Doerr, who learned the system directly from Grove as an Intel employee in the 1970s, later coined the name OKRs and carried them to Google in 1999, presenting them to Larry Page, Sergey Brin, and the rest of the founding team around a ping-pong table that doubled as a boardroom table. Google adopted them on a three-month trial. Five years later, Google went public. 8

Grove's framing in HOM distinguishes OKRs from the MBO pathology he saw in conventional management: "If the supervisor mechanically relies on the MBO system to evaluate his subordinate's performance, or if the subordinate forgoes taking advantage of an emerging opportunity because it was not a specified objective, then both are behaving in a petty fashion." 9

The distinction matters. Grove conceived OKRs as a learning system, not a performance management system. The goal was to clarify focus and surface misalignment. Compensation tied to OKR attainment was not the point — and Grove said so explicitly.

Training as a manager's core job

Chapter 16 of HOM, "Why Training is The Boss's Job," makes a claim most managers in 2026 still find uncomfortable: training subordinates is one of the highest-leverage activities a manager can perform, and most managers delegate it entirely or skip it. Grove's math: 12 hours preparing a four-lecture training for 10 subordinates, if it produces a 1% performance improvement in how those 10 people work across 20,000 annual work hours, yields 200 hours of recovered output. 10

This is the chapter that changed Ben Horowitz's career. As Director of Product Management at Netscape, Horowitz read it and wrote a training document called "Good Product Manager/Bad Product Manager." The results were immediate and specific: "The performance of my team instantly improved. Product managers that I previously thought were hopeless became effective. Pretty soon, I was managing the highest performing team in the company." 10 Horowitz made HOM mandatory at Loudcloud (later Opsware), wrote the 2015 foreword, and repeated the training leverage point across a16z's portfolio.

The Horowitz quote that best captures Grove's intent is blunt: "Being too busy to train is the moral equivalent of being too hungry to eat." 10

The most citable quotes

Grove wrote with the compression of a man who had no patience for hedging. Several lines in HOM function as standalone principles:

"It almost doesn't matter what you know. It's what you can do with whatever you know." 1

"A manager's output = the output of their organization + the output of the neighboring organizations under their influence."

"If the supervisor mechanically relies on the MBO system to evaluate his subordinate's performance, or if the subordinate forgoes taking advantage of an emerging opportunity because it was not a specified objective, then both are behaving in a petty fashion." 9

"Regardless of what the TRM may be, the manager should always monitor a subordinate's work closely enough to avoid surprises. The presence or absence of monitoring is the difference between a supervisor's delegating a task and abdicating it." 6

"Training is, quite simply, one of the highest-leverage activities a manager can perform." 10

All five of these are directly applicable to product management, and all five are direct quotes that hold up without context. Attributing them to Grove in a product review or team discussion is accurate — he coined these formulations.

Where HOM sits in the PM canon

The five books this series has covered so far address distinct layers of the product discipline:

Book	Core question	Layer
INSPIRED (Marty Cagan)	How should product teams organize to discover the right things to build?	Team structure + empowerment
Hooked (Nir Eyal)	How do you design products that people return to habitually?	Retention + behavior design
Don't Make Me Think (Steve Krug)	How do you build UIs that require zero mental effort?	Usability + cognitive load
The Mom Test (Rob Fitzpatrick)	How do you ask customers questions that produce honest answers?	Customer discovery + bias removal
High Output Management (Andy Grove)	How do you cause a team to produce more and better output?	Organizational leverage + execution

The shift from the previous four books to HOM is significant. The first four are all about what to build or how to validate it. HOM is about how to manage the people doing the building. It's the only book in the series focused on organizational machinery rather than product substance.

HOM directly supports and in some places pre-dates the frameworks in INSPIRED. Cagan's empowered product team model — where teams own problems and have the autonomy to find solutions — runs on the same reasoning as Grove's leverage formula. Cagan's critique of feature teams (teams that ship what they're told without owning outcomes) echoes Grove's argument that a manager who doesn't delegate real judgment to capable subordinates is operating below leverage. The books are in dialogue whether or not Cagan intended it.

The tension is with INSPIRED's positioning on OKRs. Cagan stopped recommending OKRs to most companies in 2020, after "many years of being a very vocal advocate for the OKR technique." His diagnosis: "You can't take your old organization based on feature teams, roadmaps and passive managers, then overlay a technique from a radically different culture, and expect that will work or change anything." 11 He isn't rejecting OKRs as a mechanism — he's saying the mechanism requires an organizational substrate (empowered product teams) that most companies don't have. This isn't a contradiction of Grove; it's an extension of Grove's same argument. Grove said the same thing in HOM: OKRs fail when used mechanically by managers who don't actually delegate judgment.

What practitioners say now

The principles don't transfer automatically

The most precise critique of HOM in the recent practitioner literature is Cedric Chin's 2022 essay "The Principles are Useless On Their Own." 2 Chin's argument: Grove and Ray Dalio both wrote "books about abstract concepts" in what Cognitive Flexibility Theory calls ill-structured domains — domains where applying a rule correctly requires judgment about context, and where the variability of real situations is high enough that top-down principle application rarely works. 12

Chin's evidence is his own experience: he spent eight months reading one chapter and applying it before moving on. Most people read the whole book in a week and find it doesn't stick. "It is very difficult to go top-down from abstract principles to effective action," he writes. 12 Grove's principles work when the reader has a rich library of management cases to anchor them to — the principles become shortcuts to already-understood situations. Without that library, they're vocabulary with no referents.

The OKR critique: not the framework, the incentive architecture

Frank Slootman (CEO of Snowflake, and previously ServiceNow and Data Domain) has eliminated MBO at every company he's joined over the past twenty years. His critique is structural: "MBO causes employees to act as if they are running their own show. Because they get compensated on their personal metrics, it's next to impossible to pull them off projects. They will start negotiating with you for relief. That's not alignment, that's every man for himself." 12

Slootman is a practicing CEO with a track record across three major tech companies. His objection isn't to measurement or to ambitious goals — it's to the incentive design that ties compensation to individual OKR attainment, which produces local optimization at the expense of coordination. His solution is a different kind of alignment system that relies on culture and hiring rather than metric architecture.

This is a real critique worth taking seriously. Grove in HOM was aware of the pathology Slootman describes — his "petty fashion" quote is precisely about managers who reduce OKRs to a compliance exercise and miss the point. But the book doesn't fully resolve the incentive architecture problem.

Andy Grove, Intel CEO and author of High Output Management, smiling, photographed circa 2009

Andy Grove, whose frameworks at Intel became the operational DNA for how Silicon Valley manages. Photo: Wikimedia Commons (CC).

The manufacturing metaphor as both strength and limitation

The breakfast factory analogy is simultaneously HOM's most cited concept and its most critiqued one. Software engineers and product managers independently flag the same issue: Grove's production-system model works cleanly for Intel's semiconductor fabs, where the output is a physical chip produced by a repeatable process. Software is different — most engineering work is done once, the complexity is new each time, and "process optimization" of the kind Grove describes can produce the exact wrong incentives in an environment where judgment and novelty matter more than throughput. 13

Simon Kozlov, a software engineer who reviewed the book in Russian: "Очень большой фокус на повторяемые процессы… И это все надо осторожно применять к миру софта, где все делается один раз и сложность при каждом подходе новая." (A very large focus on repeatable processes... All of this should be carefully applied to the world of software, where everything is done once and complexity is new each time.) 13 This is the main limit to import directly and without adaptation.

Phildini (2019) offers a more optimistic reading: the ideas Grove introduced have been so thoroughly absorbed into modern software management that they feel obvious forty years later. "As soon as I started reading it, I understood why it's so highly recommended in management circles: it's the best book on managing teams of people that I've read so far. It's so good, in fact, that some of the best ideas in it seemed obvious to me." 14 The ideas feeling obvious is the intended endgame — they've been internalized by the whole field.

The AI era challenge

The freshest critique is a February 2026 Substack series by Nadeem Hilal Wani, explicitly positioned as rebuilding Grove's management thinking for AI-augmented teams. Wani's argument: "The best management thinking ever written — Grove, Graham, Horowitz, Rabois, Lutke — was built for a world where the only variable was human effort. That world is gone." 15

His specific failure mode: teams using AI to generate code, documentation, and migrations without understanding what they're producing are "recreating the exact conditions of Chernobyl. Not in scale. But in structure. Confidence without comprehension. Output without understanding." 15

The proposed update: "AI gives you scale before you've earned understanding. That's not a feature. That's the trap." 16 Under Grove's original model, the limiting step was always human effort. A manager could increase output by removing blockers, improving training, and increasing leverage. If AI removes the throughput constraint on certain work, the limiting step becomes something else — probably judgment, taste, and strategic framing — and the managerial leverage calculation changes.

This critique doesn't invalidate Grove's framework. It applies it to a new set of inputs and asks which variables still hold.

When practitioners applied it: three cases

Ben Horowitz at Netscape. The most documented single application of HOM is Horowitz reading Chapter 16, writing a two-page training document, and watching his PM team transform. The causal mechanism: he trained his PMs on what good product management looked like before evaluating them, rather than evaluating and correcting. "I credit that investment with much of our eventual success." 10 At a16z, he now recommends HOM as foundational for every portfolio company founder. Dropbox's Drew Houston has called it "the bible of how do you scale an organization" across multiple interviews, including CNBC (2018) and Lenny's Newsletter (2025). 17

GitLab's fully public implementation. GitLab is the only major company with a publicly available line-by-line mapping of HOM concepts to internal policy. Specific adaptations include: 1:1 meetings as subordinate-driven with a written shared agenda; performance reviews as written documents shared before the meeting, with synchronous time reserved for questions only; individual KPIs cascaded from company OKRs using Grove's model. 4 The no-matrix organization decision — where GitLab consciously departed from Grove's dual-reporting model — is documented with reasoning. The GitLab Handbook reimburses employees who buy the book.

Cedric Chin's startup. Chin's case is the most methodologically rigorous because he was explicit about the experiment design: he applied each chapter before reading the next, used the output formula as his organizing principle, and tracked results. Revenue built to S$4.5 million in two years from a pivot, employee overtime dropped to one crunch period per year down from customer emergencies every few weeks, and retention improved. 2 He is also the most honest about the failure mode: he recommends HOM widely, and "it doesn't seem to result in demonstrably better outcomes for most of the people I recommend it to." 12 Slow application beats fast reading.

commoncog.com

링크 미리보기를 불러오는 중…

Five experiments to run this week

These derive directly from HOM's named frameworks. Each is designed to take under two hours and produce a usable result within your current team.

1. Map your week against the output formula. For each block on your calendar from the past five days, write down whether it increased your team's output, decreased it, or had no effect. Count the hours in each bucket. Grove's claim: most managers find they spend less than half their time on genuinely high-leverage activities. What you find in this audit tells you whether your schedule is optimized for your output or for other people's convenience.

2. Run a TRM assessment on your direct reports. For each person on your team, pick the three most important recurring tasks they own. Rate each task Low, Medium, or High TRM. Are you managing each task at the appropriate level of directiveness? A High TRM engineer on code review and a Low TRM engineer on incident response need different management styles — even if they're the same person. If your approach to everyone is the same regardless of task, Grove's framework suggests you're either micromanaging the capable or abandoning the inexperienced.

3. Audit your 1:1 meeting format. If you run 1:1s, print your agenda from the last three. Who set the agenda? If it was you, you've been running status check-ins, not 1:1s in Grove's sense. The next session, hand the agenda to your direct report with 24 hours' notice. What do they put on it? The delta between what they surface and what you would have asked about is exactly the information that's been missing from your management picture.

4. Calculate the leverage on one training investment. Pick one skill your team is inconsistently applying — a recurring judgment call, a process step that produces variable quality, a technical pattern that generates tech debt. Estimate: how many hours would one well-prepared training session take to prepare? How many people would attend? What percentage improvement in future work quality would a 1% lift in this skill produce? Do the math: (number of attendees × annual hours in this domain × 0.01) vs. prep hours. Grove's calculation almost always shows training paying back in under a month.

5. Write a decision memo this week. Identify the most consequential open question in your team's current work — a prioritization call, a design direction, a build-vs-buy decision. Write a one-page memo that states the decision, the options considered, the reasoning, and the outcome. Share it before you make the call. Measure: how many conversations does it eliminate? How many people align faster than they would have in a synchronous meeting? This is leverage in Grove's original sense — one manager hour producing output across multiple teams simultaneously.

Cover image: High Output Management, Vintage Books, 2015 edition with foreword by Ben Horowitz

High Output Management — Andy Grove's case that managing is a production problem, not a people problem

High Output Management — Andy Grove's case that managing is a production problem, not a people problem

The thesis: a manager's output is not what they do, it's what their team does

The named frameworks

Managerial leverage

1:1 meetings

Task-Relevant Maturity (TRM)

OKRs: the framework Grove built and didn't name

Training as a manager's core job

The most citable quotes

Where HOM sits in the PM canon

What practitioners say now

The principles don't transfer automatically

The OKR critique: not the framework, the incentive architecture

The manufacturing metaphor as both strength and limitation

The AI era challenge

When practitioners applied it: three cases

Five experiments to run this week

참고 출처