Andy Grove's High Output Management

Recap of the High Output Management book

Florian Sauter

9 minute read

I finally managed to pick up some long standing items from my reading list over the holidays. Here’s a few notes from Andy Grove’s “High Output Management”. My expectations were set pretty high as the book was advertised by several people to me as the ultimate management bible. However, I have to admit that I was not completely blown away – maybe that’s a good sign though, as many of the key concepts probably have just made it into common management wisdom. So I guess that people who just started out into their management career might have more aha moments when reading the book.

Key concept: Managerial leverage

The book itself states the key take-away conveniently already in the introduction in a very clear way:

“The output of a manager is the output of the organizational units under his or her supervision or influence”

So the whole book makes a case about what a manager can do to increase the output of their teams. And having read Marty Cagan’s “INSPIRED”, I would argue that “output” here probably should have been replaced by “outcome” instead. But the message stays the same: How can managers make sure that they are engaging in those activities that have the most leverage on the productivity of their teams and organizations.

Basics: Indicators and metrics

To start off, Grove talks about picking the right indicators to measure the output/outcomes. While this topic could fill a book on its own, he has some handy tips:

  • Any measurement is better than none
  • Pairing of indicators makes sense: measure the thing, and measure the (possible) negative effect in parallel (e.g. stock levels & number of supply shortage events)
  • Try measuring the output, rather than the activity (pretty much in line with Cagan’s output vs. outcome discussion)
  • Come up with leading indicators wherever possible

High leverage management activities

The more meaty part of the book is spent on different ways to look a high leverage activities a manager should (or should not) engage in.

Work simplification

Fully understanding why things are done the way they are done is vital. Grove puts the idea out there that any process one takes a deeper look at can be made 30-50% more efficient in the first pass by questioning the why of every step and eliminating unnecessary activities.

Information gathering and nudging

Good judgment and good decision making depend on how well one comprehends the facts about a business. Interestingly, Grove emphasizes that the most up-to-date (and thus most relevant) information often comes from informal verbal exchanges, rather than written reports (according to Grove, writing reports is still an important task to force people into properly thinking about a topic; but the value is in writing reports, not so much in reading them).

Delegation

While delegation can be a high leverage activity, Grove points out some important caveats. Firstly, the “delegator” and the “delegatee” need to share a common base of information and a common understanding about how to go about solving certain problems. He points out that this is frequently no the case, and thus delegation does often no work as expected. Also, it needs to be clear that a manager is still responsible for the accomplishment of a task, even after they delegated it: Mangers needs to follow-through on the results of delegation. And the only way to achieve this is proper monitoring. Also, Grove recommends to delegate those kinds of activities that you know best (because monitoring and guidance is much easier to achieve). The frequency and diligence of monitoring results should depend on the task-related capabilities of the delegatee. Grove recommends to still go deep into detail now and then (just like samples taken at the end of a production line).

Decision making

Grove introduces an idealized decision making model, consisting of three steps: free discussion of a problem, clear decision, and full support of the decision (where support does not necessarily mean agreement). He also points out that finding decisions among peers can be especially hard as nobody wants to speak up early on with an opinion that might lose out in the end. He recommends to have the peer most affected by the decision to step up into a chairman role (or engage a more senior manager to take that role). It’s generally important to hear everyone’s opinions out and take some time for the discussion part to really get to the heart of the arguments (as in the beginning of a meeting often times there’s a lot of superficial comments made). But pushing for consensus after that (and, if that fails, ultimately making a clear decision) is equally important. He cites Alfred Sloan: “Group decisions do not always come easily. There is a strong temptation for the leading officers to make decisions themselves without the sometimes onerous process of discussion”

Managing by objectives

Again, this could probably fill a whole book on its own. Grove is convinced that MBO is a good method, and it especially helps in providing focus to everyone. He’s not so much concerned about the different between strategy and tactics of objectives (“this difference rarely matters in practice”). However, MBO only works well if the number of objectives is kept very small. And if nobody tries to game the system by sticking rigidly to what has been recorded as objectives and key results: “So it’s entirely possible for a subordinate to perform well and be rated well even though he missed his specified objective. (..) If the supervisor mechanically relies on the MBO system to evaluate his subordinate’s performance, or if the subordinate uses it rigidly and forgoes taking advantage of an emerging opportunity because it was not a specified objective or key result, then both are behaving in a petty and unprofessional fashion”

Negative leverage activities

There are also negative leverage activities. One that stands out is managerial meddling (micro management). The negative leverage comes from the fact that after being exposed to managerial meddling many times, “the subordinate will begin to take a much more restricted view of what is expected of him, showing less initiative in solving his own problems and referring them instead to his supervisor”.

A word on meetings

