Engineering-Design

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

 

Advertisements

Wow

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.

So Matthew Loew wrote an article about whether the Mechanical Design Engineer is a vanishing breed.  (Matthew refers to a “Design Engineer” but here in the Bay Area that is often a particular kind of Electrical Engineer, so I’m using the longer term.)  He’s looking at it from the point of view of someone doing the hiring, so I want to talk about it from the point of view of the person seeking to be hired.

I have always considered myself to be a generalist.  My undergraduate degree is from St. John’s College, whose program consists of what used to be considered an education, reading and discussing the classics.  I went there rather than a more conventional school even though I knew I was most interested in math and science in some form.  I made that choice partly because the students there were engaged and excited about learning in a way I didn’t see at other schools, and partly because I wanted to understand the basics and the beginnings and the underpinnings of things, and where else was I going to get to actually read and study Euclid, Ptolomy, Newton, Einstein, Lobachevsky and so many others, rather than reading a textbook?

After St. John’s I knew I wanted to study engineering, and I specifically targeted Stanford because of their emphasis on both aesthetics and performance.  While taking undergraduate engineering courses to prepare for applying to graduate school, I fell in love with free body diagrams and hand calculations (i.e. solving a problem, usually to find stresses, using pencil, paper and calculator, but not a finite element analysis (FEA) tool).  They were so cool!

I give all of this as a preface to comment on Matthew’s shock at someone saying about a statics problem, “I have not solved one of those since college.”

I’m a seasoned mechanical engineer, with a Master’s Degree and over 10 years of experience.  Not only that, but I’m someone who loved to do hand calculations and was extremely fluent in them at one time.  And I’ve done a hand calculation maybe once a year in all the time I’ve been out of school.  That’s probably being generous.  Could I do one today?  Of course.  Would I be as fluent at it today as I was when Shigley was fresh in my mind?  I don’t think so.

So why is that?  There are a couple of reasons.  When you work in a large company in a mature industry, your job tends to be very narrow.  There is the perception that if you’re doing only one function day in and day out, that you’re going to be especially fluent and proficient.  While there is some truth to this, there is also a big downside to so much specialization.  It can easily make someone become so narrowly focused on that one function that they lose sight of other aspects that affect the part.  Designing the perfect part for crashworthiness, for example, is completely useless if the part can’t be manufactured, can’t be assembled to other parts, or costs 20 times what any other part in the structure does.

So let’s say my job is working on side impact for safety and crash.  I’m doing FEA, I’m evaluating test setups to make sure they are correct, I’m correlating my analyses to test results, I’m suggesting design improvements to get the performance we want, I’m working closely with the stamping guys and the assembly guys to make sure my design improvements can be manufactured, etc.  But one thing I’m definitely not doing is doing any hand calculations.

Which brings me to the second reason.  When you’re working on something with a complex geometry such as an automotive structure, and the type of performance you are concerned with is the crash performance, or even separating out the primary normal modes of the structure from those of the engine, there just is not a hand calculation that makes sense.  Now if you’re working on a small component part whose geometry is fairly simple and the main concern is whether a human hand pushing on it will break it, then sure, a hand calculation is great, and will give you at least a first order answer.

From my point of view, the frustrating thing is that, even if you’re very  interested in being a generalist engineer, there is no career path for that.  On the one hand there is the factor of each job being fairly narrow, as outlined above.  So that would lead the would-be generalist to do a bunch of very different jobs.  Yet short of an admittedly impressive stunt like the San Jose recent graduate who did 50 jobs in 50 states in a year,  most employers would rather hire someone who’s already done the exact same job in the same industry.  This makes the mission of doing a bunch of different roles a very difficult one.  As a result people, even those who are actively fighting it, tend to get typecast into one particular role.

Robert A. Heinlein once said, “A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.”  I agree with him, and while there are things on his list I haven’t yet done, there are others I have done that he didn’t list, like milk a cow or weave a cloth.

I agree with Matthew’s list of what a mechanical engineer should be able to do.  But just because I haven’t done something lately, that doesn’t mean I don’t have the brains and the drive to figure it out!

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.