6 ms·

This seems kind of like a twist on the classic 5 Whys method of root cause analysis. I think 5 Whys would work just as well in most of the example scenarios. E

This seems kind of like a twist on the classic 5 Whys method of root cause analysis. I think 5 Whys would work just as well in most of the example scenarios. Example from the post: Engineer is thinking about doing a thing without permission. Why? Engineer thinks nobody accepts his ideas. Why? 5 possible answers. We could ask "Why?" again and get another step down (the author doesn't do this and instead proposes jumping into tests right away, which I think is still at least a level too high). One answer given: Engineer thinks his ideas are good, but they are bad. Why? Engineer probably isn't validating their ideas against feasibility, business outcome, maintainability, etc. Why? Engineer might be arrogant or inexperienced with real business settings vs. university/hobby projects. Now we have a root cause we can address and then move back up the chain. When you can't ask "Why?" anymore without it being silly, that's when it's time to run tests and propose solutions.

tiborsaas 3y ago
Thanks for pointing this out, I've never heard the 5Y before: https://www.mindtools.com/a3mi00v/5-whys https://www.mindtools.com/a3mi00v/5-whys
- a_c 3y ago
  5-whys is useful. 5-whys is a linked list. Sometimes, things don't have a single cause. One mental model I find useful, while harder to apply, is to see things as a web of dependency. What are the whys for this layer of problem. What other problems are also implicated by the "why". i.e. A graph
  - d1sxeyes 3y ago
    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.
  - hinkley 3y ago
    What people often forget is that the goal of 5 Why's is to arrive at an actionable 5th Why. There's some chess that starts around the third Why, and good players end up at a useful 5th, bad players end up at 'git gud scrub'.
- jes 3y ago
  If the Five Whys appeals to you, you might also like the "Thinking Process Tools" of Goldratt's Theory of Constraints. That being said, you always have to avoid fooling yourself when building logic diagrams. It's easy to do.
fatnoah 3y ago
> When you can't ask "Why?" anymore without it being silly, that's when it's time to run tests and propose solutions. In the past year, I started a new role as a head of engineering for an existing team. I literally spent the first month asking "why" about nearly everything. The most common answers ended up being "I don't know, it's what we do", which was closely followed by some justification that boiled down to being a workaround for some anti-patterns. E.g. Q: "Why do we log this error at DEBUG level?" A: "It happens so often that it fills the logs when we log it at a higher level". Me: :(
- mcbutterbunz 3y ago
  This is why its a good idea to tell new hires to not be shy about asking "Why?". They haven't had enough time to become numb to the idiosyncrasies of the organization. At some point, you start to live with all those little problems, forget they are actual problems, and you just live with them until someone asks "Why?" and you respond "yeah, why DO we do that?"
  - wmidwestranger 3y ago
    "Brenda came up with it, isn't she awesome?" Most common type of answer I've received, which is a bit of a bummer.
    - fatnoah 3y ago
      I'm literally dealing with that as we speak. Some architecture developed by the Staff Eng. on a team that's really not workable and was causing the team to run in circles. Ultimately, I had to jump in and ask a lot of questions about the implementation. i.e. Why was it built that way, along with the related questions about what goals of the implementation were (elegance, speed to delivery, future-proofing, ability to parallelize code effort, etc) and what app/business problems the code was solving.
- landemva 3y ago
  Lucky you to have found a place that allows those inquiries. Not many exist anymore.
agentultra 3y ago
5 Whys, or as I like to call it, "Jumping to Conclusions." Viewing the world as a direct line of causal relationships is called, "making a story." You can take it all the way back to the beating of butterfly wings if you'd like. It's also quite ineffective at addressing systemic issues and connected relationships. An alternative approach to post-hoc rationalization is to look into the factors that contributed to a particular outcome (or recurring set of related outcomes) and determine relationships between them: there are often systematic reasons for particular outcomes and not a singular event. Systems are not set up like dominoes in neat rows. It's usually much more messy than that. You can follow such a causal chain a few steps and say, "look I found the root cause!" But you won't solve the problem if you don't identify the systemic factors that lead to such situations. Even if you apply a solution to that root cause, you may find the outcome happens again -- it just finds another way around your patch, sort of like a cartoon of character trying to fix a leak in their plumbing by covering it up. To really solve the problem they need to turn the water off at the entry point, reconsider the plumbing set up, and fix their budgeting so that they allocate funds to preventative maintenance. Instead we get to laugh as they get squirted in the face over and over as they try more elaborate schemes to plug all of the holes. An example of a common factor in software development: leadership that prefers features shipped on a deadline. They will do anything to ship by the deadline. There may be a right way to do things to prevent errors in the system but not acknowledging this when an issue comes up, by jumping to conclusions about root causes, means your team will be constantly fighting fires in your production environment instead of taking the time to write specifications and modelling them and properly testing things. You may feel good about finding that one line of code that caused the outage. You may apply the patch and be the hero of the week. But it's not a matter of if another outage will happen but when because you haven't addressed the confounding factor that causes situations like that to happen again and again. If it doesn't get addressed then the leadership will find other post-hoc rationalizations for why these situations keep happening where the development team is, "getting slow." To take it back to the article: if people are ignoring your advice constantly, are you going to find out why by stepping back through a causal chain to a root cause? What if you did find a satisfying cause and you address that issue. Does that mean people will listen to you or will you only get that one idea through before you notice the pattern repeating? I like the idea the article suggests of trying several things. It could be an issue like discrimination: notice that all of your colleagues are young, white, and male presenting? Does anyone else on your team that doesn't fall into that demographic get their ideas through? Maybe that's only part of it though. It could also be true that your ideas need work as well. Trying a few things may make all the difference. Ask why, but also look at the surrounding environment and see if you notice any recurring patterns or relationships around the incident. After all, you don't find the source of disease by following the individual; you need to find the patterns that lead you to the wells.
xpe 3y ago
See also "The problem with ‘5 whys’" by Alan J. Card [1] [2]. I've included some quotations below. The discussion of "distal causes" is illuminating. [1] https://qualitysafety.bmj.com/content/26/8/671 https://qualitysafety.bmj.com/content/26/8/671 [2] http://dx.doi.org/10.1136/bmjqs-2016-005849 http://dx.doi.org/10.1136/bmjqs-2016-005849 > The ‘5 whys’ technique is one of the most widely taught approaches to root-cause analysis (RCA) in healthcare. Its use is promoted by the WHO, the English National Health Service, the Institute for Healthcare Improvement, the Joint Commission and many other organisations in the field of healthcare quality and safety. Like most such tools, though, its popularity is not the result of any evidence that it is effective. Instead, it probably owes its place in the curriculum and practice of RCA to a combination of pedigree, simplicity and pedagogy. > In terms of pedigree, ‘5 whys’ traces its roots back to the Toyota Production System (TPS). It also plays a key role in Lean (a generic version of TPS) as well as Six Sigma,11 another popular quality improvement (QI) methodology. Taiichi Ohno describes ‘5 whys’ as central to the TPS methodology: The basis of Toyota's scientific approach is to ask why five times whenever we find a problem … By repeating why five times, the nature of the problem as well as its solution becomes clear. The solution, or the how-to, is designated as ‘1H.’ Thus, ‘Five whys equal one how’ (5W=1H). (ref. 9, p. 123) > This quote also makes the case for the technique's simplicity. Asking ‘why’ five times allows users to arrive at a single root cause that might not have been obvious at the outset. It may also inspire a single solution to address that root cause (though it is not clear that the ‘1H’ side of the equation has been adopted as widely). > ... > It is clear from the tree diagram that the causal pathway related to the wristband printer is neither the only relevant cause of the incident nor indisputably the most important. A serious effort to solve the myriad problems that gave rise to this incident would have to tackle a number of other causal pathways as well. > ... > There are many ‘correct’ ways a team might use ‘5 whys’ to assess even this one incident. And it is unlikely that any two teams would independently arrive at exactly the same results. This subjectivity is critically important because ‘5 whys’ focuses on only one root cause at the end of one causal pathway. > ... > Targeting only the most distal cause > Not only are users of ‘5 whys’ limited to one root cause per causal pathway, but they are also limited to selecting only the most distal cause (conventionally, the fifth ‘why’). There is, however, no logical reason to assume that this is always the most effective or most efficient target for intervention. > Actually, if it were possible to magically place a 100% effective risk control at any one point on the tree diagram, it would be best used on a proximate cause. For instance, making it impossible to administer medication without checking the wristband would render all the more distal causes moot for the purpose of preventing a recurrence. > And, while 100% effective risk controls are seldom available, an action plan that includes a proven26 (if certainly imperfect) intervention like a well-designed bar-code reader with a forcing function for patient identification (ID) is more likely to prevent another serious ‘wrong patient’ medication error than switching to a well-designed printer. > This is not to suggest that more distal causes are not appropriate targets for improvement efforts. In the example presented in figure 1, for instance, there is clearly a profound need to change the culture from one that is task-oriented and sometimes hostile to one that is outcomes-oriented and psychologically safe. The pervasive impact of such a culture change would be far more important than merely reducing the risk that this particular incident might recur; it would influence almost every quality and safety issue in the organisation. > And, in contrast to that powerful-but-difficult lever for shifting outcomes, sometimes more distal causes represent ‘low-hanging fruit’ that can be addressed while a more proximate solution is in the works. In figure 1, educating patients about why clinicians will be constantly asking them to identify themselves would be far from foolproof. But it would be fast, cheap and easy. And it might reduce an important barrier to best practice in verbal identification. > Appropriate targets for intervention may occur anywhere along the causal continuum and on any causal pathway. And efforts to improve safety and quality will often require more than one intervention targeting more than one underlying hazard. It is useful to identify all the key hazards that gave rise to an incident and ensure that each of these is either addressed or intentionally accepted. (See, for instance, the Options Evaluation Matrix.) But the use of ‘5 whys’ makes this impossible.

tiborsaas 3y ago

Thanks for pointing this out, I've never heard the 5Y before: https://www.mindtools.com/a3mi00v/5-whys https://www.mindtools.com/a3mi00v/5-whys

a_c 3y ago
5-whys is useful. 5-whys is a linked list. Sometimes, things don't have a single cause. One mental model I find useful, while harder to apply, is to see things as a web of dependency. What are the whys for this layer of problem. What other problems are also implicated by the "why". i.e. A graph
- d1sxeyes 3y ago
  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.
- hinkley 3y ago
  What people often forget is that the goal of 5 Why's is to arrive at an actionable 5th Why. There's some chess that starts around the third Why, and good players end up at a useful 5th, bad players end up at 'git gud scrub'.
jes 3y ago
If the Five Whys appeals to you, you might also like the "Thinking Process Tools" of Goldratt's Theory of Constraints. That being said, you always have to avoid fooling yourself when building logic diagrams. It's easy to do.

fatnoah 3y ago

> When you can't ask "Why?" anymore without it being silly, that's when it's time to run tests and propose solutions. In the past year, I started a new role as a head of engineering for an existing team. I literally spent the first month asking "why" about nearly everything. The most common answers ended up being "I don't know, it's what we do", which was closely followed by some justification that boiled down to being a workaround for some anti-patterns. E.g. Q: "Why do we log this error at DEBUG level?" A: "It happens so often that it fills the logs when we log it at a higher level". Me: :(

mcbutterbunz 3y ago
This is why its a good idea to tell new hires to not be shy about asking "Why?". They haven't had enough time to become numb to the idiosyncrasies of the organization. At some point, you start to live with all those little problems, forget they are actual problems, and you just live with them until someone asks "Why?" and you respond "yeah, why DO we do that?"
- wmidwestranger 3y ago
  "Brenda came up with it, isn't she awesome?" Most common type of answer I've received, which is a bit of a bummer.
  - fatnoah 3y ago
    I'm literally dealing with that as we speak. Some architecture developed by the Staff Eng. on a team that's really not workable and was causing the team to run in circles. Ultimately, I had to jump in and ask a lot of questions about the implementation. i.e. Why was it built that way, along with the related questions about what goals of the implementation were (elegance, speed to delivery, future-proofing, ability to parallelize code effort, etc) and what app/business problems the code was solving.
landemva 3y ago
Lucky you to have found a place that allows those inquiries. Not many exist anymore.

agentultra 3y ago

5 Whys, or as I like to call it, "Jumping to Conclusions." Viewing the world as a direct line of causal relationships is called, "making a story." You can take it all the way back to the beating of butterfly wings if you'd like. It's also quite ineffective at addressing systemic issues and connected relationships. An alternative approach to post-hoc rationalization is to look into the factors that contributed to a particular outcome (or recurring set of related outcomes) and determine relationships between them: there are often systematic reasons for particular outcomes and not a singular event. Systems are not set up like dominoes in neat rows. It's usually much more messy than that. You can follow such a causal chain a few steps and say, "look I found the root cause!" But you won't solve the problem if you don't identify the systemic factors that lead to such situations. Even if you apply a solution to that root cause, you may find the outcome happens again -- it just finds another way around your patch, sort of like a cartoon of character trying to fix a leak in their plumbing by covering it up. To really solve the problem they need to turn the water off at the entry point, reconsider the plumbing set up, and fix their budgeting so that they allocate funds to preventative maintenance. Instead we get to laugh as they get squirted in the face over and over as they try more elaborate schemes to plug all of the holes. An example of a common factor in software development: leadership that prefers features shipped on a deadline. They will do anything to ship by the deadline. There may be a right way to do things to prevent errors in the system but not acknowledging this when an issue comes up, by jumping to conclusions about root causes, means your team will be constantly fighting fires in your production environment instead of taking the time to write specifications and modelling them and properly testing things. You may feel good about finding that one line of code that caused the outage. You may apply the patch and be the hero of the week. But it's not a matter of if another outage will happen but when because you haven't addressed the confounding factor that causes situations like that to happen again and again. If it doesn't get addressed then the leadership will find other post-hoc rationalizations for why these situations keep happening where the development team is, "getting slow." To take it back to the article: if people are ignoring your advice constantly, are you going to find out why by stepping back through a causal chain to a root cause? What if you did find a satisfying cause and you address that issue. Does that mean people will listen to you or will you only get that one idea through before you notice the pattern repeating? I like the idea the article suggests of trying several things. It could be an issue like discrimination: notice that all of your colleagues are young, white, and male presenting? Does anyone else on your team that doesn't fall into that demographic get their ideas through? Maybe that's only part of it though. It could also be true that your ideas need work as well. Trying a few things may make all the difference. Ask why, but also look at the surrounding environment and see if you notice any recurring patterns or relationships around the incident. After all, you don't find the source of disease by following the individual; you need to find the patterns that lead you to the wells.

xpe 3y ago

See also "The problem with ‘5 whys’" by Alan J. Card [1] [2]. I've included some quotations below. The discussion of "distal causes" is illuminating. [1] https://qualitysafety.bmj.com/content/26/8/671 https://qualitysafety.bmj.com/content/26/8/671 [2] http://dx.doi.org/10.1136/bmjqs-2016-005849 http://dx.doi.org/10.1136/bmjqs-2016-005849 > The ‘5 whys’ technique is one of the most widely taught approaches to root-cause analysis (RCA) in healthcare. Its use is promoted by the WHO, the English National Health Service, the Institute for Healthcare Improvement, the Joint Commission and many other organisations in the field of healthcare quality and safety. Like most such tools, though, its popularity is not the result of any evidence that it is effective. Instead, it probably owes its place in the curriculum and practice of RCA to a combination of pedigree, simplicity and pedagogy. > In terms of pedigree, ‘5 whys’ traces its roots back to the Toyota Production System (TPS). It also plays a key role in Lean (a generic version of TPS) as well as Six Sigma,11 another popular quality improvement (QI) methodology. Taiichi Ohno describes ‘5 whys’ as central to the TPS methodology: The basis of Toyota's scientific approach is to ask why five times whenever we find a problem … By repeating why five times, the nature of the problem as well as its solution becomes clear. The solution, or the how-to, is designated as ‘1H.’ Thus, ‘Five whys equal one how’ (5W=1H). (ref. 9, p. 123) > This quote also makes the case for the technique's simplicity. Asking ‘why’ five times allows users to arrive at a single root cause that might not have been obvious at the outset. It may also inspire a single solution to address that root cause (though it is not clear that the ‘1H’ side of the equation has been adopted as widely). > ... > It is clear from the tree diagram that the causal pathway related to the wristband printer is neither the only relevant cause of the incident nor indisputably the most important. A serious effort to solve the myriad problems that gave rise to this incident would have to tackle a number of other causal pathways as well. > ... > There are many ‘correct’ ways a team might use ‘5 whys’ to assess even this one incident. And it is unlikely that any two teams would independently arrive at exactly the same results. This subjectivity is critically important because ‘5 whys’ focuses on only one root cause at the end of one causal pathway. > ... > Targeting only the most distal cause > Not only are users of ‘5 whys’ limited to one root cause per causal pathway, but they are also limited to selecting only the most distal cause (conventionally, the fifth ‘why’). There is, however, no logical reason to assume that this is always the most effective or most efficient target for intervention. > Actually, if it were possible to magically place a 100% effective risk control at any one point on the tree diagram, it would be best used on a proximate cause. For instance, making it impossible to administer medication without checking the wristband would render all the more distal causes moot for the purpose of preventing a recurrence. > And, while 100% effective risk controls are seldom available, an action plan that includes a proven26 (if certainly imperfect) intervention like a well-designed bar-code reader with a forcing function for patient identification (ID) is more likely to prevent another serious ‘wrong patient’ medication error than switching to a well-designed printer. > This is not to suggest that more distal causes are not appropriate targets for improvement efforts. In the example presented in figure 1, for instance, there is clearly a profound need to change the culture from one that is task-oriented and sometimes hostile to one that is outcomes-oriented and psychologically safe. The pervasive impact of such a culture change would be far more important than merely reducing the risk that this particular incident might recur; it would influence almost every quality and safety issue in the organisation. > And, in contrast to that powerful-but-difficult lever for shifting outcomes, sometimes more distal causes represent ‘low-hanging fruit’ that can be addressed while a more proximate solution is in the works. In figure 1, educating patients about why clinicians will be constantly asking them to identify themselves would be far from foolproof. But it would be fast, cheap and easy. And it might reduce an important barrier to best practice in verbal identification. > Appropriate targets for intervention may occur anywhere along the causal continuum and on any causal pathway. And efforts to improve safety and quality will often require more than one intervention targeting more than one underlying hazard. It is useful to identify all the key hazards that gave rise to an incident and ensure that each of these is either addressed or intentionally accepted. (See, for instance, the Options Evaluation Matrix.) But the use of ‘5 whys’ makes this impossible.