Speaking Of Reliability: Friends Discussing Reliability Engineering Topics | Warranty | Plant Maintenance

Is reliability engineering becoming less attractive as companies cut costs, demand faster development, and turn increasingly to AI? This episode argues that the opposite may be true—but only for engineers willing to move beyond comfortable tools and established routines. Chris and Enrico examine why cutting reliability capability can actually increase cost and delay development, why late-stage testing cannot substitute for early prevention, and why technical expertise must translate into business value. They also tackle AI: not as a replacement for reliability knowledge, but as a powerful tool for engineers who already know enough to question, challenge, and improve its output.

Return Logistics and Failures Abstract Kirk and Fred discuss the challenge of getting field failures back to the engineers who can do detailed failure analysis. Key Points Join Kirk and Fred as they discuss how difficult it is to get failed products back and how many returns aren’t actually failures but still end up in […]

Weibull is Useful Abstract Kirk and Fred discuss the long-running question of Weibull analysis and whether it’s useful. Key Points Join Kirk and Fred as they discuss why Weibull is useful after failures occur in the field. Topics include: Weibull plots are used to determine whether a failure is an infant mortality failure, a random […]

GM knew its ignition switch failed an internal torque specification before the affected vehicles entered production. Yet the switch was approved, field problems followed, and an improvement costing less than $1 per vehicle was later rejected. Eventually, approximately 2.6 million vehicles were recalled, with enormous financial and human consequences. Chris uses the GM ignition switch failure to make a broader reliability engineering point: finding problems is not enough. Engineers and leaders must act while changes are still inexpensive. Earlier changes the economics—and waiting until testing or customers expose a failure can turn a simple engineering decision into an extraordinarily expensive one.

What does reliability mean when the customer thinks your product has failed even though it still technically works? And how should engineers measure reliability when failures involve software defects or patient safety rather than conventional hardware wear-out? Chris and Enrico continue their examination of reliability metrics by looking at customer ratings, brand reputation, medical devices, and software. They discuss why customer expectations matter, why medical reliability and safety overlap, and why software cannot simply be forced into traditional hardware reliability models. The discussion also highlights a growing systems-engineering problem: reliable products increasingly depend on hardware and software teams working together from the beginning.