High Output Management: Grove's Operating Manual for Managers Who Mean It

Andy Grove published High Output Management in 1983. He was Intel's president at the time, and the company he was running had just survived an existential crisis — a memory chip business that was getting undercut by Japanese manufacturers on cost. Grove was not writing a motivational book. He was writing down what he had learned about running a large, high-stakes organization without losing his mind or everyone else's time.

Four decades later, Brian Halligan, co-founder of HubSpot and a Sequoia partner, described the book's durability with some precision: "Almost all of us are running a derivative of the playbook laid out in Andy Grove's High Output Management book that has been lightly edited down through the generations."1 He said this to a room full of Sequoia founders — people who had, presumably, read everything. HOM was their shared baseline, not their starting point.

This article is a practitioner's close-read. It covers what Grove actually argues, which frameworks hold up in modern teams, where the book's manufacturing-era scaffolding needs to be stripped away, and what you can put into practice this week.

Andrew Grove (1936–2016) escaped Hungary at age 20 with nothing but a chemistry education, completed a PhD at UC Berkeley, and joined Intel as its third employee in 1968. He became president in 1979, CEO in 1987, and Time's Man of the Year in 1997 — during which time Intel grew from a scrappy startup to one of the most valuable companies on the planet. The decade he ran Intel is studied in business schools less for the strategy and more for the operational discipline: Grove's management system scaled a semiconductor company through multiple platform transitions that would have shattered looser organizations.

The book itself arrived between two versions of Intel. The first edition appeared while Intel was still a hardware manufacturer running physical factories. Ben Horowitz, co-founder of Andreessen Horowitz, wrote the foreword to the 2015 revised edition and described what made it different from the business books of its era: Grove wrote from inside operations, not from outside observation. His examples come from real manufacturing decisions with real cost consequences — which is both the book's greatest strength and, as we'll see, its most persistent critique.

Ian Tien, CEO and co-founder of Mattermost (the open-source messaging platform), worked as Grove's teaching assistant at Stanford and helped produce the 2015 edition. His verdict: "probably worth several million dollars in mistakes you'll avoid during your career."3 Tien now distributes his own chapter-by-chapter breakdown to managers at Mattermost as a reference: "Meetings wasting time? Chapter 4. Awkward performance reviews? Chapter 13. Star achiever underperforming? Chapter 12 & 15."3

Grove's argument begins with a deceptively simple equation:

This formula does more work than it appears to. It removes the most common management pathology at a stroke — the manager who is personally productive, visibly busy, and directly responsible for approximately nothing. Under Grove's definition, a manager who personally codes, writes, or designs has measured the wrong thing. Their metric is the collective output of the people and processes they influence. Everything else is individual contribution, which is a different job.

Grove calls the mechanism that drives this formula managerial leverage: the ratio between how much output a manager's action produces and the time that action consumes. Some managerial actions have high leverage — training a team of ten increases every future hour they work; writing a clear decision memo eliminates a week of follow-up confusion. Other actions have negative leverage: attending a meeting to hear updates that could have been written, or redoing a subordinate's work rather than coaching them to do it better.

The breakfast factory that opens the book — Grove walks through optimizing a three-minute egg operation with inventory buffers, throughput targets, and bottleneck analysis — is not decoration. It is Grove showing his hand. He believes management is a production function, and that its inputs, outputs, and constraint points can be identified and optimized just like a physical process. This framing is both his framework's greatest source of clarity and, for readers outside manufacturing, its most significant limitation.

The book spans 16 chapters and covers territory from meeting design to performance reviews to organizational structure. The frameworks below are the ones practitioners still report using without major modification.

Grove's leverage concept gives managers a concrete way to choose between competing demands on their time. A meeting that surfaces a quality problem early, before it propagates through the organization, has high leverage — it trades one hour against many. A manager who insists on approving every minor decision before it moves forward has negative leverage — their involvement slows output without improving it.

The practical application is not complicated: when deciding how to spend the next two hours, ask which action will produce the most output-per-minute of your time. Grove is explicit that this calculation should be done honestly and unsparingly. Managers who cannot answer it are operating on habit and availability, not on leverage.

Grove's chapter on 1-on-1 meetings is one of the book's most widely cited sections, and one of the least controversial among practitioners. His position is clear: the 1-on-1 is the subordinate's meeting, not the manager's. The agenda belongs to the person being managed. The manager's job is to listen, ask questions, and identify performance or environment issues that are not yet visible in formal reports.

The mechanism: by the time a problem shows up in metrics, it has often been brewing for weeks. The 1-on-1 is a real-time diagnostic — a chance to detect issues while they are still small enough to fix. Grove argues for at least an hour per session, held regularly enough that the subordinate knows they have a predictable channel.

Greg Skloot, whose management guide "How to be a Manager" was cited 1,600+ times on Hacker News, extends Grove's principle to written communication: "Updates should always be in writing, never in meetings."4 This directly echoes Grove's taxonomy of meetings — process-oriented meetings (scheduled, recurring, information-sharing) vs. mission-oriented meetings (convened to make a specific decision). The implication: if a meeting has no decision to make, it should be a document.

