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.
I'm not sure the incentives are right... it's better to clean up as you go. Still some places would benefit from such an event from time to time and even if you clean up as you go missed opportunities happen.
Funny experiment at drawing parallels between engineering leadership and how you should behave when hiking in nature. This works surprisingly well.
Interesting tips and actions to help frame the conversation. The goal is to get the team better self-organized and directed.
This is indeed the best approach I've seen for brainstorming. It gives a chance to everyone to bring something forward, even the introverts.
A bit too archetypal for my taste but there's some truth to it. If you lean towards "explorer" (I think I do), it's hard to be also a leader. Now you could be aware of your flaws and put tools in place to compensate for them when you need lead.
This is an impressive piece about decision making and leadership. I love the approach: seeking to get the decision out of the person instead of deciding for them.
Interesting list. Definitely good things to try to learn there.
Interesting approach to get a better understanding and awareness of your surroundings as a tech lead or lead dev.
Nice (even though a bit long) explanation of the skills needed for a senior software engineers. Definitely a bunch of good advises in there.