This piece asks a very profound question in fact. If you're in a workplace where senior management allows and pushes everyone to get deluded about the real capabilities of those tools, how do you later move forward and rebuild trust?

Sometimes, you got to deliver the bad news... It's healthy if you feel uneasy about it though.

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.

Interesting insights, or how listening helps finding risk or making sure delegation will go well. It's indeed also a good illustration that story telling works often betterthan explaining abstract concepts.

Clearly, any endeavour which has to scale will need some form of bureaucracy to stay afloat. The art is keeping it to a minimal before it starts to be an end in itself.

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.

Rampant complexity in software is also a management issue. Are we sure we're rewarding the right things?

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.

This is good advice. To improve your organisation, focus only on the biggest constraint. Otherwise you'll quickly be spread thin.

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.

Good questions to consider to gauge how you work. Can improve the organisation if you really get to the bottom of it.

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.

That's one of those pieces where the clear cut categories look a bit like caricature. That said, that gives an idea of the kind of posture one should try to reach to be a good manager.

It's important to get to the bottom of problems indeed. The context in your organisation will matter for this.

Indeed, I think I prefer what's proposed here rather than READMEs. Having lightweight templates and processes to collect the information you need or steer the direction puts the burden of designing those in the right place (on the manager end). You should also know when things have to be more free form.

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.

An excellent piece, I like this kind of thinking. It works in fact as several level in your life.