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.
Politically I tend to be more middle of the road these days. I attribute this to the definitions moving and not my perspective. My stance is usually influenced on what is going on in the country at the time. There are times when I leaned more conservative. Early ’80s Reagan was a good pick, Early 2000’s Obama was a good pick. Putting in left and right steering at the correct times to get to a goal has always been my strategy. I really have never understood people who say only steering in one direction is good. Sounds like a good recipe for inspecting a ditch.
I was once sitting at a coffee shop and working. It was about ten months after the 2016 election. Sitting next to me were two gentlemen having a conversation. They were loud characters having a fun conversation. Clearly old friends. If I had to guess their occupation and age I would say machinists and in there 60’s ( I was actually close on both) They weren’t’ talking politics but listening to the things they were talking about and their general perspective I could tell they had very likely been Trump voters. Being a little bold ,and clearly needing a break from work, I interrupted them and said “I heard you guys talking and love learning about what people think. My peers are generally very liberal so I get to hear a lot about what they think. I’m middle of the road. I suspect you both voted for Trump.” They gave a mildly suspicious “yes” in reply. They both looked like they were bracing for an argument. I then said “What are two reasons you voted for Trump and how do you feel he has progressed towards those goals so far?” They were surprised but also really pleased someone was asking them sincerely what their opinion was.
After they told me what they thought about what was going on they asked me what I thought. We quickly discovered that we wanted the exact same end goals, pretty much word for word. The difference was what we each believed would get us there. That’s a lot different than if I told them my thoughts for best next actions for our country and they countered with how they thought we should get there. That’s just setting the foundation for an argument, #Thanksgiving.
By the end of the conversation they invited me to join them on a fishing trip to Alaska. It is one of the earlier topics they were 
discussing before I jumped in. I have always wanted to bow hunt Salmon and they said they have seen guys doing it when they are up there fly fishing (This would also give the wildlife wardens at the lakes around me a break on explaining how my version of fishing doesn’t comply with the intent of “catch and release”).
They then proceed to give me all the details on how to do a super inexpensive trip, how to get to the best spots, and who to talk to if I was going to plan the trip on my own. Our contact information was exchanged and we even volleyed a few emails talking about trip details that may someday happen for me. If we had all been politicians who could actually implement solutions I bet we would have come up with one or two ideas we all thought would get us to our common end goals.
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 individual product to be a great success, 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 could 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 evaluate 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 and become two forces going in a similar direction. Imagine that, and imagine the impact to the program.
-Adam
Leave a Reply