Comment by rpdillon
3 days ago
Strongly disagree with this.
In order to figure out a good solution, you have to have mastery over the problem. That takes a bunch of work.
> Understanding an issue is not the same as fixing it. A good explanation can make things worse. Once everyone agrees that the behaviour was reasonable, the urgency to change anything disappears.
This is a non-sequitor. We're not here to evaluate whether the behavior was reasonable, we're here to figure out how to avoid bad outcomes. If all the behavior was reasonable, then the problem lies somewhere else, and that's an important finding when crafting a proper solution.
The author is literally saying that asking why is the wrong question, and instead asking "What will we change?" is the right question. I get where this comes from, but you can't really answer what will change until you deeply understand why it happened.
I think you did not read that part.
> The SVP wasn't interested in understanding how the issue happened or who was involved. They didn't want to be convinced that everyone involved behaved reasonably. That's a baseline expectation.
Their question became:
“Given that reasonable people produced this outcome, what needs to change?”
Of course you have to know the problem, but he trust and excpect a sulution from them. So this does just work this way, if you can trust the people. If not, then the top person has to check the solution for himself.
It's a leadership thing. We're letting "trust" do a lot of lifting here -- I can trust my people, but still say that I'd like a good root cause analysis along with the proposed solution, so I can map the solution back to the actual problem and make sure it actually addresses it.
In my experience, lots of ineffective leaders propose solutions that don't actually fix the problem. In fact, I'd say it's the primary failure mode. I tell folks I work with to watch out for managers that will respond to a problem you raise by saying "Yes, and we're going to solve that with this new program...", and then they conveniently stop talking about the problem, and continue to give updates on the new program. My issue is that the new program is usually just pushing paper around, because actually solving the problem is hard. I don't like approaches that proxy "I understand the problem" with "I have a solution", and saying I trust someone doesn't cover this; it's firmly in the "trust but verify" category.