Bridging Triumph and Trial: A Panel Discussion about Engineering with 'To Engineer is Human' and 'The Wright Brothers'

Anne Meixner, Dr. Vaneeta Kaur Grover, and Dianna Deeney join in a panel discussion about engineering and STEM. They met for an engineering book review to discuss the ideas that came from the books themselves and to link literature about engineering to current-day challenges.

Uncover the intricacies of engineering's past and present as we dissect To Engineer is Human and The Wright Brothers. Our collective expertise spans the gamut from semiconductor testing to biotechnology statistics, offering a rich tapestry of perspectives on these seminal works. This episode promises a journey through the shared trials and triumphs that shape our engineering landscape and a candid examination of the setbacks we seldom speak about.

The episode isn't complete without their review of the books that sparked this enriching dialogue. You'll hear why "The Wright Brothers" and "To Engineer is Human" scored high on our recommendation list for anyone keen on understanding the essence of engineering, from the glory of breakthroughs to the wisdom found in failures. Join us for this episode, where we bridge the divide between historical achievement and contemporary challenges in the ever-evolving world of STEM.

Topics Discussed
Visit the podcast blog to follow along with the discussion topics, prompts, and questions. Also access a bonus topic to consider for yourself or for your own book review/discussion.

Next Discussion
Want to participate in the next discussion? Join Dianna and others on May 28th. See this link for more info.

If your team is still catching problems too late — let's talk.
→ Schedule a free discovery call: Dianna's calendar

Want insights like this?
→ Subscribe to my newsletter: qualityduringdesign.substack.com

Get the full framework.
→ Pierce the Design Fog

ABOUT DIANNA
Dianna Deeney is a quality advocate for product development with over 25 years of experience in manufacturing. She is president of Deeney Enterprises, LLC, which helps organizations and people improve engineering design.

Transcript

Engineering Book Review and Discussion

Speaker 1 0:00

Hello and welcome to the Quality During Design podcast. I'm Diana Deeney. Not that long ago, I got together with two other people in the engineering and STEM professions, anne Meixner and Dr Vanita Kaur Grover, and we had an engineering book review and discussion. We talked about two books To Engineer is Human by Henry Petrosky and the Wright Brothers by David McCullough. This podcast episode is that review and discussion and originally aired on LinkedIn Live. After a brief introduction, I'll tell you a little bit more about how this discussion group got started.

Speaker 1 0:42

Hello and welcome to Quality During Design, the place to use quality thinking to create products. Others love for less. I'm your host, diana Deeney. I'm a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. I consult with businesses and coach individuals and how to apply quality during design to their processes. Listen in and then join us. Visit qualityduringdesigncom. A little bit more background than what I give on the LinkedIn Live episode.

Speaker 1 1:17

I learned last year that I liked reading multiple books at a time, like maybe eight books at a time. When I started doing that, I started to realize that the technical and engineering books that I would read at the same time concurrently would kind of inform each other. So I would get new ideas and sometimes better ideas, because I was reading these two different books at the same time. One book would give me an idea about another and the other would give me a different sort of idea. So I really enjoy reading these technical books in parallel and together. I've done another episode where I talked about four other books, where I compared and contrast or I read these books together and the kind of ideas that I got from it. I'll link to that other episode in the show notes here. I shared that and it kind of piqued Anne's interest about it. So we got together and I invited Dr Vanita Kaur Grover to talk about Two Engineers Human and the Wright Brothers Grover to talk about Two Engineers Human and the Wright Brothers. That is how this whole engineering book review and discussion event sort of happened behind the scenes. I'm very glad that Anne and Vanita decided to join me, not to just try something new, but also they provided a lot of valuable insight. These are seasoned professionals in their careers. They've seen different things, they work in different industries from each other and from myself. Having their viewpoints about some of the topic discussions that we chose was really invaluable. I learned a lot from Anne and Vanita during this discussion and I think you'll gain some valuable insights too.

Speaker 1 3:04

This book review discussion isn't so much focused on what happened in the book, although we do pull similar themes from the book in order to come up with questions. It's more about our experiences and how we relate the books that we read to each other and to what we're experiencing now and what we foresee for the engineering and STEM communities in the future. I wanted to bring this to you in the podcast because I thought it was a really good discussion and I'm happy to be able to do so Without further delay. Let's get to the engineering book review and discussion about the Wright brothers and to engineer is human. Hello everyone, welcome to a very special LinkedIn live event. We are having an engineering book review and discussion.

Speaker 1 3:59

Whether you're joining us real time or catching up with us on a replay, we appreciate your presence here, we wanted to link some literature to current day challenges and just to show that engineering and STEM people really do still read books. So we read two books for this engineering book discussion. We read To Engineer is Human by Henry Petrosky and the Wright Brothers by David McCullough. We read these books together, so either concurrently or one after another, and we find that if we read particular books, those books are going to give us ideas and some new perspectives and when we read two different books together at the same time parallel those different ideas that they each give kind of overlap and inform into new ideas. And these two books didn't disappoint. Two books didn't disappoint, even though these books are telling historical events from different perspectives. We did find that there were some overlapping themes in topics and that's what we've pulled out into this discussion and review as discussion points the common topics that we found between these two books. Not only were they common, they're also applicable to us today in our own professions and our careers. We're hoping, with this LinkedIn Live event, to gain some new perspectives for ourselves and with you, if you're watching now or later. We wanted to get perspectives from the literature themselves and from each other as we're discussing these different topics and, ultimately, we really want to just get inspired toward action, to be able to try something new, read one of the books or make new connections with others and, along that note, engage in the chat. We're going to be monitoring the chat on LinkedIn Live and we'll be doing our best to incorporate your comments and your questions real-time during the event.

