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.

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.