[HN Gopher] High Performance Organizations Reading List
___________________________________________________________________
High Performance Organizations Reading List
Author : bfoks
Score : 61 points
Date : 2021-09-13 19:20 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| aluciani wrote:
| Great resource thanks for sharing. Lots of titles and resources
| that I have never considered. Super useful :)
| mu_killnine wrote:
| 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.
| sodality2 wrote:
| How would you even _begin to begin_ with that task? What
| resources would you consult?
| mwint wrote:
| How'd you get the opportunity to start an IT department from
| scratch? Small growing company?
| harshreality wrote:
| 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
|
| These aren't really distinct, they tend to all merge together.
| I'm sure if he formalized this and wrote it down for mass
| consumption it'd be presented differently, but he's clearly using
| this 5-step model to frame how he thinks about the process.
|
| 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 more to remove
| testing that's designed to reveal information that's already been
| collected and addressed. Cautions about false positives from in-
| process testing, and notes most testing can probably be tested
| end of line with acceptable results.
|
| (He's clearly talking about a rapidly-evolving production
| process, not a mature production process where stability and
| predictability are more important than new features or improved
| performance or cost efficiency.)
| adolph wrote:
| 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.
| question002 wrote:
| Oh self-help books written by corporations?! Surely this can help
| me. I really need the Internet to point me to this. HN is such a
| not dead site.
___________________________________________________________________
(page generated 2021-09-13 23:00 UTC)