Article #7 The hitch is on the Carrera

Picture of Adam Bahret
Adam Bahret
Screen Shot 2021 07 21 at 6.51.24 PM

Ok, we hit a milestone in the Carrera UC7 article series! A completed hitch, ready to haul some stuff. One step closer to hauling a boat around on top of this thing. But, it’s not all high fives and confetti, I do wonder about how safe my daily driver is now.


Ok, we’ll get to safety later. What insights in product design and reliability were gleamed in this chapter of our journey? It didn’t take long to figure it out; it was a very familiar feeling, frustration from over constraint. Simply put, “It’s very difficult to successfully add features to an already completed design.”

In this case, that challenge had two essential questions at its center, “How do I transmit high force from a hitch to structural points in a chassis when the back of the car is designed to be a crumple zone?” then, “Where should I install a hitch on such a low car with a motor in the rear?” The back of the 911 is stuffed with the entire exhaust system, coiled at the bumper and rear panels into what looks like a nest of snakes.

Yes, I knowingly marched myself into this situation, but the resulting struggle is no different than when marched into it by leadership. That is a circumstance I am all too familiar with, and I have a feeling you all can relate too.

The reason for my frustration is simply that the options for a correct design are very limited. In my case, I am starting with a released product and adding a rather extreme feature. Yet, even outside of my specific situation, this type of “band-aid” solution to a problem occurs often. 


This leads us to ask, “Why do product development teams end up in these types of situations so often?” Well, It’s not just from crazy post-release feature requests. From a reliability program perspective, I can give you two reasons. The first is omitting measurement tools in the DfR process, and the second is dismissing the importance of found issues.


Let’s get into how these band-aid solutions happen, omitting measurement in DfR:  When the mid-program schedule squeeze starts, it’s the “measurement” tests that most often get pushed aside. These tests take the most time and the returns can be hard to understand by those inexperienced in leading a robust design program. 

What do I mean by “measurement” tests? As m

any of you know, I use the word “intent” when defining actions. All reliability tests can be described as having a balance of two intents: “measuring” and “improving” reliability. For example, by

 my estimates, I would say that HALT has an intent of 90% improvement and 10% measurement.  ALT is 80% measurement and 20% improvement, while Reliability Growth is an even 50/50.  


Understand that these measurement-focused tests are a critical link in a closed-loop control system of smart product development. Our phase-gate process requires inputs from reliability.  It’s paramount thatwe learn as early as possible if the design is not sufficient.  Every milestone we pass where an existing issue is not found only makes correcting the issue down the line exponentially more difficult. 

In summary, disconnecting these measurement tools from the phase gates leaves us flying blind, so to speak.  Leadership ends up approving program phase gate advancements and making expensive investments in fundamentally flawed designs.

The result is a team that will get called back into doing major redesigns on a configuration that should, by this point, just be getting tweaked for production or may already be out in the field.  Constraints such as, not changing any of the tooling molds or not touching the standard qualified electronics will be set as guidelines. 

Any solution that can be created under those conditions will be highly compromised.  The result will always be a patch and a prayer at best.  What makes it even worse is that this solution costs the company 100X what a better solution would have cost if done earlier. 

Those tools that have “measurement” as an intent should be protected.  This isn’t to say that they are untouchable, like being on some endangered species list, it means that the consequence of compromising them has to be apparent to those considering removing them.

Here is an example. As you saw above I listed Accelerated Life Testing (ALT) as an 80% measurement tool, thus making it one of our vulnerable species.  It will provide projections on when the design’s primary wear-out failure modes will occur. This is a big deal because this failure mode is indicative of the entire population.  The life of any product that has worked flawlessly will end this way. Wear-out is a design characteristic, not a defect, basically the equivalent of dying of old age.  What if that wear-out failure mode, by design, is unintentionally at six years instead of 15? The results would be catastrophic.  

So, if The ALT testing is going to be delayed, cancelled,  or resource cut then the connection to the long-term risk effects must be present at the time of that decision.

This is the responsibility of the reliability team.  The reliability team must be able to communicate what is at risk if the test results are delivered later than planned.  This analysis can’t be put together at the time when it is already needed, that is too late. The reliability team should be keeping updated risk and confidence analyses relating to each major reliability activity throughout the course of the program.

Moreover, that information must be at hand at all times.  If the project manager sideswipes everyone in a steering meeting with a push to get to the next gate despite a lack of results, the reliability manager must be able to pull up the associated risk of that decision in the same discussion. In other words, these analyses help the leaders make good decisions based on complete information. 

Without them, those ALT test results may come in right after product release, driving a frantic effort to design out the premature wear-out failure mode in a highly constrained situation. It’ll surely be a bad solution and an expensive one at that.


The second scenario is driven by dismissing found issues in testing. Issues found in reliability tests are not always addressed and, of course, we aren’t going to pull the emergency brake every time we find some form of imperfection.

