April , 2016
Lou Adler is an HR professional and author who writes on topics related to hiring. Two of his articles are Let’s Fix It: End The Talent Shortage by Hiring for Results, Not Skills and To Hire Better People Define The Job Before You Define The Person.
Lou writes that it’s what you DO with what you have that makes you successful, not what you have. And points out that most job descriptions are what he calls “skills-infested”. They are lists of specific skills, tools, and experience. “X years experience in industry Y”, “Z years using CAD package A or CAE package B”, and “C years experience designing parts with manufacturing method D” are the types of things we see in engineering job descriptions all the time.
Instead, Lou says we should be asking, what do the best people do differently than the average person?
So, what do the best mechanical engineers and designers do differently?
- They know the right questions to ask to get things manufactured.
- They are fluent at thinking in three dimensions.
- They are able to break down complex problems into smaller more manageable problems to solve.
- They collaborate with others.
- They empathize with the customer in order to solve the problems of people different from themselves.
- They are willing to say, “I don’t know, but I will research and find out.”
- They are concerned for both the big picture and the small but important details.
- They keep an open mind, learn all there is to know about a problem, and then use their expertise to identify and implement a good solution.
- They are good at turning abstractions into working ideas.
- They have remarkable grit and an ability to use math, intuition, analogical thinking, and strong spatial reasoning to solve problems.
- They build stuff — working prototypes, computer models, building on the ideas of others, or even just folding a piece of paper.
- They utilize Design Thinking
- Most importantly, they have a curiosity and a passion for how things work, and they live, eat, and breathe figuring out better and simpler ways of doing things, including things in their day-to-day life.
Some examples that I recall:
- When I was doing some consulting work earlier this year, I was working on an assembly of vacuum formed parts. Since I had never worked on vacuum formed parts before, I did the usual research to find out parameters that I needed. Then I developed the parts with that information. Later, when my client and I were on the phone with a vacuum forming manufacturing company, the engineer on the other end of the phone surprised me by exclaiming, “You really know how to get things manufactured!” I thought this odd, saying that I did after all have an advanced engineering degree. She responded that she had worked with many people with advanced degrees who couldn’t do what I was doing. What I had been doing was asking the right questions — was the draft angle I used ok, what thickness did the material come in, what blank size did it come in, how much thinning could I expect with the geometry I had designed, and so on. It wasn’t about knowing all about vacuum forming, but about how do you approach a manufacturing process that is new to you.
- When I was at Magna, we had a small group of engineers all sending jobs to the same server, and a queue management system was not in the budget. I proposed and put into practice a “poor man’s queue management system”, in which we met once a week to establish project priorities, then documented them on a whiteboard which everyone could see, and used the unix “nice” command to set and change priorities as needed throughout the week.
- When I was on the GM EV1, one very contentious issue was whether to encapsulate the windshield and rear window. Encapsulation involves an additional manufacturing step — after the glass is complete, it is put into another tool, an injection molding tool, and the moldings are created by injection molding them directly onto the glass. This simplifies the installation of the glass, as there are fewer parts, but it also changes the way tolerances stack up. Since the encapsulation goes where the glass goes, there is no opportunity to use the moldings to help compensate for smaller or larger gaps due to tolerances. On this vehicle, direction from Design Staff was that the oval line of the roof was very important, and this line was the boundary of both the windshield and rear window. So someone laughingly made the comment that it would be better for us to encapsulate the roof, to help make that a consistent line. The engineer who said that was joking, because no one had ever heard of encapsulating a body panel, and assumed it could not be done. But even though the roof was not my part, I decided to research it as a serious option. I found that it was completely possible, and it would work well to accentuate the line of the roof, although we decided in the end not to do it due to cost.
- When I was at GM, I invented a new structural part to stiffen a joint in the Chevy Malibu and improve side impact performance. This was especially challenging because it was in the middle of a complex joint with many parts coming together and each having their own constraints.
- When I was at SC Solutions, the group was using antiquated methods for building models, while at the same time, model geometric complexity was growing. I was asked to research options to improve our ability to build complex meshes in a more user friendly way, and yet to continue to use the same underlying number cruncher software that we were using, Adina. I first confirmed that there were no pre-processors on the market that were designed to work with Adina. However, I realized that I could create a work-around, by using a pre-processor to write out a Nastran deck, then reading the Nastran deck into Adina. So I considered any pre-processor that could write out Nastran. I recommended we bring in two pre-processors. One of them was retained after the first year. I also developed a set of workarounds and wrote scripts that allowed the pre-processor and Adina to work together more smoothly. I taught and tutored others in the division on how to take best advantage of said workarounds and scripts. Several big projects were done using HyperMesh, one of the new to us pre-processors, and my boss, the head of the division, said it would have been impossible to accomplish those projects without my work.
- When I was at Altair, we found that the Software QA group was not always finding the same types of bugs that users were finding. Users of the software tended to be working with more complex models, where multiple aspects of the software interacted in more unpredictable ways. I came up with the idea of creating a set of “user-based” tests to more closely simulate how a typical user uses the software. Combined with the automated testing we were already doing, this resulted in much improved coverage and a higher liklihood of finding bugs before users did.
- Even when I am not at work I often find myself figuring out better and simpler ways of doing things. A couple of years ago I was in a coffee house that was my usual hangout, and chatting with one of the employees there. He was complaining about the task he was working on, which was writing the names of pastries on paper bags. This coffee house had the practice of selling pastries at a two for one price after a certain time in the afternoon. So coffee house employees would 1) decide which two pastries to group together, 2) put them in one bag, and 3) write on the bag the names of those two pastries, as well as a title like, “Better the next day! Two for the price of one!” (paraphrased). Said employee was complaining because this was his most hated and tedious task. I suggested that since they know the names of all their pastries up front, they could make labels for each pastry name, an additional label for the bag title, and substantially shorten this task. The employee liked the idea, but felt that management would not want to consider any variation in current practice.
What about you? Do you have examples of some of these qualities from your own career? Do you have other items that I did not list? Let me know in the comments.
February , 2010
Check out Leonardo da Vinci’s resume!
Although, it is really different than a modern resume in flavor, because it talks about what he can do, rather than what he has done. Something for those of us who are job searching to keep in mind.
October , 2009
The Mercury News has had two interesting articles recently on the topic of electric cars. This one, from Sept 17th, is a pretty good summary of electric cars that are coming soon, many made by big boys like Volkswagen, GM, Hyundai, and BMW.
Unfortunately I wasn’t able to find an online copy of the second article, but in some ways it’s even more interesting. The title: “Nissan to make electric cars hum”.
It turns out that electric vehicles are naturally very quiet. And since people working on cars have been struggling to make engines quieter for decades, it wasn’t intuitively obvious that there was such a thing as too quiet. But there is. Pedestrians tend to expect cars to make some noise, and especially kids, the elderly, blind people, or those listening to iPods may not notice a very quiet vehicle.
So the Nissan engineers started thinking about sound, and what kind of sound to add.
“We decided that if we’re going to do this, if we have to make sound, then we’re going to make it beautiful and futuristic,” Toshiyuki Tabata, a Nissan engineer, said. Then he and his team went out to consult Japanese composers of film scores.
Now that’s thinking about things in a new way! I’m so happy they didn’t just make a recording of a throaty gasoline engine. What they decided to do instead solves the problem in a much more interesting way.