Your organization sucks at reliability if (#1) … it could be on ‘that’ Fatboy Slim album cover.
Alright … this needs a lot of context. English electronic music artist ‘Fatboy Slim’ released his ‘You’ve come a Long Way, Baby’ album in 1998. Its cover art was a photograph of an attendee at the 1983 ‘Fat People's Festival’ in Danville, Virginia. And perhaps due to its ‘heritage,’ the album’s cover was changed to an image of a bookshelf for North American listeners. But the rest of the world got to bask in its magnificence.
So what is particular about this photograph? The subject is a larger than average human (as you would expect noting where it was taken). And he is wearing a shirt emblazoned:
I’m #1 so why try harder?
I am not writing this as a commentary on human value versus instinctive stereotypes. Far from it. There are plenty of people who are ‘better than all others at something’ that do not have sleek chiseled physiques.
The shirt’s wearer looks like a fun dude. And no doubt there is a deeper sentiment to his wardrobe. Maybe the underlying message is that that all one needs in life is to be happy for themselves. Not to be happy for or because of you (the bystander). This is liberating and empowering. But it is not good if your organization is the one wearing that ‘hypothetical shirt’ at a Fat People’s Festival.
I am writing this article to start a conversation on the characteristics of organizations who suck at reliability. No matter what industry, people who make reliable products tend to do the same (good) things. And people who make products that break and otherwise disappoint the customer tend to do the same (bad) things.
So returning to the male model who appeared in Fatboy Slim’s 1998 album cover. Why is it fantastic that he is wearing that shirt, but it is certainly not fantastic if an organization thinks that they are ‘#1, so why try harder?’
Because organizations who make things need to make their customers happy. Not themselves.
I have been involved in many organizations throughout my career. In many instances, this has been as a reliability subject matter expert to help organizations improve their approaches to reliability. And there are many things that I have seen that are both good and bad. And trust me, organizations who think that they are already ‘good’ so there is no need to try harder always struggle when it comes to reliability.
One such type of organization is the one where people say (and believe) things like:
We make a reliable product.
Firstly, organizations who make reliable products tend to never say this. They are so focused on making whatever they have now even more reliable means there is no such thing as a ‘reliable’ product. There are only products whose reliability is improving. It is never where it needs to be … it just keeps going.
Those organizations who think they already make a reliable product more often than not are not trying to make it better. Why would you? It is already reliable. Making it better is a waste of resources. But who is making the call about whether the product is reliable or not? It is the organization – not the customer.
But (I hear some say), we don’t have complaints from customers. So we must be making a reliable product? Right?
Hell no. Customers who are not satisfied with the reliability of your product have either moved to another product, or never bought your product in the first place because someone else told them that your product is unreliable. Don’t believe me? Have a look at a consumer electronic product for sale on Amazon which has a number of two or fewer ‘star ratings.’ Prospective customers may not even click on your product to see how good it is because of these stars.
In my experience, organizations that think the products are already ‘reliable’ because they aren’t getting customer complaints (or the complaints they are getting are within ‘acceptable’ levels) tend to always have no idea about how their ‘reliable’ product became reliable in the first place. That is, they have no idea if or where their reliability guidebook is, who is responsible for reliability, or what Design for Reliability (DfR) tools should be applied at different stages of the product developmental life cycle. They also tend not to know what their product’s reliability is.
It happens all the time.
And for ninety-nine organizations out of one hundred, this is because these people are confusing general effort for specific outcomes. That is, designers work very hard designing a component that meets all the customer requirements, correctly dimensioned in CAD drawings, is made out of cutting edge materials, is reviewed up to ten times by other engineers and is manufactured in an ‘ISO 1 million’ certified workshop.
All this effort, and none of it focused on how it might fail. Failure is not an option for something that is the fruit of so much labor. Because all this labor focuses on building something that can work. Not something that will work.
If your organization is like this, you have a problem.
Think of all the people who are truly #1 at something. People like Lebron James in basketball, Rory McIlroy in golf and so on. The one thing they never stop doing is trying. These people are the ones who train like no one else. The ones who take rehabilitation and injury management more seriously than anyone else. Quite simply, they will try anything to make them better at doing the thing they are the best in the world at. They are never satisfied. And unlike our male model above, the measure of their success is based on a bunch of external rules they don’t control. Much like the laws of physics that govern how things fail.
So what can you do as a reliability engineer in a ‘Fatboy Slim’ organization? Be in no doubt - your job is very difficult. Because now you are dealing with emotions more than science.
The worst thing you can do is start by telling everyone that they are wrong.
No one takes this well. It is like a parent being told their child is no good. Engineers spend years and years building something, perhaps optimistically marvelling at how good it is, perhaps having a supportive network reinforcing to you how good it is, only for some reliability engineer to throw an ‘opinion bomb’ from a cubicle in an office where no component has ever been designed.
The first thing you (as a reliability engineer) needs to do is win management support. They too may be drinking the same coolade as everyone else. They too may do the easy thing and think that their product’s reliability is ‘good.’ So you need to be careful with them as well.
However, there is an upside. The management team focus on business strategy (or at least, they should focus on business strategy). So tailor your pitch to them accordingly. Perhaps you can demonstrate the monetary benefit of improving reliability performance from where it is now. And not just say that we will make money. Give figures.
When you do, it is imperative that you do your homework. Make sure you have spoken to everyone (from finance through to a worker on the workshop floor). Work out what company initiatives exist for ‘continual improvement.’ Describe what steps your organization can do right now to start walking in the right direction. And show how you have exhausted all avenues you have available to fund these initiatives. And finally, articulate exactly what the manager needs to do for you to execute. They will appreciate the effort you have gone to.
And when you structure this conversation, perhaps break it down like this:
Talk about the business strategy and articulate what you think it is if it is not clear. This shows that you are have a holistic perspective regarding reliability, and you are not a single issue zealot.
Then introduce a proposed reliability strategy with long term aims that are perhaps 10-15 years in the making. This should include a vision statement that is clear, measurable and unambiguous. Nothing open ended like ‘we intend to make the most reliable products.’ But more like ‘our aim is to reduce life cycle costs to $ 10 per hour used.’ This example is not applicable to every application, but hopefully you get the idea.
Initiate a reliability plan (which should hopefully be the first of many) that breaks down the strategy into smaller chunks. Each plan may (for example) last a single year with specific aims. You must have baby steps. Perhaps the first reliability plan you have is focused on ‘consolidation’ where the outcome is a robust reliability handbook for your organization that captures all the good things that are currently done, eliminates all the bad things, and introduces things that other companies do well.
And finally, talk about how these three steps improve reliability capability. This might include things from in-house testing through to reliability data management. Needs change between companies and over the years. So capability needs to continually change.
Once (if) you have management buy-in, then sell your message to the masses. Instead of language that focuses on saying how they have failed up until now, talk about why they can benefit from improving. Talk about commercial realities if necessary. Competitors are always improving, so why aren’t we?
If you truly have management commitment, you will also have resources to enact change. Management commitment that is nothing more than verbal shows of support is not commitment. Speeches by themselves do nothing more than allow managers to convince themselves they are taking reliability seriously (when they are not).
You, as a reliability engineer, must come across as being someone who is there to help. Not someone who is there to lecture. This means that the pitch we talked about above needs to support workers and engineers. Not critique them.
This is not straight forward, and a detailed discussion on the topic is well beyond the scope of this article.
But it is always necessary to know where you are before you plot a course to somewhere better. And if you know that you work in a ‘Fatboy Slim’ organization, that is at least a start.
My name is Chris Jackson and I help organizations do anything from solving ‘simple’ reliability problems through to facilitating cultural change that sees reliability baked into their products, systems or services. If you think I can help out ... please reach out to me at firstname.lastname@example.org. Thanks for reading!