How I Almost Got Punched in the Face
I didn’t realize it at the time, but I was pretty close to getting slugged. I’m not kidding, in hindsight, it could have easily happened. I had just left the company I had worked at for ten years, where I built my first reliability department. I was three weeks into my new role at a medical device company and was brought in for one reason, “build a reliability department and get all program reliability initiatives centralized.”
You see, at my previous company saying that “I” built that reliability department is a bit of a fib. When the company asked if I would be a leader in that initiative, leaving the R&D FEA group, I enthusiastically said yes. You see, I had recently discovered reliability engineering due to researching and writing a few internal papers. The company knew they needed to get more serious about it and had requested I do so. Well, both the company and I liked what we found and consequently they wanted more, a lot more. So they grabbed a 30-year expert in reliability from IBM, moved him to Massachusetts and under his tutelage, we built a reliability department of 12 people along with two large labs. We had jurisdiction across all products new and old.
I was supposed to be the “heir apparent” in this story when he decided to retire.
But here is the problem, I hate being static and could see that my destiny was to either run this department indefinitely or climb up the corporate ladder. The department was the correct size and I didn’t want to be an executive. In fact, the thought of it killed me. I’m an engineer and yes a leader, but a sleeves rolled up kind of leader. I’m such an engineer through and through that most of the time when I don’t like the work I am doing on a given day, I incentivize myself by knowing that what I am doing today is going to bankroll that home engineering project I obsess about. In other words, I do engineering to fund engineering.
Do you want to hear something wholeheartedly true? I swear what I am about to tell you is the truth, there are several hundred people who can verify it, and, in fact, that was the point. In my wife’s wedding vows she included, “... and I take this man knowing that much of my home will be disassembled, modified, re-engineered and sometimes left in pieces…”
Anyway… I clearly would wither and die if I was an exec and I surely didn’t want to just manage a department that didn’t need to grow any larger. So I heard about a medical company, 50 years old and very successful, that was looking to consolidate reliability initiatives and methods across their product lines into one department. We were a match made in heaven. I get to build a department from scratch again and they get a pretty awesome reliability department. Sounds like a fair trade.
So, back to how I almost got punched. I came into work the first day ready to make it all happen.
As a reminder, I had just left an organization that had gotten into the rhythm of having reliability as a part of the design process. However, I had forgotten how long it takes to get there. All the initial resistance and slow changes. How each initiative had to show value before anyone would go on to the next one. The biggest “miss” was that back at the old company there was a very smart and experienced gentleman at the helm with over 30 years of experience navigating this journey. I was acting under his wisdom.
So, untethered I quickly found out that I didn’t fully understand what it took to integrate reliability into an established culture. Basically, I only knew how the process would work. Most of my previous career experience, R&D FEA, didn’t require consciously demonstrating value, marketing, or careful joining of deliverables into other people’s work.
I started pushing the reliability toolkit based on what I saw as risks in the design reviews. I wasn’t reading the room well at the time, but there was a silent protest brewing from day one. The design teams knew that the VP had brought me in, so a sudden hard pushback could be met with repercussions from leadership, hence the silence in “silent protest.” Head nods and then ignoring my input altogether was an easier path for the team, at that time. Like I said, I wasn’t reading the room well these first few months. That silent protest was headed towards becoming a full-on torches and mobs situation if I kept the reliability initiative going the way it had been.
My moment of clarity came when an engineer, Mitchell, ignored me in a meeting. I was speaking to him and he acted like I wasn’t even there. He left the meeting quickly and I followed him down the hall to ask what was going on and why he wasn’t interested. He spun around with a very angry look in his eye and what looked like a closed fist. I decided to just let that conversation go. I knew Mitchell was a good guy and I needed to take a step back and better assess the situation.
I stopped pushing reliability for a bit and spent more time understanding the program and what was going on in great detail and in all aspects of it. What I found is that the schedule for the designers was crushing. They weren’t allowed much latitude when issues came up to extend the schedule. Problematic designs were being pushed out into the field and then the team was sent out there to clean up “their” mistakes. They were stuck in this horrible cycle of being forced to make quick and dirty designs, being publicly humiliated for doing so, then spending time away from their families with angry customers in foregin countries trying to fix problems with little to no resources.
Even worse, they all knew that the reward for this was starting the cycle all over again with a new product. The worst part is that the new product wasn’t going to be a great advancement in technology. More than half of the design initiative was going to be permanent fixes for the band-aid fixes that were all over the current product they had just released. How much fun is that?
Now I understood how showing up and abruptly asking them to add reliability tasks to this mess was infuriating. They wanted help from their VP to make the product development cycle better and instead he grabbed an expert that is going to come in and give them more tasks to do, all with no schedule extension or accommodations for addressing the issues the tests find. Basically throwing someone supplies to build a boat while they are drowning.
The right process is as follows.
Step 1: throw me a life jacket, Step 2: pull me out of the water, Step 3: let’s build a workshop, Step 4: teach me how to make boats, Step 5: provide materials and tools to make a boat, Step 6: give me time to make and test the boat before we set off to sea.
I was throwing nuts, bolts, raw steel, and a MIG welder at a guy barely treading water and then was baffled as to why he wanted to punch me.
Here is how I switched to recon mode to better understand what was happening and figure out how I could really help. I attended design reviews and did not say a word. My only reason for being there was to learn and I was appreciative they were including me. I went out to the field with the engineers to help solve problems. This included doing it on one day’s notice sometimes. I started driving reliability initiatives “up” instead of “down” or “lateral.”
My reliability initiatives were now more directed to the ones who brought me in, the VP, project managers, and Directors, even the CEO. I went to the Friday executive steering meetings. That is where I made my points and requests regarding reliability initiatives. It was clear, something had to change there first.
By the way, the engineer that wanted to punch me, Mitchell. Well he was sent off to Milan Italy on an urgent assignment to figure out what was causing a sudden failure mode surge. I offered to join him to see if I could be of assistance (as his assistant). He didn’t seem to like that idea but knew it would be weird for him to protest such an offer.
Once on-site he saw how hard I was willing to work to help him figure out what was going on. He now understood that my pushing in those design reviews over the past few months wasn’t just to “be in charge.” He knew I just wanted to make better designs, just like him. I knew after that trip we would not only be good colleagues but good friends.
The good friends part was a done deal after our final dinner in Milan. It was a celebration dinner because we had figured out the issue and corrections were already in motion back home from our findings. I decided to entertain him and told him I could calculate “pi” by throwing bread crumbs in the air and using the principle of a Monte Carlo simulation to calculate it.
He wanted to see this, so I set up a plate and a napkin in the right orientation and started throwing bread crumbs. I was using where the bread crumbs landed as a random number generator. I had to count the ratio of plate lands vs napkin lands. The geometry of how they were set up was the equation.
We had already split a bottle of wine and within minutes, buzzed Mitchell was laughing so hard that he couldn’t breathe because of this ridiculous display. Not to mention the fact that I kept forgetting the ratio of plate to napkin lands and had to ask him if he remembered. He was also contending with the ridiculous spectacle of an American engineer (read crude and awkward socially) throwing bread crumbs up in the air at a high end restaurant in Milan, the fashion capital of Italy. Yes, I do kid’s parties.
So I came into that organization with a, “Get out of my way I’m on a mission from God!” disposition (Blues Brothers anyone?), which, through trial and error, eventually developed into a “how do I help engineers do what they were born to do by changing the landscape they operate in” mindset.
It was a big shift, but has had tremendous impact in how I can drive Design for Reliability to create great products today.
-Adam
P.S. If you want to know how the bread crumb pi calculator works email me abahret@apexridge.com
Was this article interesting to you? You can sign up and have these articles dropped right in your inbox. Here is the super slick sign-up page.