Meetings have a bad reputation. according to Grove, that’s not justified as they are “nothing less than a medium through with managerial work is performed”. So it’s not about getting rid of meetings, it’s making them as effective as possible.

Grove suggests to separate different kinds of meetings for best efficacy: - One on one meetings with subordinates: their frequency should depend on the task-related maturity of the subordinate. The content should be performance figures, indicators that signal trouble ahead, and potential problems. It should be the subordinate’s meeting, with the agenda and tone set by them. - Staff meetings: should include all subordinates. Contents should be anything that affects 2 or more people present. Ideal for decision-making. - Mission oriented meetings: They are different in that there is a clear objective and a chairman who makes sure the necessary decisions are made, recorded, and follow-up actions are taken

Hybrid organizations & Dual reporting

Most bigger organizations end up being a mix of mission-oriented and functional - a mix called “hybrid organization” in the book. For Grove, this seems to be the optimal form of organization: “no matter how many times we have examined possible organizational forms, we have always concluded that there is simply no alternative to the hybrid organizational structure”.

The one practice that make such organizations manageable is dual reporting, i.e. employees report into two manager: The first would specify how the job ought to be done, and the second would monitor how it was being performed day by day.

Individual and team performance

Grove draws some sports analogies, stating that a team will only perform as well as the individuals on the team. So the manager’s task is ultimately to make sure that each individual is at their peak performance. And there are two components to this: The individuals capability to perform (“skill”) and their motivation (“will”). This can be addressed with training on the skill level. The motivation however cannot be influenced directly – it has to come from within, so all a manager can do is to create an environment “in which motivated people flourish”.

The book draws an interesting link to Maslow’s pyramid of needs: Once a need is satisfied, it stops being a source of motivation. That is true for all needs except for one: the self-actualization need. So the wish to “become one’s personal best” (often referred to as “mastery” in engineering contexts) is the ultimate goal to instill, as it provides continuous motivation.

Management methods and task-relevant maturity

Another interesting insight is that there is no single “best” way to manage a subordinate. Indeed, it turned out from rotating managers within Intel that “neither the managers nor the groups [that have been rotated] maintain the characteristic of being either high-producing or low-producing as the managers are switched around. The inevitable conclusion is that high output is associated with a particular combination of certain managers and certain groups of workers”.

Grove concludes, that different management styles are needed depending on the task-related maturity of the subordinate for the task at hand:

  • Low maturity requires a more structured, task-oriented style (telling the what, when, how)
  • Medium maturity requires a style more oriented to the individual, supporting them, with mutual reasoning
  • High maturity requires only minimal involvement and it’s enough to establish objectives and monitor them

It’s important to state that neither of the approaches is good or bad. Especially a more structured (“tell”) style has a bad reputation, and is consequently only applied much tool late when things have good already overwhelmingly wrong - because personal preferences of managers for a more “minimal involvement” management style often override the objective need for a more structured approach.

Performance appraisals

Improving the individual’s performance is a high leverage activity as well, and improving the performance should be the solve purpose of a performance appraisal. A prerequisite is that the expectations towards a subordinate have been clearly articulated. And even then, the process is not objective by any means (because there simply is no way to assess performance in a knowledge worker environment objectively). As a guidance, the performance of a manager should be judged on both: his individual performance as well as the performance of their teams. And it’s important to only assess performance, not potential. Focusing on a few key points helps (“there is only so much a person can absorb at once”). And Grove recommends to deliver the written feedback before the face to face meeting, so people have a chance to digest it and react to with a clearer mind in a conversation.

Lastly, Grove reminds us that it’s worth to also focus on the improvement of those who already perform very well: investing into the “Stars” of the team is indeed a high-leverage activity, as they are the ones who reflect a lot of that back into the organizations and drive a lot of output.

A Philosophy of Software Design

Extracts from A Philosophy of Software Design

Florian Sauter

6 minute read

A colleague of mine pointed me to a book called “A Philosophy of Software Design” by John Ousterhout. It tackles a very interesting point: students of software engineering (and less so self-educated programmers) often times learn a lot about object orientation, algorithms and all kinds of funky theory, but there is very little time spent on practical software design. The preface of the book also raises the thought that this mystical difference in productivity between the best programmers and an average programmer is less likely just rooted in talent, but rather to high-quality practice than can be taught and learnt. Enough reason to take a peek into the book. Here’s my markups:

Core Hypothesis: It’s all about complexity

The author postulates that complexity is the core thing to focus on. The process of writing software is not limited to anything else than the ability to understand what one created. And as software grows, so grows its complexity - usually up to a point where it becomes hard for the engineers to keep all the relevant information in their mental memory. This is where things start getting slow, where bugs are creeping in, and the whole process goes into a downward spiral of more effort, less progress, more people needed to tackle it, even more complexity being created, and so on.

