Nice musing about leadership in a technical context. It's indeed not completely about having all the answers, it's about facilitating the conversations and framing them properly.

This is a widespread syndrome. It's not only in our industry of course but has real consequences in terms of leadership.

Interesting parable, it's indeed a good way to illustrate different leadership styles. Being more strategic is clearly what one should try to do.

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

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

Not fond of the metaphor used here which leads to quite some noise. Still, this article contains interesting ideas to try to push R&D initiatives forward. Definitely needed to improve any kind of organisation.

Quite some good advice in here. I like being around people who proactively communicate, mind the quality of the communication and look for new things to work on. Who wouldn't?

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.

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

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.

For sure the aforementioned manager need to fix his communication style. That being said the core advice was indeed good.

Interesting way to frame the question for leadership roles.

I like this. Sometimes a simple word can make all the difference in the way we behave. Code stewardship is indeed a better word.

It's indeed not easy to go from individual contributions, to team level leadership, to organisation level leadership. Many things need to be learned or relearned at each step.

There's clearly a tension on that topic and the expectations from engineering managers tend to change over time. I like the proposed answer here and the distinction made between writing code and being in the code.

The proposed three traits are definitely spot on. Too much confidence is a red flag, some balance needs to be found.

Not a huge fan of the writing style and the pokemon metaphor. That said, seeing your growth as an engineer based on circles is spot on.

Interesting ideas about leadership lacking in impact. Indeed it should be seen as a communal function, it's not about individuals leading each in their own directions. Think about it in a systemic way.

Good points, this is indeed often where we are struggling when we move to a leadership role. This changes the nature of the work at least in part and we need to adjust to it.