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.

Definitely required more preparation work than brainstorming. That said it's a nice alternative, maybe easier to get right.

The other advantage of not relying only on specialists. You actually get teams better at solving problems due to the extra context and communication channels the generalists will bring.

Good advice to get (back) into sketch noting or visual thinking.

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

You can also have experiments on your organisation. This is actually a good thing and probably should be done when something keeps popping up as a problem.

The title is a bit misleading in a way (and I almost didn't click through for a start). That said, it is an interesting essay dealing with the topics of intelligence, problem solving etc. I'm not sure I agree with everything in it, but that's still good food for thought.

You can't be in the backseat when using those tools. Otherwise you might feel productive by cranking out code but it can't do the essential tasks for you (most notably actual problem solving or architecture thinking). The quality would clearly suffer.

Nice list of tools and models to use for better decision making and problem solving. Can all be done on paper of whiteboard. This is a good reference.

If you spend your time in dull meetings and then run like a headless chicken... it's definitely a sign you should cut down on the meetings and keep only the ones focusing on solving actual problems.

An excellent article, that troubleshooting skill is really important in many fields... In particular software engineering. It's hard to teach and learn but it makes all the difference.

I'm not sure I would phrase it like this but there's quite some truth to it. It's important to figure out what we take for granted and to open the black boxes. This is where one finds mastery.

Interesting musing on the heuristics we use when solving problems. There are good advices in there to make progress and become a better developer.

Indeed, be careful when using "just". It's often doing more harm than anything.

Interesting talk about management and why it's hard. It touches upon problem solving and why we fail at it. In short we often look at symptoms and not problems. To make things worse we often try to solve them at the wrong place out of sheer ignorance.

It's also a very humble talk which I always appreciate.