I think such posts (and books) are usually meant like checklists for people who already knows that stuff (not learning it), but want it formalized. Then when you have issues for example with team members, you can look at those resources and try to assess why something is going into the wrong direction. It's easier to enumerate those points then.
It seems this kind of posts/books is more aimed to selling oneself as a consulting business process expert in a corporate market than to teach anything to the practitioners. It's a bunch of soundbites aimed at a dilettante.
I had a friend in college who wanted to be a writer. She was paranoid about spending too much time on comparative lit and setting the bar too high for herself before she ever got good at it.
As far as I can tell, she didn't avoid that trap, despite identifying it. Occasionally I wonder if I avoided it. There are so many ways for a project to fail and when you know too many you can become a nervous wreck. Over most of the course of the '10s I've noticed that I'm a lot more comfortable with certain classes of imperfection, because they are immaterial to the job at hand, or represent an unknown that we haven't tackled yet (if you don't know how something should actually work, making it 'perfect' might make it perfectly wrong, and then where are you?). It's like a chess game. Half the board is full of pawns to be sacrificed for some higher priority. You have a contingency plan for any threat, but you can't act on them all at once.
Probably everybody does this, but their set points are different than mine, so we argue over code reviews.
