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.

Nice summary of common terms used for roles in companies.

Interesting little taxonomy of staff engineer roles. This can help to know from where you're talking in your organization.

Interesting career ladder example. I especially like the various dimensions they focus on.

Interesting way to highlight Goodhart's Law. Indeed you can be corrupted by the very system you put in place if if it's mainly driven by metrics. As much as possible, think qualitative, not quantitative.

If you want to get to the bottom of a problem and of why an accident happen, people need psychological safety. This is indeed necessary if you want them to share truthfully why the accident happened in the first place. Otherwise fear will drive the conversation and hide important facts.

A good reminder about the impacts of Goodhart's law, or even simply of measuring the wrong thing. I like the conclusion overall: it's fine to measure things but that shouldn't be the center of the decision taking and conversations need to take a larger role into it.

Good points to keep in mind regarding team size. It's a delicate balance to strike in an organization.

Very thorought breakdown on the things to keep in mind around remote work. We definitely still need offices and ways to meet. It "just" needs to be rethought how we use them and how we're reachable.

That's nice to see a reusable framework to help organizations get started with their engineering ladder.

OK, unexpected introduction, still the advices are sound: teach, delegate, handle the hard cases.

It feels a bit like cumulating aphorisms and "laws" to prove the point. Still it's nice to know them at least for the general culture.

Very good points in there. Indeed there's a natural tension between making and managing. You can't schedule the day in the same way. After more remote work, indeed we'll need more async communication.