4 ms·

This is basically the methodology behind an Ishikawa (fishbone) diagram. It’s a pretty useful way of representing things (although I personally prefer indented

This is basically the methodology behind an Ishikawa (fishbone) diagram. It’s a pretty useful way of representing things (although I personally prefer indented bullet points).

marcosdumay 3y ago
Yeah, I was just about to reply about fishbone diagrams too. Those are an improvement on the right direction. But notice that they don't fit the GP's explanation at all. As strange as that may sound, causality is not unidirectional in a complex system. You are losing data by coercing it into that, and that data is quite often relevant to how you fix a problem, even if it's not commonly relevant for identifying the problem.
- d1sxeyes 3y ago
  Although that’s true, often something like a fishbone diagram will help to create a prioritised to-do list to fix whatever is broken (or at least understand what caused it to break if it’s not fixable).
- a_c 3y ago
  Thank you for clarifying. Re-reading the message, the intention wasn't obvious at all. For example, given a wet floor, 5-why tends to give a single reason, e.g. because it rained, and people may drill deeper into why it rained. My intention was to search broadly, i.e. what could also cause wet floor, the weather, a burst pipe, a road cleaning truck, a nearby fire, etc, and also to search adjacently, e.g. water outage due to burst pipe, flooding due to rain, etc. This will quickly expand the searching surface. It helped me to see the river instead of flowing downstream. e.g. Engineers was drowning in "tasks", it is not uncommon to have solutions along the line of work harder, pay down tech debt and hire more within the engineering org. But upon searching, the cause might be anywhere between lacking product market fit, broken and interdependent processes, fragmented and over specialised teams and tooling, and religious pursuit of growth, which has nothing to do with engineering in a traditional sense.

This is basically the methodology behind an Ishikawa (fishbone) diagram. It’s a pretty useful way of representing things (although I personally prefer indented bullet points).

marcosdumay 3y ago

Yeah, I was just about to reply about fishbone diagrams too. Those are an improvement on the right direction. But notice that they don't fit the GP's explanation at all. As strange as that may sound, causality is not unidirectional in a complex system. You are losing data by coercing it into that, and that data is quite often relevant to how you fix a problem, even if it's not commonly relevant for identifying the problem.

d1sxeyes 3y ago
Although that’s true, often something like a fishbone diagram will help to create a prioritised to-do list to fix whatever is broken (or at least understand what caused it to break if it’s not fixable).
a_c 3y ago
Thank you for clarifying. Re-reading the message, the intention wasn't obvious at all. For example, given a wet floor, 5-why tends to give a single reason, e.g. because it rained, and people may drill deeper into why it rained. My intention was to search broadly, i.e. what could also cause wet floor, the weather, a burst pipe, a road cleaning truck, a nearby fire, etc, and also to search adjacently, e.g. water outage due to burst pipe, flooding due to rain, etc. This will quickly expand the searching surface. It helped me to see the river instead of flowing downstream. e.g. Engineers was drowning in "tasks", it is not uncommon to have solutions along the line of work harder, pay down tech debt and hire more within the engineering org. But upon searching, the cause might be anywhere between lacking product market fit, broken and interdependent processes, fragmented and over specialised teams and tooling, and religious pursuit of growth, which has nothing to do with engineering in a traditional sense.