This is still a good framework to think about what motivate developers in a team. Not everyone is the same.

An oldie but still a good one. Yes, the people matter but even good people won't strive in a badly designed system.

Indeed, it's hard. You need to put in the work but it's hard to predict where the real value will come from.

Interesting findings about procrastination. Some effects were expected, others less so. The actions to avoid it in teams should be well known now.

Interesting comparison of different definitions for software complexity (which is an ambiguous term to say the least). It leads to nice consequences when team dynamics are considered.

Juggling different roles isn't easy. It's indeed even harder when friendships are involved. Know which hat you're wearing at all times.

This kind of articles are always a bit caricatural. Still there is some good advice in there. Keep an eye open for the harmful behaviors.

Mistakes happen, but shrugging them off with blaming people or pushing them to be more careful is counter-productive. Instead, you want to find the organizational issues which made them possible in the first place.

If you expected another outcome on the average developer job from the LLM craze... you likely didn't pay attention enough.

You've see a co-worker doing this, right? They're unlikely to be spies, but still they're inadvertently using sabotage tactics.

I prefer aiming for egoless positions in teams... But if it doesn't work, I guess this little trick can help turn someone around.

Rituals are definitely important... if you understand why you're going though them. If you just "go through the moves" they're failing.

Or why it's important to deeply understand what you do and what you use. Cranking features and throwing code to the wall until it sticks will never lead to good engineering. Even if it's abstractions all the way, it's for convenience but don't treat them as black boxes.
Interestingly this article draws a parallel with organizations too. Isn't having very siloed teams the same as treating abstractions as black boxes?
Quite some food for thought here.

This is indeed almost always leadership you need in your organization. An engineer who want to manage, maybe be careful about their skills and motives.

A bit shallow, but there's good advice to get started. Very often the quality of the communication medium is underestimated.

Good tips for time management indeed. I apply some of those but think I will borrow some extras from this article.

Nice little exercise to quickly figure out if the skillset of a team properly matches their project.

If you spend your time in dull meetings and then run like a headless chicken... it's definitely a sign you should cut down on the meetings and keep only the ones focusing on solving actual problems.

It's indeed a vicious circle. Also it seems easy to fall into this particular trap, I see it in many places.

This is indeed a very good way to approach planning. You shouldn't be shackled to a too detailed strategy. The broad goals are the real value, then it's about seizing opportunities to advance your position.