A couple weeks ago, I published a post introducing Talent Management in the context of the engineering organization. I honestly believe adopting more efforts like these can be the difference in manufacturers recruiting and retaining top level engineering talent in their organizations. But instead of extolling the virtues of this type of initiative, I figured …
Engineering Executive Chris Weiss on Talent Management in His Organization Read More »
It feels like we’ve been talking about simulation driven design for a really really long time. Doesn’t it? The whole idea is to setup and run simulations of a product’s performance early in the design cycle and base design decisions off those results. This approach is in contrast to using simulation towards the end of the design cycle, prior to prototype and testing or even just prior to design release, to validate and verify product performance. It might seem like a nuanced difference to some, but theoretically it can make a huge difference.
It seems that lately there has been a lot of talent management issues in engineering. With that in mind, I came across an interesting article written by Jeffrey Pfeffer over at the Harvard Business Review called Take Care of Yourself First.
Today we’re going to hear from another manufacturer about their selection of a different CAD application: Solidworks. I had a chance to talk with Chris Weiss, the VP of Engineering at Knapheide Manufacturing, about a number of issues. In the following excerpt, he talks about the decisions process his organization went through selecting Solidworks.
If you’ve been reading posts here at engineering-matter.com, I’m sure by now you know I write a good bit about generational issues in engineering as well as the software applications and systems used in engineering organizations. As you might imagine, I started to think about these two issues in light of one another. Specifically, my mind started work on the question: how have different generations adopted technology in the engineering office?
In the last post on collaboration, we covered a lot of issues surrounding collaboration. It’s been overused. It’s been used without specificity. As a result, we all cringe a little bit whenever we hear it being trotted out to describe another process or set of engineering software.
Do you remember when you first got email? Mine was through work and I remember something clicking in my head when I realized what it meant. It’s changed the way we work. We no longer had to get on the phone to communicate remotely. It enabled faster and more accurate decisions.
Is the design engineer extinct? Perhaps, but I don’t think that’s the point. Are all of the activities that need to be performed in the development cycle getting done? I believe the answer is a resounding yes. I think the subtle theme in Matt’s article that’s never quite expressly said is whether or not those activities are being done by qualified individuals.
How do you feel about the term collaboration? I know. I know. The ‘sigh and roll your eyes’ reaction is a pretty common one. And in fact I react that way myself more often than not. Over the past ten years, collaboration has been used left, right and center to describe just about anything and everything in the product development realm. And as a result, no one really knows what it means anymore. Ask ten people for a definition of collaboration and you’ll get twenty back.