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'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.
I don't mean to nitpick, but I had to read it a few times before realizing what the quote was saying, I think removing one of the "the":s before a company would make it clearer.
> 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.
Yep. As Simon Sinek puts it, leadership doesn’t have to start from the top. Leadership starts when you take care of the person to the left of you and the person to the right of you.
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.
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).
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.
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.
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).
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.
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.
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.
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"
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.
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.
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.