3 min read

After Reading: High Output Management

In reading the classic management book of the '90s
After Reading: High Output Management

I had been recommended this book by another Staff+ engineer at Shopify (after having been recommended this by many other leads in many other organizations over the years). He claimed that it had revitalized his daily task prioritization and his relationship to the calendar. I thought that sounded good.

And so when I spotted it on the shelf near the programming books I was browsing in the physical bookstore a month ago, bored of reading articles online, I picked it up.

I had a similar feeling, in reading this, to how I felt when reading How to Win Friends and Influence People a few years ago. It reads a bit like my great-uncle is talking to me: I really enjoy the stories and can feel the weight behind the person having carried them around and retold them time upon time again, but I take them with a grain of salt.

I do think there are some bits of this book that I'll think about day-to-day and pieces that will make me rethink my engineering process, but a lot of it I found I had already learned through years of managing teams myself. It, guiltily, felt good to have my own practices and given advice confirmed in a famous book, though. (Or were my practices taught to me by others who had read this book so many years ago!)

Passages and concepts I marked

Relating to the role of management

CEOs always act on leading indicators of good news, but only act on lagging indicators of bad news.

And it's our job, as non-CEOs, to act on leading indicators of bad news.

A common rule [...] is to detect and fix any problem in a production process at the lowest-value stage possible.

Big problems always start as small problems upstream.

And, consequently:

Inventory should be kept at the lowest-value stage possible

General comment: There is a lot of overlap in this writing and team/product guidance to the 'stocks and flows' described in Thinking in Systems. I should read that book again. I should read that book once a year.

Reports are more a medium of self-discipline than a way to communicate information. Writing the report is important; reading it often is not.

And thus I am writing these notes myself.

[...] productivity can be increased in three ways:
1. Increasing the rate [...] [of] activities
2. Increasing the leverage associated with the various [...] activities
3. Shifting the mix of [...] activities from those with lower to those with higher leverage.
delegation with out follow-through is abdication

And thus we find the 'Accountable' role in the RACI matrix.

Anyone who spends about a half day per week as a member of a planning, advisory, or coordinating group has the equivalent of a subordinate.

That equates to more than one 'meeting subordinate' for me.

The point is to impose a pattern on the way a manager copes with problems. To make something regular that was once irregular is a fundamental production principle, and that's how you should try to handle [...] interruptions [...]

Sounds like an echo of 'work to code'.

[...] two basic kinds of meetings:
process-oriented meeting, knowledge is shared and information is exchanged [...]
mission-oriented meeting, frequently producing a decision, set to solve a specific problem [...]

I have been categorizing things for a while as process or immersive work, and I think these mirror nicely.

Relating to managing individuals

managers do not talk to their subordinates about their problems but they know how to make the subordinates talk about theirs

General comment: In several places, the soft maximum of 6-8 members is drawn: in reports to a lead/manager, in people attending a decision-making meeting, etc.

the real sign of malorganization is when people spend more than 25% of their time in ad hoc mission-oriented meetings

This caused me to reflect on my year, and indeed I saw a correlation between mission-meeting and lack of clarity in the organization.

Task-relevant maturity

As a concept, this was nice to be given as a handle to discuss how I've been guiding projects to people in the past.

any decision [should] be worked out and reached at the lowest component level. [...] this is where it will be made by people who are the closest to the situation and know the most about it.

I can't help but see this mirror the advice earlier about keeping inventory at the lowest level and keeping problems low as well.

What decision needs to be made?
When?
Who will decide?
Who will need to be consulted prior to making the decision?
Who will ratify or veto the decision?
Who will need to be informed of the decision?

And the last four of those are the RACI matrix linked earlier.

Today's gap represents a failure of planning sometime in the past

Not of a failure to plan or act today. This is great to remember during Root Cause Analysis procedures and capacity limit conversations.