The role of a reliability engineer is to support the other engineers and managers as they make decisions concerning reliability.
Our ability may be well honed and effective. Or it may be fumbling or annoying. It is our ability to communicate along with our technical ability that determine our ability to influence well.
We may do analysis or testing. We follow up on failures and evaluate suppliers. What we actually are doing is influencing decisions.
Starting the Discussion
When I first starting working with HP I was assigned to support a new business inkjet printer development team. The 326 page product requirements documents soon landed on my desk. It did not have a reliability goal.
It did have cost, time to market, and functional specifications. It did have information about the environment and how they expected different types of customers would use the product.
It mentioned it should work for 5 years on page 124. It included the warranty duration, 1 year. It included little else concerning reliability.
Asking a senior engineer, Jerry, on the team about the lack of a reliability goal, he recommended that if I needed one, that I just create one.
What? I’m just assigned to the team, a new hire, a junior engineer, who was I to set a goal.
Jerry said it the goal is good enough for the development team they will use it. If not they will change it. Not having a reliability goal is not even missed at the moment. Having one will start the conversation.
So, I did a little math. Talking to a few other members of the development team, and crafted a simple reliability goal. Something like 98% of printers will survive 5 years. (Note: figures are not from that printer project) Then referenced the environment, use profiles, and functional specifications to round out the reliability goal statement.
The next development team senior management meeting included an invitation to me to attend, and it included a length discussion about the reliability goal. It didn’t change. They accepted the goal.
The discussion was around how each department on the team had to respond to now having a goal. Some included checking with customers if it was good enough. The mechanical, electrical and software teams discussed challenges to achieving their allocated goals, and a plan to achieve the reliability goal started to take shape.
When not finding an answer to a question, I created one. Sharing the goal had the desired effect of having a reliability goal for the project, plus it started the conversation around achieving a reliability goal.
Sometimes just asking a questions, sharing a target, or exploring an idea, creates the desired result.
Understanding Your Audience
A big part of influence is understanding what is important to those you want to influence. If your proposed course of action impeded their ability to succeed, in their opinion, your proposed change is not going to happen.
Different people have different motivations. Some work for money, position, power. Some work for the personal satisfaction of doing a good job, learning something new, or simply to support some other endeavor.
With a development team the motivations may be driving by cost, time to market or technical wizardry.
The individual and team drivers may become tied together. For example, if we ship the product on time, the team receives a bonus. Those motivated by money may work a bit hard to hit the shipping timeline. Those motived by learning something new may chafe at the lack of time to explore a new material.
Crafting Your Message
When making a recommendation, do your homework on both the team’s driving motivations along with the key decision makers’ motivations.
Presenting the recommendations such that it reduces the risk of delaying a project thus helping the individuals to receiving their bonus, that helps those so motivated accept the proposal.
The hard part is including how the proposal benefits those with different motivations as well. Knowing what is important to the team and to individuals helps you prepare and present the ideas in a way that is heard and acted upon by the team.
Instead of recommended the team include two prototypes for HALT, recommend we discover potential failure mechanisms earlier in order to have time to learn how to mitigate those failures. Thus, we can minimizing the chance of finding those issues late in the project thus delaying the launch.
Connect the report, results, recommendations, and proposals to what is important to the team, business, customers, and decision makers.
Bio:
Fred Schenkelberg is an experienced reliability engineering and management consultant with his firm FMS Reliability. His passion is working with teams to create cost-effective reliability programs that solve problems, create durable and reliable products, increase customer satisfaction, and reduce warranty costs. If you enjoyed this articles consider subscribing to the ongoing series at Accendo Reliability