Grove devotes a full chapter to making the case that training is not HR's responsibility and is not optional. His arithmetic: if a manager spends 12 hours preparing and delivering training to a team of ten, and that training improves each person's output by 1%, the return is 200 hours of increased output from the initial 12-hour investment. No other single managerial action comes close to that leverage ratio.

Tien calls this explicitly "the highest leverage activity a manager can do."3 The point Grove is making goes deeper than time arithmetic: managers who treat training as someone else's problem are, in Grove's frame, failing their primary function. The excuse that a manager is "too busy" to train people is an inversion — it means they are spending time on low-leverage activities instead of the highest-leverage one.

GitLab institutionalizes this directly: CEO learning sessions on Grove's frameworks are part of the company's standard management development, delivered through handbook documentation and structured onboarding rather than informal osmosis.5

Task-relevant maturity is Grove's framework for diagnosing how much supervision a given person needs for a given task. The level of TRM is not a fixed property of the person — it is a function of the specific task. A senior engineer with ten years of backend experience has low TRM when asked to manage a team for the first time. An entry-level analyst may have high TRM for tasks they have done repeatedly.

The management implication is direct: the appropriate leadership style shifts with TRM. Low TRM → more directive, more structured guidance, more checking-in. High TRM → more delegation, more autonomy, less interference. The mistake is applying the same style regardless of TRM — micromanaging experienced people (destroys trust, wastes leverage) or under-managing inexperienced people on new tasks (produces errors that compound).

Grove's framework predates the more commonly cited Situational Leadership model, but the core logic is identical. Its continuing value is in the diagnostic step: most management style failures come from managers who have never explicitly asked "what is this person's TRM for this specific task right now?"

Grove's prescription for performance reviews is more specific than most managers implement. He argues for a written review delivered to the subordinate before the face-to-face discussion — not handed across the desk and read together in silence, but shared in advance so the person can read it, process it, and come to the meeting prepared.

The mechanism: the conversation that matters most in a performance review is the one where the subordinate responds honestly to what they have read. If they receive the review for the first time in the meeting, they spend the first ten minutes processing the emotional content, not engaging with it. The advance document turns the meeting from a verdict-delivery into a real dialogue.

GitLab has operationalized this for remote work: managers write a document before the meeting covering key points, areas of strength, development areas, and future plans; the direct report digests it first; the synchronous session handles only clarifying questions and genuine discussion.5 This is Grove's design, adapted for a distributed team.

The most detailed institutional case study of HOM in practice is GitLab's. Sid Sijbrandij, GitLab's co-founder, used the book explicitly as the blueprint when designing the company's management and people practices: "If there is one management book you should read, it is High Output Management. A lot of GitLab policies are directly from the book."5 GitLab operationalized six HOM frameworks at organizational scale — the output formula, OKRs cascaded from company to team to individual KPIs, subordinate-owned 1-on-1 agendas, TRM linked to emotional intelligence training, decision-making via a Directly Responsible Individual (DRI) model, and manager-as-trainer philosophy.5

They also made one conspicuous rejection: Grove's dual-reporting or matrix structure. GitLab maintains a no-matrix organization.5 This is the characteristic pattern of informed HOM adoption — selective rather than wholesale, with specific frameworks kept and specific ones discarded after deliberate evaluation.

On span of control, Grove recommends 6–8 direct reports for a largely supervisory manager. Emmanuel Goossaert, an engineering manager with over a decade at companies including Booking.com, adapts this to 4–8 for engineering managers who also write code

— budgeting roughly 2–3 hours per report per week rather than Grove's half-day, and preserving 50–60% of the week for technical work.6 He reports a real case from Booking.com where a Holacracy-style configuration with 25–35 direct reports per manager was tried across 2,500 employees — and reverted after about a year due to undetected team conflicts, superficial relationships, and performance reviews that relied entirely on second-hand information.6

On OKRs, the picture is more complicated. Grove developed the framework at Intel, evolving it from Peter Drucker's Management by Objectives (MBO, first described in The Practice of Management, 1954), compressing the review cycle from annual to quarterly and renaming it.7 The credit line "Grove invented OKRs" is historically imprecise: David Wilsey, CEO of the Balanced Scorecard Institute and co-author of The Institute Way, frames it as a "stake-your-claim" problem common in management consulting — incremental improvements to existing frameworks get branded as inventions.7 More practically: Goossaert argues that OKRs work when they are embedded in the culture that produced them (Intel, GitLab), and tend toward cargo-cult performance when organizations adopt the ritual without the context. The 2022 OKR Impact Report, he notes, relied almost entirely on how leadership and employees "feel" about strategic alignment — no empirical evidence on cost efficiency or profit impact.8

For remote and async teams, the adaptation pattern that holds across multiple practitioners is: push written communication as far as possible before scheduling synchronous time. GitLab's handbook states it directly: "Managers can be role models of our bias towards asynchronous communication by declining meetings in favor of async."5 This extends Grove's principle — that meetings should have a clear function as the right medium for specific work — into a context where the medium options are vastly wider than they were in 1983.

