We all would like a clear path to achieve what we need. But we all know that it’s not the clear sections of the path where we spend most of our time. In product development many of these events we label as “obstacles” are in fact other individuals.
If these team members are noted as being strong enough to be considered an obstacle that means they have strength. This is a good quality in a team member. If we were to get ourselves headed in “generally” the same direction a lot of progress could be made very quickly.
If the program is pursing a goal then there will be some distance to travel and we will be taking the developing product with us. As an individual who wants the program to succeed we begin picking up pieces taking them with us and assembling them along the way. Working with individuals who work slow or have mediocre passion slows you down because you have to carry their responsibilities or wait for them to often catch up. It’s wise to avoid them. This can sometimes be difficult because they are usually the most fun to be with, which sometimes is their defense strategy against being called out as a low contributor.
With the adversary we dig in and brace for the conflict. It uses up our energy and lowers our moral. Stopping for a moment and reframing what is going on here can make a big difference. Consider what makes someone engage with high energy. Your “adversary” clearly cares greatly about something in the program. If not then why do you see them expelling so much energy in their role? It’s enough energy and passion to take other’s head on, same as you. What do they care so much about? What are they ultimately trying to achieve, success of the product, happy customers, success of the company, personal career success?
All of those are likely on your list as well. The difference is what you and they believe are the interim steps to get to those goals. Much of this has to do with your individual roles and personal backgrounds.
At work as a reliability engineer my adversary at a specific point in the program may be a R&D technology leader. Even though they may be an adversary we both want the company to gain new market share, we both want this new product to be loved by customers, we both want to be acknowledged as a significant team member.
Where we may differ is.
The R&D developer believes
- This technology is not going to have a big impact on the market unless it is out there “right now”
- Customer’s will be tolerant of some issues in their hands for the first release because the tech is such a big jump in functionality
- The engineering team is good, really good, they don’t make big mistakes.
- If you really don’t think people think this just look at how surprised they always are when field issues pop up. I’m rarely surprised.
The reliability engineer believes
- Customers are not going to be impressed with new technology that doesn’t work consistently
- Releasing a highly reliable version of this technology six month late is much better, than releasing an unstable version now
- There is no such thing as an engineering team so good that they can create a highly reliable product without implementing standard Design for Reliability (DfR) tools. Would you fly in a new technology plane that the best of the best of the best engineers in the world developed, but didn’t do a reliability program on? No thank you.
What would happen if you, a passionate person, and your adversary, equally passionate were to align, just a little? Not fully align but just a little closer? It would be an amazing contrast to the two of you pushing against each other wasting energy.
There are a few ways to do this.
- Make some time to sit down together with this specific objective in mind and no audience. Maybe even a coffee shop.
- The conversation starts with each sharing what they are trying to accomplish and how they plan to accomplish it.
- Look for common objectives and come up with a combined strategy. “We both want market share to be gained in this product by introducing a cutting edge feature.” Discuss how important reliability is to the feature being perceived as valuable. You might find common ground that you both want to support.
The conversation may be like this.
Reliability Engineer (RE): “I believe that a more minor increase in technology that works all the time is a better strategy than a large technology jump that has a noticeable failure rate to the consumer.”
Design Engineer (R&D): “I think many of the tools we apply to these programs don’t impact the first generation product anyway and we always end up doing a 2.0 anyway based on customer feedback.”
RE: ” What tools don’t work historically?” (R&D): “HALT. By the time we get the results and suggested design improvements the product is already in the release stage. We get customer trial feedback at almost the same time”
RE: ” Let’s do HALT in two phases then. Once with legacy parts and sub systems and then once again when Beta is available. The first will give us some design input early on. if in the second we find robustness opportunities we can evalute them based on an ROI if fixed and driving a delayed release. If the ROI against the delayed release doesn’t make sense we can do the changes in 2.0.”
RE:” Let’s drop Accelerated Life Testing (ALT) to investigate wear-out. It takes a long time and has a low ROI because we do not believe this new feature will be driving the primary wear-out failure mode. We can take the risk of skipping ALT and not delaying release. We will also be able to stay ahead of field wear-out failures by initiating an ALT program when the product is released and high quantity for test are available. If we find a concerning change in wear-out we can do a field replacement before customer units demonstrate the issue.”
Maybe the R&D engineer will see that there is a middle ground for some reliability issue mitigation and small delay in release.
The Reliability engineer may see that not every known reliability issue or risk has to be fully addressed before the product is in the field.
Maybe the two can select a common compromised program structure and tool application, becoming two forces going in a similar direction. Imagine that, and imagine the impact to the program.
-Adam