Speaker 1 6:20

Now I want to introduce our members today. I want to introduce you to one of your co-hosts, ann Meixner. Hello Ann, hi Diana, I'm trying to see if I can make you a big star. There we go. Can I tell our audience about you, ann, and your background? Sure, so Ann is a semiconductor text expert with 30 years experience as an engineer and a leader. She founded the Engineer's Daughter to consult on semiconductor testing and to contribute to engineers' career development. So a big thanks to Anne for co-hosting this event and choosing the books.

Speaker 1 7:07

Dr Vanita Kaur Grover. Hello Vanita, hi Deanna, may I tell a little bit about you, absolutely please, to our audience. Vanita is the director of CMC Statistics at Segen, a company that develops and commercializes transformative cancer medicines. She leads a group focused on applying statistics and data science to chemistry, manufacturing and controls for biotechnology. A big welcome to you, anita. Thank you, vanita. Thank you, we're great, great to have you here.

Speaker 1 7:52

To note that Anne and I are both engineers and Vanita is more in the sciences and STEM, so this will add additional perspectives to our topics today, which I'm looking forward to. And I'm Diana Dini. I'm an engineer and I help other product design engineers and product designers incorporate quality and reliability into their product development processes Quality during design which is an online resource for that purpose. Now I wanted to take a moment here to acknowledge a change in our guest lineup.

Speaker 1 8:27

Unfortunately, saul Rosenbaum had to withdraw from today's program due to circumstances that are way beyond his control, and, while I won't go into the specifics, we're all sending best wishes to him and a note that it's essential to support one another in STEM, and we hope to welcome Saul to future events when he can attend. And you can show support to Saul by visiting his website, the Engineering Mentor, or checking out his LinkedIn profile. So if you are interested in connecting with any of the speakers here, be sure to look them up on their LinkedIn profiles, and you can look at the other attendees to today's session. I mean, networking is what makes this kind of event special, so take advantage of it. So I want to thank you for being here and let's make it a fantastic experience together.

Speaker 3 9:35

So would you like me to go with the synopsis of each book before we get into?

Speaker 1 9:38

the discussion. That would be a great warm up.

Speaker 3 9:42

Yes, All right. So first To Engineer is Human by Henry Frytosky. In his book he focused on how we learn from our mistakes to make better things and build a better world. His point is engineering is just about applying science and math. It's also about making judgments and taking risks. He writes about a number of case studies, including the collapse of the Tacoma Narrows Bridge, the building of the Crystal Palace for the Great Exposition in London of 1854, and the building of the Brooklyn Bridge. Since my dad's from Brooklyn, I was really happy about that, and the building of the Brooklyn Bridge. Since my dad's from Brooklyn, I was really happy about that.

Speaker 3 10:33

The next book is the Wright Brothers by David McCullough Sidebar. He also wrote a book about the Brooklyn Bridge. In this book he writes a biography of Orville and Wilbur Wright, the two brothers who invented the airplane, as well as her sister, catherine, who helped them grow their ideas into successes. The book tells us her about their lives, from their childhood in Dayton, ohio, and to their groundbreaking experiments at Kitty Hawk, north Carolina, and also looks at the early days of aviation and the many challenges that the Wright family had to overcome.

Speaker 1 11:02

And Anne, you picked these books for us because you had read them before. Yeah, I had not read them. And Vanita, had you read them before our goal today? She's here. Oh, vanita, we lost your audio. Okay, we're going to come back to Vanita. It was working, just working. That's how technology goes right.

Speaker 1 11:30

So with each of these books, like we mentioned earlier, we found some common topics between them in unexpected ways. So what we wanted to do today was to just introduce these discussion topics, these commonalities that we found between these two books, and we're going to share with you what we found in each book that related to that topic. So we'll give a little blurb about what it was about the book that talked to this topic, and then we're going to discuss some prompted questions. We have some questions that we each independently came up with answers for, and hopefully it will provide a discussion that will give you some additional insights as we're reviewing this too. Also, think about whether you would want to read either of these books. Can you hear me now, janet? Yes, I can, loud and clear.

Speaker 2 12:32

All right, sorry about that. I think my other headset died, so the plug-in backup always works than the Bluetooth one, and that's a STEM feature of us right Redundancies. Right. Sometimes you do need them.

Speaker 1 12:51

Good job, okay, so shall we jump into our first discussion topic? Yes, okay, okay. So the first topic that we kind of saw that was similar between these two books had to do with how people get inspired for new innovative ideas. But not just the inspiration, but capturing the lessons learned from those inspirational pieces. So, for example, those inspirational pieces. So, for example, in both books people created the impossible with the bridges and airplanes and he talks about how successful engineering designs stand as an inspiration of what is possible.

Speaker 1 13:38

