Lots of good insights in here. Of course YMMV and some definitely depends on your context. That's a lot of dimensions to keep in mind though.

Interesting framework of different leadership styles. They all come with their own pros and cons of course.

The point is interesting. Priorities are indeed relative and dynamic. It's impossible to put an "absolute priority value" on what needs to be done.

Interesting comparison of Drucker's and Deming's approaches to management. One is easier while the other is clearly demanding but brings lasting improvements.

Nice advice, there's a lot of variation on the role. And yet, some things seem to always be there.

This is a good overview of what the Staff Engineer can be. There's of course a lot of variation depending on time, priorities and the culture of the organisation.

Feels a bit odd to go to such length to put it in numbers. And yet, it's clear that friendships in the workplace are a must. They should be fostered rather than stifled.

Good historical perspective about the attempts to get rid of developers. This never unfold as envisioned. This is mostly about the intellectual work to build artifacts handling the world complexity, and this doesn't go away.

This has been documented for a long while. Of course, it's been followed by an unhealthy fascination for the "Toyota way". This kind of cargo cult of course lead you nowhere to doing things properly. And yet, now that the dust settled, there are good lessons to learn from Toyota management back then.

I think this is a good pick at a core skill for senior developers. Indeed removing ambiguity for the rest of the team is an important factor.

This is very true. It's not like whoever produced bad code is particularly stupid, in most cases it's the context around which breaks the people.

It's indeed not just about the label. It's more about behaviour.

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.