The responsibilities drop on people before they're ready for it (I see it first hand regularly at customers). Such tips are thus welcome and helpful during the transition.

This is a short one but a good one I think. Helping others to do rather than doing directly is the needed shift to get into technical leadership. It's not an easy leap though, been helping some people getting there and it's quite the effort.

Short and to the point reminder: our job is never only about the tech. It always encompass some people related concerns, be it inside teams, between teams, or the impact on the users.

Cryptic title to be honest. But this is a good explanation of why any "agile transformation" better start close to the code and in particular with automated tests. If you can crack that nut (and it take time), the rest will follow naturally.

So much this... There are so many organisational problems that churning code faster is likely not what you need. When did we start to obsess with the number of lines of code?

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.