But what gets hidden or forgotten are the challenges and lessons learned along the way. In contrast, failures are often clear in hindsight and are difficult lessons learned because of loss. But those lessons are well learned from the engineering community and changes are usually adopted. On the other hand, brothers Book they looked at what other people were trying to engineer for humans to be able to fly, which had been a limited success. They decided that the focus on the machine and not controlling the machine had been a strategic error. On the other inventors' efforts, they also didn't openly criticize others' works, but they kept to their own ideas and iterated on their own work. They shared their open thoughts with the local community and gave invited talks on their progress, but they were careful of what details to share. So, in this theme of getting inspired and learning the lessons from those inspirations, we had a question what gets in the way of us sharing lessons learned from a success? Is it the same challenge with how we learn from a failure, or is it different? And, anne, can I pick on you first?

Speaker 3 15:11

Sure, sure. So first, in lessons learned from a success when I worked at Intel for over 20 years and there was, we had internal conferences where you could share. But also, you know, we want, some of us want, I submitted some of our successes or technology externally and there was always this why should you share the successes? Are you sharing a? Are you letting other people know how to do that and stuff? So I mean there's sort of this. You know balance of. You know sharing, sharing. Hey, here's what we did and here's, here's what we found that was successful and here's what we like. Oh, this didn't work. Here's what we do differently. And are you tipping your hat too much to your competition? And it's that balance of. Well, did you share everything Right? That's why a lot of corporations have legal reviews. I think you know sharing.

Speaker 3 16:23

And going to the next question when you share, it's different in sharing a feeling. When you share a success you have your ego is boosted. You're like here's what I did and here's how it went. But often when you tell the sort of end story, you don't tell about the sort of securious classes that you take to get there right. You always talk about things in a linear fashion like, oh, I did this, this and this, and you may leave some things out.

Speaker 3 16:50

And I think sharing failures is harder on the engineering ego and it depends upon does your corporate culture or your organizational culture have? All right, let's do a postmortem, and a postmortem is done as what went good, what went not so good, right. Right, let's do a postmortem, and a postmortem is done as what went good, what went not so good, right. What would you do differently? And so, if it's taken in that notion of well, we're going to learn from this, both from the successes and for the things that weren't so successful. And so that's instilled there, I think.

Speaker 3 17:33

But you know, I saw very few sort of senior engineers show oh, I really slipped up. And I had one engineer of mine, tim Fraudsham, like shared a bunch of stories because he said we're not doing our jobs right because in terms of data sharing or questioning our management when they ask for something, and so that always struck me as a sign of someone who was very mature. So I think part of sharing failures is being mature enough to know I need to let people know that, even as someone experienced, I tripped up, and here's how I tripped up and here's how I think we should all move forward. So we don't make those mistakes.

Speaker 1 18:19

So I'm hearing that the innovators and the engineers a lot of sometimes ego gets involved when it comes to explaining your success and your failures gets involved when it comes to explaining your success and your failures.

Speaker 1 18:35

Now, john McClure made a comment here that lessons learned aren't shared due to competitive reasons, and I've certainly seen cases like that where there's intellectual property that doesn't want to be shared and success can be wrapped into that property that doesn't want to be shared and success can be wrapped into that. And John also mentioned I'm going to show his comment here so I was in the oil industry for 10 years and what I observed was a reinventing of the wheel because everyone who had come before wanted to capitalize on their intellectual property for competitive edge and those who came after had to build their own version rather than build on the existing. So I think that kind of goes along with that same ego theme that we're seeing Now. Vanita, what is your take on this? What in your industry and what you've seen? Is it the same sort of things that get in the way of sharing lessons learned from success?

Speaker 2 19:31

there. Before I do anything, I do want to read a disclaimer that the views that I'm expressing today are purely mine and they do not reflect the opinions or beliefs of Sejan. So I just want to make sure that these are all my personal views and beliefs. So I think to me it depends on who the audience is, where you are sharing, right? If you are sharing within a team, within yourself, I think we share a lot more failures and we celebrate some successes too, because you know failures is a stepping stone for success, right? So you want to always acknowledge what you have learned from that particular event, or you know what didn't work and, going to your point and you know you would do a post-mortem at the end and see what the successes were and what were the things that we could do better the next time. And I think in some ways, there's also a little bit of mind shift, I think needed, in ways that we celebrate success as we say we did good, but when you talk about learnings, you always go back to the failures. What did we learn? How can we do better? Why do you always ask for a feedback on what you're not doing good? Why don't you always ask me a feedback on concentrate on what you did good, let's celebrate that and let's see what you can do better and how you can do better.

Speaker 2 21:02

So I think, coming back to the point, that it really depends on the audience. If you're going to be sharing, let's say at the conference that you're publishing it. You don't want to talk about all the different iterations you went through to get there. You would talk more about the successes and then it gets capped by the legalities involved in it. Right, our legal departments in the companies how much IP you can share, how much IP you cannot share. So, going to John's point, there's that much limited information in terms of IP that you're allowed to share out, both for the successes and the learnings. I do want to read out Nelson Mandela's note, right? He said I never lose. I either win or learn. So he's always celebrating the success or, you know, sharing the success and learning from that. Or there was a learning, there was never a failure I like that quote.

Speaker 1 21:54

