Knowing When To Ask For Help

Knowing when to ask for help can mean the difference between a successful project and an unsuccessful one. It can be the difference between managers wanting you on their projects, and teams actively blocking you from participation. So how do we know when it’s time to ask for help?

A few weeks ago, we were in Anaheim for the MD&M West show. It was day 2 and we were leaving our Airbnb just after 9am to travel to our booth at the convention center. We were driving Eleanor (my beloved Rivian R1T), an EV, which had been plugged in and charging overnight. When I attempted to remove the charging connector from the vehicle’s charge port, though, it wouldn’t budge.

“Uh-oh, this isn’t good”, I thought. I tried pushing it in further before pulling it out, I tried twisting it thinking maybe it had just caught a weird snag internally. I tried squeezing the release trigger harder. Nothing worked. At this point the anxiety was starting to build: the show was starting soon and we needed to leave.

A few of my team, fellow engineers, were with me. So, we did what engineers do: we started exploring and experimenting. We got a flashlight out and pointed it into the narrow crack between the connector and the charge port. Maybe we can see what’s catching with more light. We manipulated the plug in every which way. We even started tearing apart the frunk (the front trunk) in an attempt to access from the inside whatever was capturing the charging connector. 15 minutes later we were still stuck.

As my comrades continued working the problem, I decided to call Rivian support (which, by the way, is excellent). I got a support rep on the phone and two minutes later the connector was liberated from the vehicle’s death grip. Turns out the entire vehicle (not just the driver’s door) needs to be unlocked before the vehicle will release the plug. Doh.

This entire ordeal only took about 20 minutes, not a big deal in the grand scheme of things. And we probably could have shaved a few minutes off by calling support earlier. The principal I’m trying to illustrate, however, is that there are times when we as engineers try to solve problems that have already been solved, and spend a lot of unnecessary time doing so in the process. This is understandable: engineers like solving problems. It’s why we got into engineering in the first place. It’s fun, and solving problems is what any good engineer should be doing. A great engineer, however, knows when to work the problem on his or her own vs simply sourcing an existing solution.

Don’t get me wrong, working the problem on our own often leads to invaluable experience without which we rob ourselves of meaningful growth and education. On the other hand, I’ve had engineers who ask for help at the first sign of trouble and want to be told exactly what to do – that’s not a great way to learn and grow your skills. I often say that persistence beats brilliance, and it’s often the persistent engineer who figures it out over the brilliant engineer who isn’t willing to put in the time. Nevertheless, as in all things, there is a balance.

How do we know when we should continue working the problem ourselves vs when we should ask for help? I created the following decision chart to help guide the answer to that question:

Sometimes we may not know the answers to these questions. For this reason it is important to have mentors you can turn to. Spending 5 minutes talking through a problem with a mentor could save you 5 hours of work that someone else has already done. 

Justification for the time it takes to solve a problem scales with the value of the solution. Working the problem on our own is generally a good place to start as it leads to growth and new skills. It’s important, though, that we keep in mind how valuable the solution is as we work the problem. Low value solutions may not warrant more than a few minutes, hours, or days, while high value solutions may warrant weeks, months, or even years. Striking the right balance is key. And learning where that balance resides is a skill worth spending the time to develop.