Top Ideas in This Book
Although Grove’s output orientation may stem from his background in hardware, it also aligns with the reality that most software engineering managers today are assessed based on team output.
Grove also raises the importance of growing your managerial sphere of influence to include other teams and departments, saying you should also be judged based on that team’s output.
Imagine that each hour worked on a feature costs $40. Naturally you’d want to detect errors and fix issues earlier in the process in order to reduce rework cost. Identifying tactics is easy. Low fidelity designs, engineering kickoffs, pair programming, earlier code reviews, and automated testing are obvious ways to shift left on quality.
Fostering a culture that celebrates shifting left on quality is difficult but high leverage. That Grove defines managerial productivity as the ability to choose which tasks to perform based on their leverage.
Grove presents a decision tree for identifying the issue with any low performing employee. Do they have the skill to perform the job? If no, train them. If yes they have the right skills, then they must lack motivation. Alternatively, you could interpret this as a four quadrant matrix.
Grove writes thoughtfully about motivation and provides details of when monetary vs. non-monetary incentives work and don’t. I recommend pairing Grove’s advice with the notes on motivation from Peopleware.
Toward the end, Grove also includes a chapter describing employees as athletes and managers as coaches, reminding me of passages from both Wooden and Peak.
On performance Grove writes, “The single most important task of a manager is to elicit peak performance from his subordinates.”
This line really resonated with me: “My day always ends when I’m tired and ready to go home, not when I’m done. I am never done.”
That is the reality of people management – you are simply never done. Nobody tells you to go home. Your todo list is infinite. Manager problems are fuzzy with no clear definition of done.
You can always do more, which is why managers need to practice self control and moderation to avoid burnout.
Taking care of your team requires taking care of yourself.
How strongly do I recommend High Output Management?
9 / 10
I resisted High Output Management for two years. What could a 90s hardware guy teach me about managing software teams? Did you see what this guy is wearing?!
But when you read a lot, certain titles appear over and over. Everyone writing about engineering management references High Output Management and I’m happy that I read it.