That's applicable too. Yeah, and uh, john added another, another comment that, um, yeah, he, he really wouldn't call this kind of thing an ego either, because most engineers work for a company which has many motivations other than the advancement of technology and the engineering profession, and they typically necessitate rules, closure of intellectual property, particularly to competitors. So I can see all of those kind of things going on, and with failures too. We're talking about intellectual properties with success, with failures too, there's also some liability concerns about disclosing a failure, so there are some of those kind of attitudes also.

Speaker 1 22:52

He spoke to engineers, human, uh, he talked about the, uh, the glass house, the crystal palace and how there were a lot of things that needed to be overcome, challenges and engineering challenges that needed to be figured out, and they did it and it was a success and yay, let's move on. So I think the nita a little bit to your point asking for feedback on what worked well is to make sure that you're getting the good balance of both, that you're stopping to recognize what did work, not just what didn't work. Would you agree? Yeah, okay, agree, yeah, okay. I think we can move on to the next discussion topic. Is there any other comments about this particular topic that we discover?

Speaker 3 23:42

Okay.

Due Diligence in Engineering and Innovation

Speaker 1 23:49

All right. The next topic that we kind of discovered between these two books that overlapped and got us thinking differently about things is just due diligence in STEM. So this is about innovating and taking what we've already known and using it for a new purpose or to develop something new. In Petrosky's book he challenged the traditional view of engineers as rational and infallible. They're portrayed as being humans inspired toward innovation, which I think we all realize that, but many people that aren't in engineering may think a little differently about that. So engineers may base work on successes of others and failures are a reminder that they innovated too far, too quickly. Failure traditions help all engineers understand more fully what some apparently did not, and that kind of ties in with what we were just talking about, with learning from our failures In the Wright's book.

Speaker 1 25:00

The Wright's initial trials were based on the experts before them and they took a wide approach to gathering what was known about flight at the time. Through their first trials they realized that the experts were wrong and they needed to abandon their initial assumptions of what would work and start from the beginning on their own. So this theme sort of ties into. You know, we stand on the shoulders of giants, do you think it's more difficult or easy to practice this kind of due diligence, researching the baseline of what you're innovating from? Is that easier today compared to the early 1900s and Vanita? I'm going to ask you to start with this one Sure.

Speaker 2 25:50

Diana, I think in some ways, because before then you had to reach out to the library and to make a request for an article and it'll take about a month to you know, get shipped from, get photocopied and shipped from the place where it is available.

Speaker 2 26:37

So I think in that way it has become easier. One of the other things, I believe what has enabled not only you know, looking at what has been done before, but researching and doing what you want to do now. Right, if you're building a new model, if you want to build something new, there are more simulation softwares available where you can try and play around with things in the software to see is your design going to work, you know, is this model going to work? And given the computer technology advancement, we can do it much, much faster and much easily. So, and then you know. The other thing is also they are more available the risk management software. So when you're looking at the due diligence, so when you're looking at risk, it kind of helps you in making sure you have looked from the all aspects and you have not missed anything. So I think it's become easier in that way. And availability of online documentation or electronic documentation of things and simulation software.

Speaker 1 27:58

Yeah, I like your point about the simulation software, because there's a lot of baseline knowledge that people built into those systems already, especially for reliability type calculations, where the idea put forth by the software developers is, yes, this is a very good software suite, but the people that are using it really need to know the assumptions behind what it is they're using it for and because they just gave everything as an availability. So that is something that I think about that these tools are more readily available and usable, but we still need to understand the basics of where they're underlying assumptions in the car right.

Speaker 2 28:39

So if you're in an accident or collision can it leak back into the car or not? So I was using that software Reliability, one of those Reliability softwares to do the probability calculations of you know how much possible it is for it to leak in or leak out and what kind of repercussions it can have. So I think our regulators also look for those calculations and those probabilities.

Speaker 3 29:43

Yeah, interesting. How about you, Anne? Do you think it's more difficult? Or think to the point of we have access to more last sort of chapters about that is knowing how many decimal points, knowing that there are limits on there and that having full faith in a computer model results can be a dangerous thing.

Speaker 3 30:07

I think there actually are some challenges that they didn't really have the 1900s in terms of the speed that people want to apply new technology or make iterations on that or change processes for the maintenance of infrastructure. In fact, sometimes the focus on innovating things, people forget that you need to take care of things and that in making your case to your management it's like we need to do this, okay, we need to make sure you set aside the people to also maintain this once we deploy it or have methods in place to do that. And I think sometimes the push for meeting a schedule can put pressures on to maybe ignore something that you know looks a little off. And I definitely know of some cases at Ento where someone saw something for silicon on a design like ah well, maybe it's just here, and it turned out to be a significant issue that had implications in manufacturing tests to mitigate it and eventually they had to rip out a circuit design and put in a new one to mitigate the whole thing. But it's so.

Speaker 3 31:26

I think there are a lot of stories about that and I think that's the tension that you have, and I'm sure those tensions existed in earlier technologies. In rereading Petrosky's book in particular, it was like, well, we need to have safety margins, and how much safety margin? And when you went and talked to for the railroad, they talked to several different experts, the British government, and they found people had numbers all over the place, right, and so you know how those numbers are based. What's the data behind it? You know there's a certain aspect, at least in the engineering sort of craft of engineering, is you kind of have to go with an intuition, right? There's usually more than one way to solve a problem, and you may have. Sometimes you have. You never have all the data. You want to make the decision, and sometimes you you have to make a decision to go forward.

