In other words, remember you're a manager and not a nanny. Of course, it doesn't mean you can freely ignore the human factor or empathy. Just don't get overwhelmed by this.

Interesting move on the Scrum definitions to move from roles to accountabilities. The article does a good job explaining it but then falls back into talking about roles somehow. Regarding the tech leads indeed they can work in Scrum teams. Scrum don't talk about them simply because Scrum don't talk about technical skills.

Nice list of templates to use for better handling of engineering management in your organisation. Pick, choose and adapt what makes sense to the context.

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.