There are basically two methods to deal with complexity: 1. Avoiding complexity in the first place (e.g. by eliminating special cases) 2. Encapsulating complexity (e.g. dividing it into modules so one only needs to understand an interface, and not the whole implementation)

The book also points out that it’s important to be able to identify (unnecessary) complexity:

“The ability to recognize complexity is a crucial design skill. (..) It’s easier to tell whether a design is simple than it is to create a simple design.”

So, what exactly is complexity and how can we identify unnecessary complexity?

“Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system” (..) Complexity is more apparent to readers than writers. If you write a piece of code and it seems simple to you, but other people think it’s complex, then it’s complex.”

Three Symptoms of Complexity

  1. Change Amplification: This basically means that a simple change requires touching many different places in the code.
  2. Cognitive Load: How much does a developer need to know to properly modify a piece of code?
  3. Unknown unknowns: When it’s not obvious which parts of the code need to modified to achieve a certain outcome

Interesting, the book also concludes that the number of lines of code is hardly related to complexity. It’s generally true that very big systems tend to be complex, but often times solutions that require more lines of code are simpler than very concise notations that need to be deciphered first.

Tactical Programming vs. Strategic programming

Good design is declared to be a mindset question, with the two different mindsets of either tactical programming or strategic programming. The focus of tactical programming is to build something that works. The focus of strategic programming is to produce a great design that happens to work.

The author claims that a 10-20% additional upfront cost into a proper design is the sweet spot in terms of an return on investment. However, there is an interesting caveat to those who are not willing to even invest these 10-20%: “once a code base turns to spaghetti, it is nearly impossible to fix it. You will probably pay high development costs for the lifetime of your product.” – and have a competitive disadvantage quite early on.

Practical guidance on good software Design

The book dives into encapsulation / modularization here: “the best modules are those whose interfaces are much simpler than their implementations”.

So a few hands-on tips are:

  • Encapsulate powerful functionality and expose it through simple interfaces (“deep modules”, not “shallow modules”)
  • Avoid creating too many classes (especially you Java guys out there) - each of them needs in interface and the sheer number drives cognitive Load
  • Try building functionality you need today, but design the interface with multiple use-cases in mindset
  • Avoid “pass-through” methods that just call other methods and where the signature is bigger than the actual code
  • It’s more important for modules to have simple interfaces than a simple implementation
  • Don’t be afraid of big methods if that allows to read them easily (“In general, developers tend to break up methods too much”)
  • Design it twice: consider multiple options instead of jumping on your first idea
  • Documentation inside the code is essential to properly explain your abstractions (“without comments, you can’t hide complexity”)
  • Comments in the code should describe things that are not obvious from the code itself (“don’t repeat the code in comments” – add design decisions instead)
  • Good names are a form of documentation as well (“don’t settle on the first name that roughly describes the thing at hand” – they should be precise and consistent)
  • Whenever you change any code, try to improve the design at the same time (“if you’re not making the design better, you likely make it worse”)
  • Stick to conventions and try to never change them (“the benefit of consistency almost always outweighs the advantages of a change in conventions”)

Especially the Design it twice imperative resonated with me. I am also observing that developers in my surrounding tend to go for the first solution that pops into their mind. The author gives a very interesting explanation for that: He claims that smart people are conditioned to work this way through their experiences in school and life:

“I have noticed that the design-it-twice principle sometimes is hard for really smart people to embrace. When they are growing up, smart people discover that their first quick idea about any problem is sufficient for a good grade; there is no need to consider a second or third option. This makes it easy to develop bad work habits.”

The author rightfully points out that this strategy stops working if the problems become hard enough. And large scale software systems usually are part of that problem category. So there is a lot to gain from looking at at least two or three fundamentally different designs before starting off.

Comments are essential to good designs

The author claims that comments are essential and should be written upfront as part of the early design process of a class/interface. The core idea is to capture information in the Comments that is not obvious from the code, e.g. design intentions, design decisions, broader ideas, things to keep in mind when calling a method, etc. This makes it also clear that why it’s such a misconception that good code would be “self-documenting”.

Test driven development sets the wrong incentives

One of the more controversial (and thus more interesting) statements of the book is that test-driven development (TDD) is encouraging tactical programming more than strategic programming. It puts the focus on making specific features work, rather than finding the right design. That’s why the author discourages TDD, and only recommends using it when fixing specific bugs that can elegantly be reproduced in a test beforehand, so one can be sure to actually fix them with the change at hand.

The reward for developers

Investing in good software design creates upfront cost. But the cost is worth it for two reasons: - Engineers can spend more time in the design phase (which is actually the fun part of the job) - Engineers will spend less time hunting down bugs that stem from poor design, complicated and brittle code (which is the least fun part of the job)