Speaker 1 32:32

Yeah, and so the pace of things is a little faster and that could be a good thing and it could be a bad thing. And the quantity of information is more readily available and that's definitely a good thing to have more information. I've also experienced where I have more information and they conflict, so then I don't know where it stands. This report says this and this report says this Just from a consumer perspective. I was just reading an article in Newsweek about this. With the American diet, there are so many conflicting reports. As soon as one comes out and says this is good for you, another report comes behind it says no, it's bad, you want to do the exact opposite. So I think that makes it more challenging to filter through all that information, To filter through all that information.

Speaker 3 33:57

I think one of the ways to do that is to understand, you know, control groups and things like that, to really differentiate.

Speaker 2 34:26

So engineering it's important to understand, when you're reading a paper like Anne, what assumptions were made for each one of those studies underlying assumptions, because that's really important. You know to your point, Deanna, there's so much information available or, depending on what they're doing, they made different assumptions. So, as a result, when they looked at the data, they came up to a very different point than somebody else who did that same study, had made different assumptions and collected the data in a different way, so they reached at a different point. So I think underlying assumptions are also very important in addition to the scope.

Speaker 1 35:04

Yeah, those are both good points. So, yeah, just understanding the baseline, scientific method and scientific studies and hypothesis tests. I think that's an important thing for anybody in STEM. I think it's good to continually practice and get better at that. John McClure also commented the difficulty, or the difference between today and hundreds. Uh, uh, john thinks the safety risk is also weighted much more heavily today than it was during the right era. Um and Vinita's agreeing yes.

Speaker 2 35:47

I think that's what um Henry's also talking about in his book. Engineering is Human right. He goes back to the cost of human life and everything that is a lot more paid attention to these days than it was, you know, early 1900s.

Speaker 3 36:03

Right, and I think there was a point he made in the epilogue. He talked about the space challenge or the crash there, and an engineer said there's a point he made in the epilogue. He talked about the space challenger, the crash there, and an engineer said there's a risk and the management said, no, well, we've had all these successes. How, you know, how do we come out, looking at a closer look at that, and said that NASA was such a data-focused thing there that, having that gap, well, we don't have the data that really proves that. And someone Feynman said well, when you don't have the data, you use rational thought, you reason it out, you say what could the potential risk be? And so that goes back to what data do you have? And also, where are the gaps and how do you fill in those gaps to make a decision and in terms of safety, right, you know, we've. We've. This brought us back to Petroski's.

Speaker 3 37:18

It's hard to learn from success, right, If you're always successful, you don't necessarily you don't necessarily know where the the points are, because when you design something, you can't always look at all the different aspects and sometimes engineers focus on a certain aspect and I think, when reading over the review of the Comet, the first jet airplane, and what the risks were.

Speaker 3 37:45

And they had focused on this but they missed this other part. But it took them a long time to figure out. It was only from the failures that they learned what that was. But the other thing they pointed out, he pointed out was you know, even though it took him a while to figure that out every time you go look at a failure, you keep making improvements because you notice this other thing is like oh, I hadn't thought about that, that and I'm seeing this risk here. And so I think part of due diligence goes to understanding, is and goes back to learning from the failures and how the Wright brothers learned from their failures, from their experiments. So like, oh, this isn't quite working right, what do we have to? You know what has to be done differently.

Speaker 1 38:30

Yeah, good points. Do you want me to introduce the next topic?

Transfer of Skills Across Disciplines

Speaker 3 38:40

I'll introduce the next topic. Okay, great. So topic three was the transfer of knowledge from other disciplines. Transfer of knowledge from other disciplines, and a great example in Two Engineers Human, is about the famous Tacoma Narrows Bridge, which undulated dramatically, you know, to the point where thrill seekers would go on it to experience a roller coaster ride, and it failed from a crosswind. While it totally failed from crosswinds, while a scale model was being tested at University of Washington to figure out what could be done to stabilize it. It turned out another expert who was from an aeronautical engineering identified what the problem was and created the mathematical expression that as a slender bridge it started, you know, it was acting like an airplane in the wind.

Speaker 3 39:33

Um, the white brother's skills and knowledge of bicycle riding and machines actually transferred very well into the development of the airplane because they understood, you know, balancing as you move and the the need to, as the rider, control your bicycle, transfer it. There's like, hey, we need to make sure we understand how to control this machine and that's going to take lots of practice and, compared to the other people trying to make airplanes, they did lots of trials and it wasn't just testing the technology, it was understanding how to control this vehicle. Where their competitors were so focused on I need to build this machine, they didn't think about having the experience as a pilot to control the vehicle. So the question that we have here is how do your varied interests help you become a better STEM professional, and what are some skills that you, you know, transfer to your current challenges? Diana, why don't you start off from your experiences?

Speaker 1 40:50

