High Performance Organizations Reading List(github.com)
github.com
High Performance Organizations Reading List
https://github.com/pdfernhout/High-Performance-Organizations-Reading-List
42 comments
As someone who is literally starting an IT department from scratch, this is a really exciting list for me to dig into. There are old favorites like 'mythical man month' that I'm generally aware of, though never actually read personally, and whole new blogs and videos to sift through. Thanks for this.
Great resource thanks for sharing. Lots of titles and resources that I have never considered. Super useful :)
Everyday Astronaut's walk and talk with Elon Musk where he attempts to explain his management process, starts at 13:30 of part 1: https://www.youtube.com/watch?v=t705r8ICkRw&t=13m30s
Here's a rough summary:
1. Make requirements less dumb.
2. Delete part or process steps. If you're not occasionally adding things back (he says 10%) (ideally in improved versions), you're not removing things often enough.
3. Simplify, optimize, solve. Everyone's trained to jump to this because the educational process requires you to answer a question as posed, when often the question is dumb and shouldn't be dealt with as-stated.
4. Accelerate process
5. Automate
Those tend to blur together at the edges. I'm sure if he formalized this and wrote it down for mass consumption it'd be presented differently, but it's his current mental model.
Process testing - remove unnecessary in-process testing after production line debugging is done. Obviously there are nuances, he's not saying to do no in-process testing, but rather to remove testing which was intended to reveal information once that's already been collected and addressed. He cautions about false positives from in-process testing, and notes most testing can be done end of line with acceptable results.
Finally, it's important to understand the context. The part about part/step deletion in particular, when things get added back 10% of the time, is not appropriate for all development processes. That would have to be adjusted a the specific product and market objective.
Here's a rough summary:
1. Make requirements less dumb.
2. Delete part or process steps. If you're not occasionally adding things back (he says 10%) (ideally in improved versions), you're not removing things often enough.
3. Simplify, optimize, solve. Everyone's trained to jump to this because the educational process requires you to answer a question as posed, when often the question is dumb and shouldn't be dealt with as-stated.
4. Accelerate process
5. Automate
Those tend to blur together at the edges. I'm sure if he formalized this and wrote it down for mass consumption it'd be presented differently, but it's his current mental model.
Process testing - remove unnecessary in-process testing after production line debugging is done. Obviously there are nuances, he's not saying to do no in-process testing, but rather to remove testing which was intended to reveal information once that's already been collected and addressed. He cautions about false positives from in-process testing, and notes most testing can be done end of line with acceptable results.
Finally, it's important to understand the context. The part about part/step deletion in particular, when things get added back 10% of the time, is not appropriate for all development processes. That would have to be adjusted a the specific product and market objective.
Also note the things mentioned by him that happen kind of before/in parallel, i.e. costing and planning.
Building high performance organizations really often is about the "mundane" stuff:
- Planning processes
- Assigning responsibility and putting incentives in place
- Clear objectives with good KPIs
Building high performance organizations really often is about the "mundane" stuff:
- Planning processes
- Assigning responsibility and putting incentives in place
- Clear objectives with good KPIs
That was so good I transcribed/transliterated it for my team:
Elon Musk’s Five Steps to Optimize:
- Question the Requirements - Delete Parts or Processes - Simplify - Accelerate - Automate
Quotes:
You want everyone to be a chief engineer. So, “everyone is a chief engineer” means that people need to understand the system at a high level to know when they are making a bad optimization. Like when we put immense effort into reducing engine mass but hardly any effort into reducing propellant residuals.
All designs are wrong, it’s just a matter of how wrong.
Transcript of Five Steps description:
What I’m trying to have us all implement rigorously is the five step process.
First, make your requirements less dumb. Your requirements are definitely dumb. It does not matter who gave them to you. It’s particularly dangerous if a smart person gave you the requirements because you might not question them enough.
Then, try very hard to delete a part or process. This is actually very important. If you’re not occasionally adding things back in, you’re not deleting enough. The bias tends to be very strongly towards “Let’s add this part or process step in case we need it.” But you can basically make “in case” arguments for so many things. And for a rocket that’s trying to achieve, trying to be the first fully reusable rocket…you have to run at tight margins because if you don’t run tight margins you get nothing to orbit.
Whatever requirement or constraint you have must come with a name, not a department. Because you can’t ask the department, you have to ask a person. And that person who it putting forward the requirement or constraint must take responsibility for that requirement. Otherwise you can have a requirement that basically an intern two years ago randomly came up with off the cuff and they aren’t even at the company any more . . . these things are way more silly than you’d think.
If you’re not adding things back in at least ten percent of the time you’re clearly not deleting enough.
Only at the third step you simplify or optimize. The third step, not the first step. The reason it’s the third step is because its very common, its possibly the most common error of a smart engineer is to optimize something that should not exist. And you say why would people do that? Well, everyone’s been trained in high school and college that you’ve got to answer the question, convergent logic. So you can’t tell a professor “your question is dumb.” You will get a bad grade. You have to answer the question. So everyones basically without knowing it they’ve got a mental straightjacket on. They will work on optimizing the thing that should simply not exist.
Finally you get to step four which is accelerate cycle time. You are moving too slowly, go faster. But don’t go faster until you’ve worked on the other three things first. If you’re digging your grave, don’t dig it faster, stop digging your grave.
The final step is automate.
Elon Musk’s Five Steps to Optimize:
- Question the Requirements - Delete Parts or Processes - Simplify - Accelerate - Automate
Quotes:
You want everyone to be a chief engineer. So, “everyone is a chief engineer” means that people need to understand the system at a high level to know when they are making a bad optimization. Like when we put immense effort into reducing engine mass but hardly any effort into reducing propellant residuals.
All designs are wrong, it’s just a matter of how wrong.
Transcript of Five Steps description:
What I’m trying to have us all implement rigorously is the five step process.
First, make your requirements less dumb. Your requirements are definitely dumb. It does not matter who gave them to you. It’s particularly dangerous if a smart person gave you the requirements because you might not question them enough.
Then, try very hard to delete a part or process. This is actually very important. If you’re not occasionally adding things back in, you’re not deleting enough. The bias tends to be very strongly towards “Let’s add this part or process step in case we need it.” But you can basically make “in case” arguments for so many things. And for a rocket that’s trying to achieve, trying to be the first fully reusable rocket…you have to run at tight margins because if you don’t run tight margins you get nothing to orbit.
Whatever requirement or constraint you have must come with a name, not a department. Because you can’t ask the department, you have to ask a person. And that person who it putting forward the requirement or constraint must take responsibility for that requirement. Otherwise you can have a requirement that basically an intern two years ago randomly came up with off the cuff and they aren’t even at the company any more . . . these things are way more silly than you’d think.
If you’re not adding things back in at least ten percent of the time you’re clearly not deleting enough.
Only at the third step you simplify or optimize. The third step, not the first step. The reason it’s the third step is because its very common, its possibly the most common error of a smart engineer is to optimize something that should not exist. And you say why would people do that? Well, everyone’s been trained in high school and college that you’ve got to answer the question, convergent logic. So you can’t tell a professor “your question is dumb.” You will get a bad grade. You have to answer the question. So everyones basically without knowing it they’ve got a mental straightjacket on. They will work on optimizing the thing that should simply not exist.
Finally you get to step four which is accelerate cycle time. You are moving too slowly, go faster. But don’t go faster until you’ve worked on the other three things first. If you’re digging your grave, don’t dig it faster, stop digging your grave.
The final step is automate.
What does "make your requirements less dumb" mean? Make them more applicable? Make them more precise? Something completely different? Question them, but what is the flaw of "dumb" in a requirement?
I'll take a stab at answering this by paraphrasing Musk.
He said this 5 step process was inspired by the time they were trying to optimize part of the Model 3 production. There was a segment that was causing a lot of problems - the installation of some sort of foam or padding on the battery. I guess the glue wasn't adhering well between the metal of the car and the foam, or whatever I dunno, problems.
They tried all sorts of things to optimize the process, until eventually Musk asked, "what's this for?" and the Noise and Vibration team told him they weren't sure, probably for fire safety. The Battery team (the one that would institute a fire-related requirement) told him they weren't sure, it was probably for noise and vibration.
They built a car without the foam, tested it for noise and vibration against a car with the foam, couldn't tell the difference, and ultimately removed the part entirely.
So this story touches all 5 of the points, but on the point of "make the requirement less dumb" it means that whoever got the requirement in the first place should have asked "what is this for?" and should have tried to find another way to meet the requirement without needing foam (and in doing so would have found out that the requirement was BS in the first place).
He said this 5 step process was inspired by the time they were trying to optimize part of the Model 3 production. There was a segment that was causing a lot of problems - the installation of some sort of foam or padding on the battery. I guess the glue wasn't adhering well between the metal of the car and the foam, or whatever I dunno, problems.
They tried all sorts of things to optimize the process, until eventually Musk asked, "what's this for?" and the Noise and Vibration team told him they weren't sure, probably for fire safety. The Battery team (the one that would institute a fire-related requirement) told him they weren't sure, it was probably for noise and vibration.
They built a car without the foam, tested it for noise and vibration against a car with the foam, couldn't tell the difference, and ultimately removed the part entirely.
So this story touches all 5 of the points, but on the point of "make the requirement less dumb" it means that whoever got the requirement in the first place should have asked "what is this for?" and should have tried to find another way to meet the requirement without needing foam (and in doing so would have found out that the requirement was BS in the first place).
I think the parent comment's story describes the concept really well. The below clip from "Pentagon Wars" describes some of the organizational dynamics that are another way to arrive at dumb requirements.
Pentagon Wars - Bradley Fighting Vehicle Evolution: https://www.youtube.com/watch?v=aXQ2lO3ieBA
Pentagon Wars - Bradley Fighting Vehicle Evolution: https://www.youtube.com/watch?v=aXQ2lO3ieBA
Either there isn't a precise goal so the requirements are scattered, or there is a precise goal and the requirements don't match the goal.
I had the same question.
Does it refer to eliminating or deprioritizing requirements that are not core to the product? Removing "gold-plating" requirements? Or does it mean converting solutions/implementations disguised as requirements into actual requirements? Something I see a lot of in my role.
I see value in both exercises.
Does it refer to eliminating or deprioritizing requirements that are not core to the product? Removing "gold-plating" requirements? Or does it mean converting solutions/implementations disguised as requirements into actual requirements? Something I see a lot of in my role.
I see value in both exercises.
What a BS parade. You don't become a real person by reading on how to become a real person.
"Intelligent individuals learn from every thing and every one; average people, from their experiences. The stupid already have all the answers."
https://www.goodreads.com/quotes/7834133-intelligent-individ...
- Socrates
https://www.goodreads.com/quotes/7834133-intelligent-individ...
- Socrates
I agree, but would be very surprised if the attribution was correct.
And how do you propose people learn how to become better? One way is to read. This is such an accepted thing that your response is so far below intelligible I can’t even try to engage with you in good faith.
Similar pages: [0,1,2] and my own list, [3]
[0] https://github.com/LappleApple/awesome-leading-and-managing
[1] https://github.com/kdeldycke/awesome-engineering-team-manage...
[2] https://github.com/ankitjaininfo/awesome-managers
[3] https://graphthinking.blogspot.com/2021/04/reading-list-for-...
[0] https://github.com/LappleApple/awesome-leading-and-managing
[1] https://github.com/kdeldycke/awesome-engineering-team-manage...
[2] https://github.com/ankitjaininfo/awesome-managers
[3] https://graphthinking.blogspot.com/2021/04/reading-list-for-...
My problem with reading all of these tomes (and by now I’ve read a few), is that while I appear to be aware of what works for a software team, my management does not, hasn’t read these, or just plain doesn’t care.
I need a guide on how to teach people that have a vested interest in not acknowledging that there might have been a problem in the first place.
I need a guide on how to teach people that have a vested interest in not acknowledging that there might have been a problem in the first place.
I've heard a rather interesting take on the issue:
> Your choices usually are to either change the company, or to change company.
(edited for clarity)
So essentially if the people around you fail to see your point, there's probably little that you can do to educate or convince them, short of looking for a new company to become a part of yourself.
I guess people "jumping ship" is just a sign of the times and the environment that we work in - in most western cultures it's a bit more fluid than in, say, Japan.
> Your choices usually are to either change the company, or to change company.
(edited for clarity)
So essentially if the people around you fail to see your point, there's probably little that you can do to educate or convince them, short of looking for a new company to become a part of yourself.
I guess people "jumping ship" is just a sign of the times and the environment that we work in - in most western cultures it's a bit more fluid than in, say, Japan.
> while I appear to be aware of what works for a software team
I think the problem might be here. You don't know what works because nobody does. These books offer frameworks and mental models to work through problems but every organisation is different.
Approaching it as "I have the solution and I just can't do it because you don't let me" is not great and I'm not surprised it hasn't worked. If you cannot get the rest of leadership or your boss on the same boat as you, you don't have any solution. The best of solutions is worthless if it can't even be put into practice.
This is assuming everyone has good faith and is trying to improve things. If not, switch jobs.
I think the problem might be here. You don't know what works because nobody does. These books offer frameworks and mental models to work through problems but every organisation is different.
Approaching it as "I have the solution and I just can't do it because you don't let me" is not great and I'm not surprised it hasn't worked. If you cannot get the rest of leadership or your boss on the same boat as you, you don't have any solution. The best of solutions is worthless if it can't even be put into practice.
This is assuming everyone has good faith and is trying to improve things. If not, switch jobs.
You can’t change a boss or organization. You can choose a boss or organization. And you can become a boss or start an organization.
The trouble with all of these great ideas is that while the management/leadership/whatever may claim they want to solve these problems - they actually don’t want these kinds of solutions.
What they want is to maintain the power structure that got them where they are - and want to remain - at all costs.
It’s like asking politicians who got elected using the current system to reform it. It ain’t gonna happen.
What they want is to maintain the power structure that got them where they are - and want to remain - at all costs.
It’s like asking politicians who got elected using the current system to reform it. It ain’t gonna happen.
Some leaders are insecure and guard their power jealously, but others truly are level-five leaders who want their organizations to thrive.
In my experience the distribution of the former tends to increase exponentially with the size of the company.
Yeah, good people are rare in most professions.
Additionally, humans tend to resist work to become more self-aware, and such self-awareness is critical for good leaders/managers (and yes I know those two things are different).
Additionally, humans tend to resist work to become more self-aware, and such self-awareness is critical for good leaders/managers (and yes I know those two things are different).
> increase exponentially with the size of the company
Most large countries are run by psychopaths incl the US recently
Most large countries are run by psychopaths incl the US recently
Yup. These are exactly the sort of exec speak that I expect up-and-coming managers read. They aren't exactly fads but nor are they longstanding respected works. Most will probably still be read in a couple years, but very few will survive twenty. Where are the great works that will improve a person's written language? Where are the seminal works on market theory? Where are the histories? My kingdom for an executive who can string together a cohesive paragraph.
Your comment makes it sound like you're aware of those works that you wish executives would read. Would you mind sharing some?
Not OP but I share their sentiment. In my estimation such a reading list should include:
- high output management, grove
- managing oneself, drucker
- tech revolutions and financial capital, perez
- measure what matters, doerr (maybe… as an addendum to high output management)
- high output management, grove
- managing oneself, drucker
- tech revolutions and financial capital, perez
- measure what matters, doerr (maybe… as an addendum to high output management)
Peopleware has been around for a while by now and continues to get as much praise as it did.
I'm surprised Andy Grove's High Output Management wasn't on the list.
I had a suspicion that there was a significant recency bias, so I clicked on the first 19 amazon links and looked at the published dates.
- 1988 - 1
- 1999 - 1
- 2000 - 1
- 2002 - 1
- 2005 - 1
- 2007 - 2
- 2008 - 1
- 2012 - 1
- 2013 - 1
- 2014 - 2
- 2015 - 3
- 2016 - 3
- 2017 - 1
I'm also reminded of the the recent post on The Creative World's Bullshit Industrial Complex [0]. There are some gems in here but I can't help but feel like a lot of them are just uninspired remixes of what came before. The list I want to see is of the "great management books". Ones that:
- had an effect on firms both in the time the book was published and in subsequent business "generations"
- influenced subsequent works of note.
- remain relevant to business today
Where is that list?
[0] https://news.ycombinator.com/item?id=28459533
- 1988 - 1
- 1999 - 1
- 2000 - 1
- 2002 - 1
- 2005 - 1
- 2007 - 2
- 2008 - 1
- 2012 - 1
- 2013 - 1
- 2014 - 2
- 2015 - 3
- 2016 - 3
- 2017 - 1
I'm also reminded of the the recent post on The Creative World's Bullshit Industrial Complex [0]. There are some gems in here but I can't help but feel like a lot of them are just uninspired remixes of what came before. The list I want to see is of the "great management books". Ones that:
- had an effect on firms both in the time the book was published and in subsequent business "generations"
- influenced subsequent works of note.
- remain relevant to business today
Where is that list?
[0] https://news.ycombinator.com/item?id=28459533
Try "The 100 Best Business Books of All Time: What They Say, Why They Matter, and How They Can Help You": https://www.goodreads.com/book/show/4274735-the-100-best-bus... . I found it useful as it has summaries of the books as well.
thanks. will check it out.