phildini.dev
Touring the Breakfast Factory: Thoughts on High Output Management
As I mentioned in my last post, I recently moved from being a Senior Software Engineer to a Team Lead. I’m fortunate to have received the advice early in my career that moving to management is less a promotion and more starting a new job; I immediately started looking for information on how to get better at this new job, fast.
I am doubly fortunate to know Jacob Kaplan-Moss, and to have come across his reading list for new engineering managers last year. As soon as I knew that I was heading towards a management path, I bought every book on his list, including Andrew S. Grove’s High Output Management.
One of my winter break goals was to get through as many books as possible, and High Output Management was at the top of the stack. 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.The ideas seem obvious because every company I’ve worked for has implemented some part of Grove’s ideas about management. They seem obvious because I have the advantage of living in a world that has had High Output Management in it for the past 30 years.
Take the idea of metrics and outcomes guiding a team. Every company I’ve worked for, especially in tech, has every team or department within it tracking metrics that get reported up the chain on a regular basis. As an engineer, this obsession with team metrics and trying to improve them can seem like a waste of time. “We feel good about the things we’re working on, why do we have to spend so much time quantifying them?”
The answer to this comes almost immediately in High Output Management: Every team is a black box to everyone not on the team, and the only way to know if a team is successful or not is to check the team’s metrics or see what they’ve shipped (which is itself another kind of metric). Thinking about metrics and outcomes in this way permanently changed my approach to teams. I started immediately looking at my team’s reporting metrics not as some arbitrary goal to hit, but as the only measure of the team’s health that most of the rest of the company would see.
Once you start thinking about metrics and outcomes in this way, if you’re like me you’re driven to make sure the metrics are real for your team. “Real” here means that the metrics actually line up with what the team AND the company care about, that your team can do something to affect the metrics, and that the members of the team are bought in to what the metrics represent. That last bit is especially crucial. Once your team knows why the metrics are important and agrees on what they should be, they can start making suggestions for how to improve them that might be better than the planned workstreams.
Speaking of outcomes and ideas that were popularized by High Output Management, let’s talk about OKRs. OKRs are an instance of the endless acronym parade that permeates Silicon Valley, and this one stands for “Objectives and Key Results”. Grove introduces this in talking about “management by objectives” (MBO, hooray another acronym), which is how every team I think I’ve ever been on has been managed without my ever knowing the term. “Objectives and Key Results” is an unfortunately jargon-heavy way to express an idea that I actually love, namely “Here’s where we think we’re going, and here’s how we’ll know if we’re going in the right direction.”
A trivial example. Say I want to get from my house in Alameda to my favorite taco place in Oakland, Xolo. “Get to Xolo” is my objective. There’s a myriad of ways I could check how close I am, and each one of those is a potential key result. I could carefully measure the odometer (metrics based), or I could know that I’m about a quarter of the way there when I hit the dog park, halfway there when I hit the tunnel, and roughly three-quarters of the way there when I turn on 12th st (milestone based). Take this simple idea and expand it to what your team or company cares about, and hopefully some of the chaos of running a team doesn’t just get a little bit clearer.
“Making things clearer over time” could be a subtitle for the book, in fact. Grove lays out his material in such a way that every chapter has at least one idea I found immediately useful, although the later chapters on performance evaluation and especially hiring feel a touch outdated. This is the disadvantage of reading such a seminal book 30 years after it’s publication — Grove’s ideas were so good we adopted many of them and kept iterating!
After reading High Output Management, I’m doubly indebted to Jacob KM and the others who recommended it to me. Once, because it gave me more tools in my management toolbox. Twice, because I know have an iron-clad recommendation for anyone who asks “what books should I read about being a manager?”. Grove’s book is near the top of that list.
Have you read High Output Management? Think I’m wrong in some of my thinking on it, or want to talk about strategies from the book that worked for you? Drop a note in the comments.