Sure, I'm an avid do-it-yourself, I'm not afraid to jump in and just try to do stuff, and I don't know if that's part of being an engineer just trying to figure things out with whatever you got. But it's this whole cross-pollination of ideas of different backgrounds, different technologies and professions Using those kind of things. Today's innovation is always really fascinating to me, and I think of things like TRIZ, the theory of inventive thinking that someone's done it before, even if it's in a different industry. And new ideas are usually based on some technology that was developed in a different industry in a new way. And I was introduced a couple of years ago from someone at NASA to the Center for Transformation of Work and that's an online searchable directory of marketplaces and it's meant to cross-pollinate innovative ideas.

Speaker 1 42:07

So one of the great, one of the greatest stories or it's one of my favorite stories is a potato chip manufacturer was trying to make a crisper chip and they didn't know how to do it and they they reached out to I think they reached out to one of these marketplaces. Or as a violin virtuoso who knew very well how different sound waves and resonances worked with the violin, and he knew it in a statistical manner, so he got back to the chip manufacturer and said hey, if you use this sound wave, it'll shake the excess oil off your potato chip the excess oil off your potato chip. So I just love stories like that, and whenever I'm trying to solve a problem, I do reach out pretty wide with problems.

Speaker 3 43:00

Well, that's. I like that and I think it'd be great after the live session to share that you know, that resource to people you know in terms of understanding what happens in other fields, the semiconductor industry requires so many engineering and science disciplines I continue to marvel at. You know, all that makes there and in my recent work as a technical consultant for semiconductor engineering I've come to appreciate. You know, I'm a trained electrical engineer but there are a lot of mechanics and materials and structures and chief forces that impact making electrical contact and I kind of knew that but I've had a greater appreciation for that. But what are examples of skills you transfer?

Speaker 3 43:59

So I'm a professional ski instructor and that means I'm analyzing people skiing and I'm trying to teach them, and more than half your lessons are people who's never skied before. It's their second time, and so that has actually helped me over the decades be a better engineer and working with others, because you really need to be listening and really understand what is their goal. To help work with somebody and you know I've only gotten, you know, better in that. But I think it's just really listening and focusing on what that person's goal is and not what your goal is on there, and I think sometimes, as an engineer, we get so hung up when we're working with someone else like, well, here's my goal, we need to go this way and that, and not necessarily listening to your partner, whether it's another partner, organization or client. You know, understanding that, vinita, in your work, where do you see, in terms of this, varied interests or applying skills from one area to another?

Speaker 2 45:10

I think you nailed it pretty well. So I'm a statistician, I'm not an engineer I think the last time I did science was my grade 12, but I work with great scientists and engineers all the time, right? So I've worked in academia, I've worked in chemical industry and now, for last, about seven, eight years, I've been working in pharma. So there are some things that are very common throughout. Right, you talked about the communication skills making sure you understand what the other person is asking for, making sure you understand what they're looking for. Right? And there's a very famous saying in our stats world is people like scientists will come saying I need this, but actually they don't know what they really need. So you have to talk to them and they actually need something else. So they might need A, but what they really need is what they're asking for is A, but what they really need is B. So you have to figure out between you know, having a conversation, how to move them First of all understand what that B is and then how to move them from saying I need A to yes, I actually do need B, I don't need A. So you know, that's really important. So having a really good, strong communication skills, which is both you know asking questions great questions but also listening how to actively listen and, you know, ask the right questions. The other thing is you know people skills. How do you get to talk to people? How can you, you know, not offend somebody? And because a lot of times when you ask a question, a scientist could get really uptight like are you questioning my scientific, you know knowledge or are you questioning what I'm saying? Same thing for engineers, right? So how do you ask them a question so that they don't feel offended but they feel you're asking them a question, they feel flattered and they will share more than you had asked for and a lot of times in that, more than asked for, information is what lies the golden egg, right? That's where the whole thing lies, in order to understand their ask.

Speaker 2 47:12

I think the other thing is I am a quilter. So when you're quilting, when you're cutting a fabric, you always want to measure multiple times before you cut it, because that plot is never going to get back together and if your measurements are not correct in quilting, when you're piecing it together, you will not get a good. You know you won't get a nice piece in the end. I always call it. That's my piece. You know that's a human piece, not a machine piece, but regardless.

Speaker 2 47:44

So I apply that in everyday life of my workplace as well, because one of the things I do is I design experiments. I tell people, in order to answer your question, you need to go out and collect the data and, by the way, you will run experiments. You run this many experiments and here's the order you run them in, right, because they're trying to understand how to optimize their processes and things like that. Some of them are actually very costly, right. Each run is money and man, hours and a lot, of you know human effort into it. You don't want to go that wasted. So what, you're going to ask them how many runs to do and how to do it. You want to think and think really ahead of time and think properly so that you're not wasting company resources. So I think those are some of the ones.

Speaker 2 48:36

The other thing I would say is I'm also a master black belt, six Sigma master black belt. So some of the things I learned from there are more around problem solving. So I apply that actually even in my day-to-day life, when I'm sometimes, you know, I'm trying to get some point across, I'm trying to understand what my daughter is really trying to do there. I apply those problem-solving skills to oh okay. So let's try to do you know, let's try to understand what are you really doing here or how are you doing it. So I think those are some of the other skills I would say that are really, you know, cross-functional in a way, and they come in handy from different interests.

Speaker 1 49:19

Now, vanita, you said black belt and I thought you were going to go a different direction. She quills and is a black belt and a statistician. She's so cool, I mean, you're still cool.

Speaker 3 49:29