The criticisms of HOM are real and worth taking seriously before applying the book's frameworks to a modern team.

The breakfast factory metaphor never fully closes. The book opens with a detailed analysis of optimizing egg production and uses terms like "limiting step," "bottleneck," "in-process inventory," and "incoming inspection" throughout. These concepts translate cleanly to manufacturing and to processes with defined, repeatable units of output. They translate poorly to creative work, strategy, and software development — where, as one Goodreads reviewer noted, "everything is done once and the complexity is new each time."2 CatReader, writing in 2024, put it plainly: the breakfast factory model "fits better for a book about optimizing manufacturing lines, not a book about managing people."2 This is not a minor quibble about dated examples. The factory metaphor shapes how Grove frames all measurement — and applying it to knowledge work requires constant, conscious translation that the book does not do for you.

People show up as metrics, not as humans. Sam Stagg, a three-star reviewer on Goodreads, identifies what holds the book back as a reading experience: "Everyone in the book is a cipher, and every story which intends to add a splash of human colour merely underlines that Andy Grove doesn't appear to have had a massive amount of empathy for his colleagues."2 Grove sees people as a system variable to optimize. In 1983, this was ahead of the typical management literature. In 2026, it looks like a missing dimension. The book contains no framework for motivation, psychological safety, team trust, or the dynamics of creative collaboration. Managers who rely on HOM alone will have the leverage mechanics but not the full picture of what makes teams actually work well.

No dual-track career path. Yevgeniy Brikman, co-founder of Gruntwork and author of four books, identifies the structural assumption that underlies HOM: "This book comes from a world where management is a promotion from individual contributor (IC — a person who contributes directly rather than through managing others). There is no faster way to kill a tech org than to signal to your technical talent that individual contributions...are 'second class work.'"2 Modern tech organizations — including Google, where Distinguished Engineer is the rough IC equivalent of VP — are built on a dual-track career model that HOM simply does not address. If you manage engineers who may not want to manage, the book offers no framework for that conversation.

The meeting doctrine is 1983 vintage. Grove wrote that "two fundamental management tasks can only be done through person-to-person interaction, and therefore only through meetings." In 1983, the alternatives were memos and physical presence. Today they include asynchronous video, collaborative documents, persistent chat, internal wikis, and shared dashboards. Coleman McCormick, a technology practitioner and writer, observes that this specific claim "shows some age as we have so many more avenues for engagement today than in 1983, but his principle about fitting the work to the medium still holds."9 The principle survives; the specific prescription about meetings as the only medium for real management work does not.

The table below summarizes what practitioners consistently report:

These translate directly from the frameworks above. Each has a concrete starting action, a judgment call you will face, and what "done well" looks like.

1. Write down your leverage ratio for this week. Take every recurring commitment on your calendar — meetings, reviews, approvals, check-ins — and ask for each one: what output does this produce, and how much of my time does it consume? Anything where the output is information you could have received in a written update, and the time is more than 30 minutes, is a leverage-negative activity. You do not need to cancel it today; you need to see it clearly first. Done well: by Friday, you can point to one recurring obligation you are going to change — either shorten it, convert it to async, or stop attending it.

2. Return ownership of one 1-on-1 to your direct report. At the start of your next 1-on-1, tell them: "This is your meeting. I want you to come with an agenda of what you want to talk about — what's stuck, what you're thinking through, what you want my input on." The judgment call you'll face: they will probably be surprised, and the first session may feel thin. That is fine — it takes two or three sessions before people bring substantive agendas. Done well: within a month, your 1-on-1s are surfacing issues you would not have known about otherwise.

3. Put one training investment on your calendar. Identify one skill gap in your team that is showing up repeatedly in your work — a type of decision your people are consistently making poorly, a communication pattern that is creating friction, a technical area where they are slow. Block two to four hours to design or source a training on that specific gap. Run it in the next two weeks. The judgment call: "I don't have time" is the wrong answer — by Grove's leverage arithmetic, this is the highest-return thing you can do with those hours. Done well: someone on your team does something differently after the training, and you can point to the specific behavior change.

4. Calibrate your management style against TRM for each direct report. For each person you manage, pick one current project or responsibility and ask: is this task in their TRM zone of experience, or is this genuinely new for them? If it is new, how much structure and check-in frequency is appropriate — and is that what you are actually providing? The judgment call: the error most managers make is applying uniform style (either always hands-off or always directive) regardless of task novelty. Done well: you can describe specifically what changes about how you manage each person depending on whether they are in their TRM zone.

5. Send your next performance review document before the meeting. If you have a scheduled performance review or mid-year check-in in the next 30 days, write the document first and send it at least 48 hours before the meeting. Explicitly ask the person to read it before the session and come with their reactions. The judgment call: some managers resist this because they want to "control the reaction." That control instinct is exactly what this practice is meant to override — the goal is a real conversation, not a one-directional assessment. Done well: the meeting covers things you would not have reached if you had presented the review cold.