Solve your big problems by solving your real problem

Everyone likes to rant about lobbyists and lobbying, which are strange names for something Thomas Jefferson chose instead to call "petitioning government for redress of grievances".

Is it that you just dislike it when other people exercise their rights? Is it that you don't bother to exercise those same rights yourself, and so they shouldn't be allowed to do so either? Or maybe it's just that they're better at it and that seems unfair to you?

Seems to be called lobbying in the US.

> Government, acting in the best interest of their citizens, were trying to curb an addictive substance. CEO of generic tobacco / drug / oil / gambling company, realizing that this would hurt their profits, decided that the best way forward was to effectively bribe those in power to put their company's profits over the well-being of society.

If this is true, I'd like to thank the author for inadvertently pointing out the real source of the sports gambling problem: people like Jason Robins.

We don't have a sports gambling problem, we have a greedy CEO bribing lawmakers problem.

There is a reading of this story where draftkings helped lawmakers make better laws. It doesn't take much sceptisism to read it differently admitedly, but the plain text doesn't state that.

Generally speaking, the major problem isn't that some people do this (though some do in bad faith). The larger problem is that most people don't (and even fewer do so as concrete problem solvers).

Let's delve into this "problem" of addictive behavior and think about root-cause-problems.

- people are unhappy in their lives and fall into addiction

* they have too many opportunities for abuse

* there's something really wrong in their lives that needs solving

- lawmakers fail to make laws that reduce addiction

* lawmakers are persuaded by lobbyists that act for profit, because the latter have good arguments or the former are easy to convince/bribe

* they don't understand addiction because they are ill positioned for that job

Above can be broken down further into core problems, that should be tackled. My point being, it's not necessarily a bad example.

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: :(

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.

[1] https://qualitysafety.bmj.com/content/26/8/671

[2] 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.

What are the features involved in success, which ones are levers that can be pulled.

Realizing everything is an abstraction for another thing that is yet another abstraction is in a way a freeing realization.

The advice isn't even consistent. He says that you need to break things down into a "one-word" problem, because anything bigger than that is too hard and abstract. And yet, his little template to fill out "I don't have a ___ problem, I have a ___ problem" gets filled out with single words in each instance!

"I don't have an acceptance problem. I have a communication problem".

The latter is somehow preferred to the former. Why?