There are many responses to a found issue. It may be a simple adjustment, cost increase by a component redundancy strategy, or a feature adjustment. In these cases, there may have been a compromise in permanently designing out the issue, and that’s fine, as long as it was the correct decision to make for the product factor balance. 

However, what is not acceptable is knowingly releasing a product that will surely come to have major issues. This is done more often than most of us would like to admit.  This is 

usually sold as “we will fix it right after release, you know, a 2.0.”

“So, we are releasing a defective product that will have high warranty cost, disappoint the customer, and likely drive a recovery phase in the program all just to meet our schedule?” Th

e response:  “Yes.”  That was a real conversation I had once with a senior manager in product development. Not kidding.

Circumstances like this, of course, result in the exact same situation I’m stuck in now, pondering an overly constrained problem and coming up with compromised solutions very late in the game. 

I think we can all agree that, to an outside observer, it’s pretty stupid to make a product development team work in a similar manner to an individual figuring out how to add a high load hitch to a section of car intended to be flimsy to protect occupants in crashes.  

So why, you might ask, when we are in the midst of a program, does this not seem like an obviously crazy scenario to avoid? I can tell you. It happens because we let individual roles carry individual goals, as opposed to the full product goal set. 

If an engineer, project manager, R&D manager, Director, or VP holds only part of the program goals there is no chance the product released will match the product planned. These individuals holding individual goals will compete with each other.  Competitions have winners, which means they also have losers. 

This results in a program directed under forces that in n

o way could represent the intended product goal balance that was created at the start to grab maximum market share and delight customers. The trick for top leadership is to find ways to ensure that all the roles in an organization hold all the goals of the product.

How do we do that? Well, there are many tools that can help. But for the sake of brevity, here is the one that matters most.  In weekly program meetings, ask the team how they are advancing each of the program’s goals. Keep that objective front and center with public commitment.  For example, “Mr/s Project Manager, what are you doing to ensure that we demonstrate our 80% confidence in our 99.94% reliability goal at release?” or “Mr/s Reliability Lead, what are you doing to see how we can co

mpress our test program to get us to market faster?”

That change alone reinforces that the team is accountable for the full product goal set, just the same as the C-suite, the investors, and the brand. It’s one simple step, but the first of many that will lead to an organization building the products they intended. 

So, what am I left with after managing to add a feature to an already released product? Well, I may or may not have a sufficient and safe crumple zone on a car I drive every day.  Crumple zones are very precisely designed “mechanisms” that absorb the correct amount of impact force to reduce force to the passenger, me. They do this all while keeping the central structure of the car intact. This central structure is what protects 

from the forces that exceed what can be handled by the crumple zone.

There are two remaining concerns regarding what I currently have after the hitch addition. The first being that the large aluminum bumper beam now has a reinforced steel center section, it will not bend or absorb load as intended.  Its shape and material were very carefully calculated to respond in specific ways in specific types of crashes.  How will it respond now that it has a very rigid center section? No idea.

The second is the sheet metal structure that that beam is attached to.  I will be putting cyclical high loading through all that sheet metal to transmit force to the inner body structure from the hitch/beam.  Will that cyclical force weaken the crumple zone sheet metal?  It’s meant to be flimsy to absorb force. As engineers we know that when you bend flimsy things back and forth they tend to break down pretty fast.  Have you ever broken a steel coat hanger by just bending it back and forth a few times? Yeah!  I may be doing that to the part of my car that is supposed to protect me when a truck runs into me at a stoplight. 

So obviously if a Porsche Carrera had a design spec to include a hitch, the crumple zone would be designed differently. It would have some means of permitting a central structure that carried the hitch load to maybe the drivetrain or suspension structural sections. But, of course, then it would collapse at a specific level of impact so that the energy absorption intent function remained. 

Anyway, I drive my band-aid solution to a problem no one asked to have solved around now. Yes, I added that cool towing capability, but it’s clearly not a well integrated solution and compromises other functionality.

As a result, there is a slight nagging feeling every time someone comes up a little too fast on me at a stoplight.  Is that crumple zone only a fraction of how strong it used to be? What happens when the steel center section of the hitch get’s driven all the way up into the motor which is pumping fuel and hot oil?

Sounds crazy to imagine putting yourself in that situation on purpose, but companies do it every day, just crossing their fingers and hoping for the best—and that everyone else has good brakes.


I, of course, didn’t accomplish this alone. As you may recall, Ryan Liu at Acorn worked with me to design a hitch that gave us the strongest pulling power. Then Joe Schwendler, Shawn Kendell, and Harsha Jogdand at Hypertherm manifested our design into reality using Hypertherm’s plasma cutting technology. No matter how many times I see the results, I am always amazed at how the plasma cut edges look machined. Even the small bolt holes looked as though they were perfectly drilled. Amazing.


Share this post