Wednesday, June 6, 2018

Reading List: High Output Management

High Output Management by Andy Grove was first published in 1983, making it one of the earliest books about management in the technology industry and an influential book about management overall. I recently read the 2nd edition, revised in 2015.

Though the revisions help in updating the material, the book does still strongly resonate of the 1980s. Some of the examples concern Japanese DRAM manufacturers crowding out US firms, the rise of the PC industry, and the business climate of email beginning to replace telephone and memos. Nonetheless, management techniques change much more slowly than technology, and there is quite a bit of useful material in the book.

Some key takeaways for me:


 

Manager output = output of org + output of adjacent orgs under their influence

Grove’s point is that managers should be evaluated based on the performance of their own organization, plus the extent to which they influence the output of those who don’t directly report to them. This is especially important for knowledge leaders who provide technical direction for a large organization in particular areas, but without having large numbers of people reporting to them on the orgchart. The examples Grove uses are typically concerned with manufacturing and production, which was a particular strength and focus of his at Intel.

It is notable that 30+ years later, we’re still not very good at evaluating management performance in influencing adjacent organizations. Manager evaluations focus mostly on their direct reports, because that is more straightforward to judge. The incentives for managers are therefore to grow their org as large as possible, which isn’t always the best thing for the company even if it is the best thing for the manager.


 

Choose indicators carefully, and monitor them closely

It is important to monitor output, not just activity, or you’ll end up emphasizing busywork. An example Grove gives is a metric of the number of invoices processed by an internal team. That metric should be paired with a count of the number of errors produced. Any productivity metric needs to be paired with a quality measurement, to ensure that the team doesn’t feel incentivized to produce as much sloppy work as possible.

Even more importantly, the indicators need to be credible. If you won't act on them by taking big (and possibly expensive) steps, then all the monitoring will produce is anxiety. The business indicators need to be invested with sufficient faith to act when a new trend is clear, even if that trend has yet to percolate up in other, more visible, ways.


 

Management can usually be forecasted and scheduled

Though we will always deal with interruptions or emergencies or unexpected issues, a big portion of a manager’s job is predictable. You know how often you should have career discussions with team members, and when performance appraisals should be done, so put career discussions on the calendar a quarter before performance appraisals. You know when budgeting will be done, put milestone planning on the calendar two months before that.

For lull times between the scheduled activities, Grove recommends a backlog of manager tasks which need to be done but don’t have a hard deadline. This also nicely reduces the temptation to fill the lull periods by meddling in the work of subordinates.

I feel like this is something management as a profession has gotten better at since the book was initially written. Practices may vary across companies, but on the whole I feel like there is perhaps more structure for managers than the book implies from earlier times.


 

Now, a disagreement: technical half-life

Grove makes a point several times that technology changes quickly so the company needs to keep hiring younger workers straight out of university, where they will have learned the latest technology. As engineers become more senior they can move into leadership and management roles and leave the technology to those more recently graduated.

I find this not credible, for several reasons:

  • It assumes that technology work is 100% technical, that communications skills and leadership are entirely separate and can be supplied by those senior engineers who move into management roles.
  • There are far fewer managers than engineers. This idea takes it as given that universities should produce a large number of grads for corporations to chew through, and discard most of them in favor of fresh graduates. It seems like corporations could find a better use for their senior engineers than to discard most of them.
  • It implies that all of this new tech comes from somewhere else, perhaps from Universities themselves, and that senior engineers play no role in developing it.