Thank you. So I thought we could move to discussion point number five, because I thought that would be a great one to wrap up on Sounds good. So you know how do you iterate in STEM from small scale to large and test iterate cycles, which keys in well to Veneto's last point about design of experiments in one particular order to engineers, human, about the crystal palace and how, going from a small greenhouse that was built and how to iterate that into larger structures. Um, same thing with bridge building design. And one of the points about the crystal palace was the the engineer designer took advantage of, because it was built up quickly and was able to, and took up a sort of unit, unit intervals of what was manufactured, what was the largest glass plate, and I really marveled at that. Right, knowing, knowing what those limits are. Okay, how can I use that on there?

Speaker 3 50:47

And the Wright brothers? Well, they did tons of iterations on their prototype planes and some of them took months. They did a lot of test flights and made changes there, right. So some iterations were longer, some iterations were short and I think as they progressed in their understanding of flight, they got shorter. So questions In your industry is your industry more specific to small to large iterations or sort of test iteration cycles. Vinita, I'll let you go first, because you're an informer. You just talked about doing tests.

Speaker 2 51:25

Yeah, yeah. So actually this is very important for us, right? Because anytime you are innovating or you're coming up with a new method, it's always in the lab, but when it gets approved and when you are ready to manufacture, it has to be on a pretty large scale. There are different ways we do it. We have what we call as a scaled-down models, so we would validate some models on a small scale and we would test them to compare to the large scale that they are giving similar results, that transferable right. Because, for example, if you have you're mixing something in a small beaker, you cannot mix it at the same speed when you're mixing in a, you know, 20 liter, 50 liter, 150 liter reactors.

Speaker 2 52:09

So some of those conversions of course play into place. But we oftentimes would work with our scaled down models if you're trying to troubleshoot something and then see how that translates to the large, you know, to the full scale. We don't often reiterate between both. You know the back and forth between small scale and large scale. Initially we might do a few experiments to make sure that our scaled-on model is good enough, but then we stick to the scaled-on model if we have to troubleshoot anything.

Speaker 3 52:42

Okay, diana, I know you're focused on quality design processes and to get in reliability. I'm curious what your experience is in these different type of iterations.

Speaker 1 52:57

I've seen both. I work a lot in medical devices, so there is a lot of test iteration cycles that happen and not so much the small to large scale iterations just because of the nature of of the devices and, as we talked about the, the safety factors that we're trying to validate against. Something that I think about with consumer electronics is there's I know that there's test iteration cycles within those products too, but when we get into software and the consumer electronics, I see some evidence of field use as part of that design iteration. So well, let's do this iteration and release it to the public and see what happens, and that's just a different level. Maybe there's no safety concerns when industries do that. That's not really something that all industries could do, really something that all industries could do, but it's. It's just I guess it's highly dependent on what it is you're developing, what the safety factors are, and then understanding your risk and the uncertainty around the risk when, when you do that kind of stuff.

Engineering Book Review and Discussion

Speaker 3 54:24

Right, yeah, I think I think in the medical part the whole risk, you know, is similar to some other things where you call functional safety, sort of in aeronautics and in automotive applications, where there's that the semiconductor industry is right, we have, we're making really tiny devices, but we often produce them on a large scale and they're actually made in very large factories. Um, and there is um. I worked in technology development for over 20 years and we talked about pathfinding and there was sort of proof of proof of concept and then, well, let me do a smaller scale, let's's try, you know, try out one machine. But there was always, you know, there was sort of there was always this learning when you put something into high-value manufacturing, it could be that all the some of the procedures you were doing, the factory wasn't doing, or there were different pressures, or it's just some things you don't learn until you go to scale in terms of a manufacturing process. But then there are definitely, as you develop, process recipes, you know, there are these sort of test information and short loops where you're like, well, let me put this set of wafer in.

Speaker 3 55:42

There's a lot of DOE in semiconductor processes. In fact, intel made a big investment in you know we need to have statisticians here and we need to train engineers, but they also need to do this work because there's a huge amount of data to analyze, looking at in the industry in terms of there's a new sort of emerging area in semiconductors called cycle silicon, life cycle management, recognizing that there are things we may have to modify out in the field or there's learnings you can have in the field to see that. So I think we're we're finishing up here and so we should probably wrap up with our reviewer recommendations and um sort of number of stars. Um, I'll go last, since I recommended the books that I'm. I'm obviously a little biased. Um, the need to, why don't you go first? Since you're the non-engineer here? I'd be curious what you thought.

Speaker 2 56:56

I enjoyed reading both the books. I was telling Diana that it's been a while I actually sat down and read a book, and you know definitely a book like this. I enjoyed reading both of them. Sometimes I found Henry's book a little bit interesting in the way that you know there are a lot of he's trying to draw a lot of similarities between the human body and you know the engineering aspects and stuff like that. There were times when I found that very interesting. There were times when I found a little bit hard to follow just given you know my engineering background in it I would probably give four stars to both the books.

Speaker 3 57:32

Okay, all right, sounds good, diane.

Speaker 1 57:35

