It's clearly a choice in management style. For such choices, always keep in mind the trade offs this create, maybe it'll push you to revise your choice.

Nice list of things to keep in mind when working on projects, even small personal ones. This greatly improve maintainability in the long run.

A bit heavy handed in the way it tries to paint Root Cause Analysis as evil. Still it has good points about its shortcomings. In particular I appreciate the emphasis on complexity which indeed points to have contributing factors and unexpected outcomes. Definitely things to keep in mind for any postmortem efforts.

Interesting story on how power plays can sometimes completely hide the fate of a project until it's too late. Definitely a cautionary tale.

Very important points. This can easily turn a project into a death march with rampant undue complexity. Also the proposed guidelines are simple and seem efficient.

This is an interesting way to frame it. I generally talk with people about making sure you got vision and horizon in your product backlog (which then requires adequate grooming). Still this sounds like a simpler to grasp wording here. Probably good for a first approach.

Interesting way to highlight Goodhart's Law. Indeed you can be corrupted by the very system you put in place if if it's mainly driven by metrics. As much as possible, think qualitative, not quantitative.

Lots of truth in there. Indeed the proposed "practices" when they get in just kill the promises of things like Scrum.

Good explanations on why trading quality for speed is always a bad idea. It also goes on about how to avoid sacrificing quality through the definition of done and proper estimates.

This is unfortunately very much true. Was only a matter of time I guess. The "grass is greener" effect is indeed the most likely reason.

An advice I often give, it's nice to see the theory behind it well laid out like that.

Now this is a well balanced piece about estimates. Starting from the "why" to decide how you approach the estimates and the level of details is just very good advice.

Couple of interesting tips. I like how it challenges the usual mythical man-month quote. Indeed sometimes adding people might help, if the conditions are right.

It feels a bit like cumulating aphorisms and "laws" to prove the point. Still it's nice to know them at least for the general culture.

Interesting set of metrics indeed. As usual the danger lies in how/if you set targets and potentially fuzzy definitions of some of the terms.

Interesting take as usual. Utilization doesn't matter, throughput is what you need to keep in mind.

This is a good piece. Killing all planning is indeed not a good thing. Setting plans in stone wasn't a good thing either, it's no reason to go to the other extreme.

Interesting musing on how different types of companies manage their projects. I'm glad to see there's less cargo-cult Scrum than I expected. I also find funny that Scrum is perceived as "heavy weight". :-D

This is a sane approach and a good list of steps for estimating at large scale.

Excellent advises on project planning and management. It explains pretty well why being optimist in those areas will just drive your project through a wall.