Cultural Avoidance of Engineering
Chris and Fred discuss the organizations that culturally avoid engineering. Those organizations that for some reason, never ask for the data, the math, the tests, the thinking or anything else that might actually help you understand why your thing fails.
Join Chris and Fred as they discuss the organizations that culturally avoid engineering. Those organizations that for some reason, never ask for the data, the math, the tests, the thinking or anything else that might actually help you understand why your thing fails.
- Cultural avoidance needs three things – (1) defendability, (2) transferral, and (3) no strategy. Defendability means you can (apparently) prevent other people from accusing you of not taking (reliability) engineering seriously. And this often means a brutal focus on process and checklists. Transferral means that you have transferred technical decision-making to so-called ‘technical specialists.’ Like ‘chief engineers,’ ‘safety guys,’ and the ‘reliability team leader.’ And because they aren’t actual leaders, they quickly devolve into people who complete these checklists. And then there is no strategy. As in, not spending any time on making communication, future-proofing or reliability engineering strategy. There might be plenty of posters on the wall saying how ‘cutting edge’ your organization is. But everyone’s calendar shows where they actually focus their energies …
- … and transferring decision-making always means risk aversion. If you are a ‘chief engineer’ in an organization that culturally avoids engineering, then you will almost certainly be the person that every engineering decision has to go to. Because the actual leaders are avoiding this decision. But the chief engineer doesn’t share the same accolades as the true leaders when the project is on time, on budget, reliable, and so on. But … the chief engineer will where the ramifications if something goes wrong. So it is in the chief engineer’s personal interest to overprescribe tests, demand perfect information, and everything else he or she needs to make a perfect decision. Which delays the program and costs money. Which makes them a pariah. And then repeat.
- Failure Analysis (FA) means analyzing failure. Not just replacing everything. Not just shipping out a new unit to a customer. Not just calling it as an outlier until the financially crippling body of evidence (… think fleet recalls) forces you to conclude otherwise. Working out why things are failing is not a ‘PhD thesis.’ It is good reliability practice.
- Bureaucratic groups (like militaries) are the worst at this. Big call. But most reliability professionals know this. For whatever reason, meeting budget, schedule, committee approval, governmental approval become the most important things for a particular project. And what we are trying to accomplish gets completely lost. Which is understanding why our thing will fail. Not hoping it won’t.
- Understanding the mechanics, the math (you know … the first principles) makes you uniquely useful across all industries. If you focus on this – people will think you are a savant! But you are not. This is critical thinking. And critical thinking can sometimes cause immediate delays. It might blow out what you were hoping to achieve this week. But … this might save you years and millions of dollars of failures later on. Organizations that avoid engineering are always the ones that deal with atrocities later on.
- Leaders of organizations that don’t avoid engineering decisions show that they value engineering. If the CEO asks an engineer to take them through, step by step, how a simulation was performed to show that fatigue cracking was not a problem … then the CEO shows to that engineer how valuable making something reliable is. But if the CEO only ever talks about time to market or launch dates … then that powerfully shows that is what matters. And human beings are really smart at picking up on this.
Enjoy an episode of Speaking of Reliability. Where you can join friends as they discuss reliability topics. Join us as we discuss topics ranging from design for reliability techniques to field data analysis approaches.