Well, at the risk of sounding like a parrot, that's what I picked too. I did write it down. But the Wright Brothers I listened to it on audiobook and it was a really well done biography. And the author relied. He did what to do. He relied on the facts in order to paint a picture and give us an understanding of who these people really were and why did they make the kind of decisions that they did and why did they act the way they did. So sometimes I was, I was kind of belabored with, you know, how the right home looked and what kind of dishes they had and the kind of socks they wore, you know. But I was able to, you know, I understood what the author was trying to do and it did give me some information. But that was just a thing that you know. I would skim through some of that and get more to the meat of the book.

Speaker 1 58:33

Um, and to engineer is is human. Um, yeah, I don't, I don't know. He, I think in the in the introduction he explained that he meant this book to explain engineering to people who aren't engineers. Um, so I could see where he was going with a lot of the stories, some of those historical events. I knew of them before through other books, but he took a different angle or talked about different details about it. So that was very interesting. But I didn't really find any bigHA engineering surprises, which I guess is a good thing if I'm an experienced engineer, right. So I gave both books four stars also.

Speaker 3 59:20

Okay, I will give David McCullough's Wright Brothers five stars because I thought as a trained historian he does a really good job of explaining sort of the engineering processes. I mean I also found that with the Brooklyn Bridge. So I think he may do a better job of explaining to Lehman what engineers do in certain respects. And he's an excellent writer. And the arc of the story and going from close to end I thought was always very well done. I think to engineer is human. In rereading, I mean, I think for engineers it validates their experiences and I think that's why I would agree I'll give it a four star because sometimes it's not always the easiest to read, sometimes his prose is a little dense, but I think he makes so many excellent points and I've read some of his other books and some of them you know I think are more successful in explaining some of the because he talks about something more specific like the evolution of everyday things.

Speaker 3 1:00:33

I still remember the story of the zipper and the investor waiting 20 years and no one would do that today, right, but we have zippers.

Speaker 3 1:00:42

But what I appreciated about it was his focus on learning from failure, because so often from the lay person they always hear about the successes and on that and understanding that these are really complicated structures or processes or there, and that you know it's hard to. He does a good job explaining. It's hard to assess everything right. You have to say what's important, what's not, and then it's based upon what you know, and then when you build it, you realize something turns out to be important that you didn't know about, and so I think, as engineers, it's nice to have someone really tell our story and validate what we do and what makes it hard and what makes it wonderful, I think, for the lay person. I think there's learnings in there, to also understand you know why something may not work the way you want it to, or why you know, know things fail. Things have to have maintenance and inspection right, and one of the breakthroughs was they weren't doing the inspections, so it so it failed.

Speaker 1 1:02:01

So yeah, well, I want to. I want to thank both of you. I think, with our different backgrounds and our different perspectives, we really were able to share that, because there were things that you talked about at these topics that I hadn't thought about and you took it a different way, which I thought was interesting, I thought was staying. So I really appreciate that you. We did this special of LinkedIn live event, I hope that you enjoyed it too.

Speaker 2 1:02:43

Thank you, I did, I really did.

Speaker 1 1:02:44

Great and I hope for those that are viewing, either if you're viewing now or if you are watching it on the replay. We hope that you enjoy this special event too. Let us know if you decided to read one of the books and look us up on LinkedIn, We'd be happy to connect.

Speaker 3 1:03:11

And maybe let us know if this was worthwhile, that we should try it again and maybe if you're interested in maybe being one of the book discussion people. That's right. I'm thinking about you, john McClure, because I know you love to read and I'll put something in the link about the book, about the story of the zipper, that that it's part of there, because I think it's a cool story that's great thanks thanks, diana, for reaching out.

Speaker 2 1:03:38

I really appreciate it. I really had a lot of fun um reading both the books and, uh, joining you both today for the discussion great, I'm glad to hear and thank Anne for helping to co-host this event.

Speaker 3 1:03:51

Yeah, it was a lot of fun.

Speaker 1 1:03:54

I hope you enjoyed our book review and discussion. If you noticed, during the episode we skipped from question topic number three to number five, so we skipped a whole topic that we had planned to maybe discuss if we had the time, but we didn't have the time. The question that we skipped was about STEM and culture. Let me share this topic with you so you can think about it for yourself. If you read these books, if you have read these books in the past, you can think about STEM and culture as it relates to the books and then also to how you're experiencing your engineering and STEM career.

Speaker 1 1:04:41

The Brooklyn Bridge and the Crystal Palace in To Engineer is Human was supported by some groups but challenged by many others. Bridges were seen as necessary improvement but also very dangerous and not readily accepted by the public. The Crystal Palace was seen as a marvel but not necessary. The Wright Brothers flights were dismissed by many in the world as impossible, and some groups didn't even give them their time to demonstrate their work. France provided better environment for demonstrating their success with the airplane than the United States.

Speaker 1 1:05:17

Two questions that you can consider for yourself. How often do you think culture plays a role in today's STEM inventors' plans Just as much as the projects in the books, or less? And a second question is with today's connected world, can we more easily find the people needed to support a STEM project compared to the projects in the books? At qualityduringdesigncom, as part of the blog for this podcast episode, I posted the questions that Anne and Vanita and I discussed in our engineering book review discussion and also this extra topic and questions. Consider having your own engineering book review, a discussion about these two books. Use the questions and the prompts that we use and see what kind of new ideas and inspirations you can get from the engineers and STEM professionals that you know. This has been a production of Dini Enterprises. Thanks for listening.