Nice (even though a bit long) explanation of the skills needed for a senior software engineers. Definitely a bunch of good advises in there.

Interesting way to frame the potential problems around organizational culture. This indeed influence behaviors quite a bit so should be in check. It also shows it's a complicated problem you don't want to overdo it, freeze the culture in place, and see it used mainly for blaming... it'd effectively turn into a cult.

Definitely this. Having "heroes" brings obscurity and hide the problems, this prevents management from knowing and handling the issues. This also create lots of missed opportunities for collective learning and improvements.

Interesting advises for higher management roles. The information gathering and the distorsion fields are key factors to have in mind to not loose perspective. Otherwise it's when you'll start doing more harm than good.

Interesting, this seems to empirically confirm the Peter Principle, at least in sales. Also shows that companies are trying to workaround it. Dual career ladders seem to be an interesting path for this.

This is definitely a worthy advice with lots of interesting side effects. For me the main motive beyond cheer curiosity is developing more empathy towards others with different roles.

OK, definitely a gutsy move... Still this is an interesting approach for a complex system. Better have a controlled early failure if you can get it, than a complete collapse later on. This might be just the incentive you need for real organizational change.

This is a sound advice, it's better if it's a conversation. Some companies push for that some don't. If they don't the proposed plan is a good one.

It's coming from the job interview domain... but I wonder if it could be more largely useful due to how simple it is (but not easy mind you). I guess I'll experiment with it for my next project postmortem.

Always a good idea to seek reduction in time spent in meetings. I've seen this being too often a drain. Can get quickly out of control.

It's clearly a choice in management style. For such choices, always keep in mind the trade offs this create, maybe it'll push you to revise your choice.

Like it or not (I'm part of those who don't like it) but the role of manager will necessarily create power imbalances. This article is thus a must read to managers at any level to know how to deal with it properly.

Interesting article. I especially like how it makes the difference between being kind and nice. That honesty is required if you want to be really kind to others. It nicely shows examples on how to apply this (for instance, but not only, in the context of code reviews).

I'm not a huge fan of the "Steve Jobs said..." to justify thing, a clear rhetoric trick. Still, I think this short piece nails it down, it's just better when managers actually know the job. It's better to promote someone who knows it and coach that person into the job. There's only one challenge then (which is glanced over in the paper): how to keep this manager technically relevant over time. It's not that easy in our field.

Interesting take of the cognitive overload in bigger teams which end up with more responsibilities. Indeed splitting the teams and the responsibilities can then be a way out.

Interesting framework for sustaining a strategic train of thoughts for the long term. This can't be a fix thing, it needs to live and breather which this approach seems to foster.

Interesting take on burnout as an organizational phenomenon and the consequences. This is not simply about the amount of work.

Maybe a bit heavy handed in the way it is presented in this piece. Still, constant brainstorming can get in the way of true focus or getting in the zone. This is definitely needed for some problems.

As I could experience both, I concur. Anniversary reviews are just much better for everyone involved.

Interesting point. It's clearly not easy to get proper feedback depending the size of the group we're reaching out to.