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-...
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.
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.
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'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?
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.
Great resource thanks for sharing. Lots of titles and resources that I have never considered. Super useful :)
Software and hardware are factories that manufacture data, so they have the same "warehouse/workshop model" and management methods as the manufacturing industry. so, Software and hardware are a unified architecture: "warehouse/workshop model".
the "Warehouse/Workshop Model" will surely replace the "von Neumann architecture" and become the No. 1 architecture in the computer field, and it is the first architecture to achieve a unified software and hardware. Follower: Apple M1 chip.
[The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model](https://github.com/linpengcheng/PurefunctionPipelineDataflow)
[10 principles of the system design](https://github.com/linpengcheng/PurefunctionPipelineDataflow...)
[Why my "warehouse/workshop model" can achieve high performance and low power consumption (take cloudcomputing, supercomptuing, HPC, Apple M1 chip, Intel AVX-512, Qualcomm as examples)](https://github.com/linpengcheng/PurefunctionPipelineDataflow...)
[The difference between "the Principle-based Warehouse/Workshop Model" and "Microsoft Azure DataFactory/DataPipelines Architecture"](https://github.com/linpengcheng/PurefunctionPipelineDataflow...)
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.
What a BS parade. You don't become a real person by reading on how to become a real person.
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.