The Day I Decided I Need a Mentor, or How to Become a Better Engineer

“If I have seen further it is by standing on the shoulders of giants.” — Isaac Newton

One of the first tasks that I handled as a Project Manager (versus a Team Lead working with a group of specialists in a particular technical discipline) was lifting a wind tunnel model from its work stand and installing it in a calibration fixture. The calibration fixture was going to be utilized to calibrate the internal balance used to measure thrust and side forces that experimental rotors would generate during testing. I was feeling pretty good about my expanded role and felt I could handle the lift with no problems.

Straight forward task, but there were a few nuances that made the task interesting.

First of all, the model was 70K pounds and the facility crane was rated for 50K pounds. This meant we needed to rent a second crane and perform a two-point pick-up.

Secondly, because the model cost over a million dollars, the lift was designated as “Critical,”due to a potential financial loss if we dropped and destroyed the model. That kicked in a lot of requirements: all involved cranes had to be certified up to 150% of their capacity, the lift plan had to be approved by a number of stakeholder organizations (as well as the safety folks), and a number of other concerns we had to address.

About a week before the lift, we found out that the certification for the facility crane was going to expire a few days before the lift. Not a big deal, but we had to call out the contractor, who did inspections/certifications, and learn what the process was. The best we could do was schedule the certification the day before the lift. This meant getting the shackles that were rated for 75K pounds (where do I get those?), getting 75K pound cement blocks out to our site (how do I get those moved to the site and then get them removed before our lift?), and coordinating the paperwork trail for all activities. In the meantime, we were still trying to perfect the delicate ballet dance that we were going to do with the two cranes to get the model into the correct position.

A few days before the lift I was scheduled to go up to the Director of our code to give a status on the project and the preparations that we were making for the lift and the follow on calibration activity. I was joined by another Project Manager from our organization (more experienced, having successfully completed a number of test campaigns), who was going to give status on her own activities, and I suspect was scheduled by my supervisor to accompany me just in case something went “sideways.”

We sat down and I started my presentation about all the things that I have followed up to make sure we meet all the requirements of the “Critical Lift” as detailed in our manual. When I was done, the Director asked me a simple question: “What happens if, for some reason, you are not able to go through with the crane certification?”

BAM.

I spent all this time setting up the different processes, but I never considered that something might not happen the way I orchestrated it. What if the special forklift for the calibration weights is broken down? What if the inspector gets sick or just doesn’t show up for work? What if…

All I could say, and I knew it was weak when I said it, was: “There is no reason not to…”

My colleague came to the rescue with a simple: “Depending on the circumstances, we can get a waiver from the safety office. The crane will be out of certification by only a few days and we can get qualified eyes on the steel cables to insure their good health. There has been occasions when we got waivers before, and we can make a good case for it here if needed.” A simple statement that satisfied the Director and we moved on.

I didn’t know anything about “waivers.” There was nothing in any of the procedures that I read that even mentioned “waivers.” I thought: “Wow, I got A LOT to learn.”

Since then, every once in a while, I stop by the office of the more experienced Project Manager and describe to her what we are doing and listen to her thoughts on the processes involved. She is not assigned to mentor me, but she became my official “unofficial” mentor. Up to that point she hasn’t even considered the fact that she has anything to mentor anyone about.

I have come to realize that young engineers don’t seek out mentors for two reason. The first reason being simply that they “don’t know what they don’t know.” School should have prepared us for our jobs, right? We paid for four years (or more) of college, so now we know everything we need to know to start working and what we don’t know, we can “Google"…so, no need for mentoring, right?

I call this the “Ignorance Factor” and I have been “guilty” of it myself. I now realize that school taught me some basic engineering principles, taught me how to apply an engineering approach to solve problems, school even taught me how to use tools that some of the older engineers had no idea even existed (I still remember the delight one of the test engineers expressed when he saw me run a SPICE 3 simulation of the circuit we were designing), but most times, in order to do the best jobs we can on any particular project, we need not only the most up to date technical tools but also an understanding of the process involved, the policies in place, and sometimes even a little understanding of human nature (that they might have forgotten to teach in the Engineering 101 classes).

The second reason for not seeking out mentors is the “Generation Gap Factor,” also known as the “Arrogance of Youth.”

And before you ask, “yes” I have been guilty of that as well from time to time. I can’t speak for others, but at times I felt that I “knew better” than the “old timers” in the engineering pool. I think the “young” being frustrated and not having patience with the “old” happens with every generation.

My father grew up with letters as the fastest method of finding information, I grew up with the telephone, my son is growing up plugged into the world 24/7 through this thing called “the Internet.” He doesn’t want to hear any advice from me, because he can find all his answers with a touch of a few keys. I get it. But, when you get to feel a bit “arrogant,” please keep in mind that even though we might be more aware of the world around us because of the faster information paths, the only reason why we find ourselves in our current reality is because of the transfer of knowledge from generation to generation that has taken place for thousands of years.

Why not participate in this fine tradition?

I have also came to realize that most of the more senior, more experienced engineers are so engrossed in their own projects that it doesn’t even cross their minds to make themselves available as mentors. Most of the time, our focus is on our area of responsibility and we don’t think of how best to pass down what we know to others. Sure, if someone asks you a question, you will be happy to engage and explain something, but how many of you put aside time in your day to purposively mentor someone? To come into a junior engineer’s cubicle and ask how things are going and offer advice on the process or encourage them in their undertaking? Maybe scribble a formula that you haven’t used in years, but is the linchpin of a particular physical phenomenon that is being looked at? Maybe share your experience on how, many years ago, you approached troubleshooting a bad amplifier channel? Maybe tell them about ”waivers”?

Or maybe tell them where they can get a good cup of coffee?

I have been very fortunate to work with experienced engineers, from many different disciplines, who were willing to give me their time and share with me their experiences and knowledge…in the process making me better engineer.

Instead of making me feel like I was “re-inventing the wheel” every time a new issue came up, I started to feel like I was building on the solid foundation of tried and true solutions…what was that phrase about standing on the shoulders of all those who came before me? It might be a cliché…but it’s a cliché because it’s true.

To Manage, or Not to Manage, From the Perspective a NASA Engineer