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.