S2E34 How Process Engineering Will Make You An Invaluable Engineer | Zach O’Ferrell

Process engineering is not something that gets a lot of love during school, so many engineers enter the field without an understanding of what it means to be in process engineering. In practice, it’s one of the most important skills an engineer can have because it relates directly to a company’s ability to manufacture their product or device. Join us on this episode to hear from Zach O’Ferrell, a master process engineer, about design verification & validation, IQ/OQ/PQ, Lean, Six Sigma, DMAIC, and other tools for optimizing the manufacturing of products. 

The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.teampipeline.us.  

About Being An Engineer

The Being An Engineer podcast is a repository for industry knowledge and a tool through which engineers learn about and connect with relevant companies, technologies, people resources, and opportunities. We feature successful mechanical engineers and interview engineers who are passionate about their work and who made a great impact on the engineering community.

The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.teampipeline.us

Transcript

Presenter: 0:00

The Being an Engineer Podcast is a repository for industry knowledge and a tool through which engineers learn about and connect with relevant companies, technologies, people, resources and opportunities. Enjoy the show.

Zach O'Ferrell: 0:16

So I've tried very, very, very hard to never focus on whose fault it was or who did it. It's always how do we get to the root of this problem so that we can understand what the process failed? And how can we design a better process?

Aaron Moncur: 0:43

Hello, and welcome to another exciting episode of the Being an Engineer Podcast. Our guest today is Zach O'Ferrell who is Director of Product and Process Engineering at Edwards Lifesciences. Zach holds a Bachelor's Degree in Bioengineering and an MBA and has deep experience in the manufacturing, especially from a process standpoint of medical devices, as well as with managing engineering and technology teams. Zach, thank you so much for joining us today.

Zach O'Ferrell: 1:11

Yeah, sure. Thanks, Aaron.

Aaron Moncur: 1:13

So what made you decide to become an engineer?

Zach O'Ferrell: 1:18

Probably the same thing that most other engineers answer, which is, I was good at math and science as a kid. I had a couple other engineers in the family. And so when I was making my my college decisions. I made decisions like a 17 or 18 year old, which was engineering sounds fine. might as well do it. I think not not, not probably not a great thought process. But I did love math and science growing up. And so that was a lot of what drove my decision toward engineering.

Aaron Moncur: 1:48

Awesome. That sounds very similar to my decision process. Not a whole lot of thought went into it, but it ended up working out. So you are the director of product and process engineering? I think most engineers will understand what product engineering is. But can you explain a little about what process engineering entails?

Zach O'Ferrell: 2:06

Sure, yeah. So interestingly enough, process engineering was not something that I had a good understanding of coming into college, because a lot of college experience, especially undergraduate is more research and develop ent, product focused. It's al about designing a good product But what they don't spend a much time on, especia ly in things like bioengi eering or biomedical enginee ing is how are we actuall going to make this thing? ow are we going to manufac ure it? How are we going to put t together, and I discove ed a pretty deep love of manufac uring during my co op experie ces in college. So I got to do s me hands on engineering. And thr ugh that experience, I discove ed that I really love digging into and understanding process s, especially manufac uring processes. And so the pro esses would be the how you do t, the product is really the wha what are you going to make? A d then how do you do it?

Aaron Moncur: 2:58

So the process engineering is much more closely related to manufacturing than it is the development R&D design processes?

Zach O'Ferrell: 3:05

100%. It's all very hands on, how do you actually build this device, yep.

Aaron Moncur: 3:11

Can you can you share just one or two examples of a process that, that you use regularly with the products that you manufacture,

Zach O'Ferrell: 3:20

I could go on and on. But some examples. One example we've got here at the site that I support is laser welding. And so you can actually use laser energy in order to transmit heat to a part. And it can be a really efficient way of molding two plastic components together by imparting a very specific amount of heat for a controlled amount of time. So laser welding is an example. So it's a process that that you can get very deep end to understanding. So I've got that in my background. And part of my training as an engineer was to learn and understand how these laser welders work. Another example that we use all the time is UV cured adhesives. So many adhesives you think of if you just pull out a superglue, you put it on and it just air cures over time. Well, we can accelerate curing of those adhesives using UV light, actually, and so we have a lot of processes that that utilize a process like that.

Aaron Moncur: 4:16

Very cool. Now you also have experience implementing and executing something called the DMAIC process. DMAIC be an acronym for D-M-A-I-C , which stands for define, measure, analyze, improve and control. Can you explain what the mech is and share a practical example of how you've used it in your work?

Zach O'Ferrell: 4:37

Yeah, absolutely. So dometic is an engineer's bread and butter. And ultimately, it's a problem solving tool. So when you have a problem you want to solve and that could be a problem being an undesirable state, meaning a bit of an issue or something, or it could be a desired future state that you'd like to get to but you don't know how to get there. dimeric is a way of breaking down that problem into meaning meaningful steps that you can then tackle one at a time rather than saying, 'Oh, I just need to go solve the problem.' Oftentimes engineers have a tendency to say, 'I have a problem. And I immediately want to develop solutions to that problem.' But what they fail to do oftentimes is break down that problem to understand, is this a problem worth solving? What are the elements of the problem that are important? And then obviously, understanding what are the stakeholders? Who are the people who are going to be affected by this solution. And maybe in some cases, even the more people focused areas of the problem that are maybe less well understood by many engineers. And so to me, it forces you to walk through these different processes of defining the problem, then understanding how are we going to measure success for it, analyzing different steps coming up, and then finally, you come up with improvement processes, and then you monitor to make sure those went well. So examples, with daily examples in manufacturing, there's constantly things going wrong, that's just the nature of a manufacturing process, there's things that will go wrong. And the urgency is extremely high to fix those problems. And so by by allowing our engineers to step back and use a rigorous thought process for solving these problems, we know we can gain better consistency in the solutions that we get.

Aaron Moncur: 6:19

There's also Six Sigma and Lean. And is DMAIC a subset of those? Or is it its own separate entity altogether, and different different nodes, processes, DMAIC or Lean or whatever are used depending on the application?

Zach O'Ferrell: 6:33

Yeah, I view DMAIC as another tool in the tool belt. So Six Sigma is a tool, Lean is a tool. And they each have many tools within them. And DMAIC is a tool of its own. Now, DMAIC very often pairs with both Six Sigma and Lean. So I'm I am Six Sigma Black Belt certified. I don't have any Lean certifications. But I'm fairly well versed there. And so I know that for Six Sigma Black Belt, DMAIC is the underpinning of how we walk through problems and the whole training courses designed around that phase approach for dymanic. And so but I can bring DMAIC dubare, outside of a six sigma problem, or outside of the lean problem, it could be any problem, I found that I can bring that tool to bear to solve that problem. It's just a different way of thinking through it.

Aaron Moncur: 7:20

Okay, so it's really a standalone process.

Zach O'Ferrell: 7:23

That's all I've done. That's how I've always used it. And and again, that it pays dividends because I can use it in other areas outside of just those very technically focused things.

Aaron Moncur: 7:33

Sure. Yeah. Well, here's another acronym. I'd love to hear you talk about IQ, O, PQ, can you tell us what this stands for? And run us through a practical application of equipment qualification?

Zach O'Ferrell: 7:46

Sure. So this this one's also my bread and butter. So I've sat on our company's validation board for many, many years, which is the the board that defines policy and procedure for our whole company for validation. And I've also been to some training given by a third party that's also given to FDA. So I sat in with FDA auditor so Food and Drug Administration auditors on in this training, so got to got to sit right next to them learning the same things that they learned about how they view validation. So IQ, OR, PQ stands for installation qualification, operational qualification, and then depending on which company you're at process qualification or performance qualification, they're interchangeable. And so it just depends on which company you're at. And some companies will merge OQ, PQ, together, some will merge IQ, OQ together. But ultimately, those are three separate efforts, IQ, OQ and PQ.

Aaron Moncur: 8:42

Okay. And so you receive a new piece of equipment, how do you start the qualification process?

Zach O'Ferrell: 8:47

Yeah, sure. So again, if it's a laser welder, let's say one of our pieces of equipment that we use, we, before we even get that piece of equipment on site, we have to define what we want out of that piece of equipment. So we have to write what's called a specification document or a user requirements document, we have to define exactly what it is we want this thing to do and high level terms, meaning, what capacity do I want it to have? What kind of utilities should it have things like that, we write that we give that to the vendor to confirm that we've got the right specifications, before it even arrives on site. What that allows us to do is prewrite our installation qualification, knowing what the thing should do before it even gets here. Oftentimes, before that, we'll even go go to the factory to do a factory acceptance test. That's an important part of installation qualification. Then when it arrives on site, we will actually install the thing in place and then we have a set of things we want to check about it. So for instance, we want to make sure it's safe. So we'll check the alarms, we'll check all the interlocks the guarding things like that. We want to make sure that the the installation happened as we said it happened. So did we actually have the utilities required to run it? Check that kind of stuff. And then obviously the most important part is the functional. Does it actually do the things we said it was going to do. So that's running cycles in the equipment. That's checking different outputs, whether it be laser power, or laser focus or things like that these these important factors that we defined, actually checking those to make sure they're repeatable over time, they have consistency over time. And that gives us some good confidence that we can then move it to the next stage, which would be OQ in this case.

Aaron Moncur: 10:28

I think that entire process is so interesting, because I think oftentimes people don't recognize or appreciate the fact that when a new piece of equipment is received, it's not just on the for running automatically right away, right, there's this whole process that has to be gone through to, to validate it to quantify it before it can be used. And that in itself can be a hefty project to go through.

Zach O'Ferrell: 10:50

It's a big one. And all of it is in in light of mitigating and managing risk. That's the whole reason we do it, if we weren't working in an industry, so I work in medical devices, if we weren't working in an industry that could have detrimental effects to not only our customers, but our patients, those requirements might be a little bit less. And I don't want to compare with other industries. But but I do feel like we are held to a bit of higher standards in some cases, because we have that expectation that this thing is going to work perfectly from day one. And there's no real tolerance for failure if that equipment down the line.

Aaron Moncur: 11:25

Yeah. All right. Well, we've talked about the process side a little bit manufacturing and qualification. Let's back up just a little and talk about something called design verification. What what is design verification? How do you prepare for it? And at what point in the development process do you start talking about and planning for design verification?

Zach O'Ferrell: 11:46

Yeah, so design verification is a day one type of activity. Now, you don't run design verification on day one, but you have to be thinking about it from the very beginning. Because when you design a new device, obviously the first thing you want to figure out before you even go into design that devices, what do I need it to do? So similar to my example, for giving a specification document for equipment, you have to define upfront? What is this product? What should it do? And what must it do? And that's actually a huge aspect of design verification is listing out the attributes that this product has to have. So for instance, we start with something like the product in medical devices, the product must deliver some fluid to this vascular area, that's an example. Well, that then translates back into a set of product requirements, meaning, okay, if we wanted to deliver fluid, then we need to start defining fluid flow rates, and we need to define pressures or things like that. And those become the engineering specifications that we'll check during design verification. So design verification is not about saying, does this meet the clinical need? It's saying we created some specifications that we think will meet the clinical need, does our design meet those things? And then there's design validation, which is a secondary step, which is, okay, we've made the device that we think will work, let's go check it in an animal surrogate and humans, whatever that that thing might be to say, does it actually meet the needs that we've defined out in the field?

Aaron Moncur: 13:21

Right. Does it not only satisfy the design inputs? But does the device holistically do what it's supposed to do? Does it do the right thing?

Zach O'Ferrell: 13:29

Exactly. And for simplicity, we try to break those into separate efforts so that we can take it one step at a time. And obviously, if it fails, design verification, we don't want to move to the next phase. So it's an important phase gate for us.

Aaron Moncur: 13:43

Yeah, talk a little bit about design verification. I mean, you've defined the product, you've defined what you want out of it, you know what the design inputs are? So how do you perform the actual verification?

Zach O'Ferrell: 13:55

Yeah, so for design verification, that's really I'd say the one of the first times you're going to be building the device in its entirety for for more than a few devices. Because you can build feasibility, you maybe do a few for some very front end studies. But design verification is the first really controlled, protocol driven build. And so you're actually building it on the manufacturing floor, running it through all the processes you would normally run it through with operators who are building the product, who will potentially build the product in the future, you build those devices, you condition them as you need to so put them through simulated shipping, or the worst case temperatures that they might experience throughout their life, things like that. accelerated aging, so you put them through the full rigor and then there's a very generally a very rigorous set of testing that you need to do so you'll destroy the device in the process, but break it down into its component parts tested against you know, this, this length to meet the length we need. Does this withstand the pressures that we need, all those types of things that you specify that it has to perform too, you check it against each one of those specifications. So you're literally tearing the thing apart, measuring everything, running it through simulated use testing, things like that.

Aaron Moncur: 15:13

Yeah. See, I love talking about this part, because this is what we do we develop the the test equipment for these kinds of devices. And when we are developing the spec for our own equipment, not for the device, but for the equipment, we go through the same process where we'll define what are the user needs, what job are we hiri g this piece of equipme t or this test fixture to do? nd then we translate those u er needs into design inputs. What are the technical require ents that need to be satisfi d? And then at the end, we'll b able to go back to those d sign inputs and say, 'Alrigh, here's a an enginee ing metric, can we measure this and check it off the lis based on measured results' So this whole process I just oved so much, vacations for me, I want to go to a manufac uring facility and watch how the make things. Is that is that so fun?

Zach O'Ferrell: 16:00

You're welcome anytime, Aaron.

Aaron Moncur: 16:03

Nope. Ah, I'm not much of my take you up on that? All right. Well, you work a lot with Six Sigma and Lean processes. We talked a little bit about this before, what's the difference between those two? Are they complimentary? Or are they even used separately? Just by themselves? Are they standalone things like DMAIC? r are they often used togethe?

Zach O'Ferrell: 16:24

Yeah. So I would say they can be used separately. But in order to, I'd say, fully solve a problem, many problems, you're going to want to know both. And the reason I say that is, if all you know is Six Sigma, let's say and Six Sigma is the tool set, that's it. What's the saying? 'To a hammer, everything is a nail.' And so the potential problem is you only bring that tool to bear even when it's not really applicable. So so I'll back up a little bit for Six Sigma. I'm simplifying this quite a bit. But in general, that is a tool sets that's used to reduce variation or understand variation and a process by variation. I mean, you run the process 1000 times, and each time you'll get a different result. But the question is, how different of a result Do you get each time you run it? And is it okay, that we're getting that different of a result. So for instance, if you run a process 1000 times, and half of the time, it produces not a good result, you have high variation in that process relative to what your specifications are, that you're measuring against. And so Six Sigma is a great tool set for breaking down variation, understanding sources of variation, and being able to eliminate or reduce or change them. And that that comes along generally with maybe more automated processes, processes that have many, many defined attributes about them. So a lot of input parameters, things like that. lien, on the other hand, is all about reducing waste. So if you look at it one way, you could say, well, variation is a form of waste. And you can look to reduce waste that way. But it's going to be very difficult to reduce variation without also having the Six Sigma tool sets. Lean on its own generally is used to to improve process efficiency. So oftentimes, they say, I'm producing 1000 widgets a day, right now, if I want to produce 1500 widgets, tomorrow, I'm going to have to change something about what I do. Now, you might have existing waste in your process. And by waste, I mean, you have an operator who's walking 50 feet just to operate on a part when they could be walking 10 feet, or, there's a lot of waiting time and they're waiting for the next thing to come their way. Well, waiting time is waste. We look at different types of wastes that way, and you can reduce those using Lean fundamentals.

Aaron Moncur: 18:54

Six Sigma and Lean are commonly used within a process engineering environment. I'm curious, have you ever seen them used effectively within more than R&D or product development environment?

Zach O'Ferrell: 19:08

Yeah, that's a great question. I have. So Six Sigma very much so because when you're developing a product, that product itself is going to have some variation in it. So an example would be if I design a part to always be three inches long, let's say I design the part to be three inches long. Well, I'm contracting a vendor, let's say to make that part, I really need to understand what variation that vendor is going to provide to me, because that tells me what design limits I can potentially work within. So an example would be I want it to be three inches, but they're able to give me a part that's anywhere from 2.5 to 3.5 inches. Well, I either need the vendor to do better than that, or I need to design for that level of variation and understand that fitment of parts is going to be an important piece. If my design, so that's called tolerancing, geometric tolerancing, things like that and R&D engineer absolutely has to understand what what variation means in that context. And there's lots of different types of variation you can encounter. Some are acceptable for your design, some may not be, but you got to understand how to measure it, how to look at it, and how to respond to that variation in your design. So that's just one example of where that that Six Sigma mentality around variation, understanding is really critical.

Aaron Moncur: 20:29

Got it? Okay, that makes a lot of sense. Let me take just a short break here and share with the listeners that teampipeline.us is where you can learn more about how we help medical device and other product engineering or manufacturing teams, develop turnkey equipment, custom fixtures and automated machines to characterize inspect assemble, manufacturer and perform verification testing on your devices. Today, we're speaking with Zach O'Ferrell. Now, Zach, one of the interesting things I learned about you is that you facilitated the transfer one of Edwards' products, I think you've done several, actually, but one of them I read about was a transcatheter heart valve delivery system from Edwards plant in California, to a plant in Utah. I'm assuming that was a pretty big project. And you probably learned some things along the way. And I'm wondering if you can share a few of those lessons learned with people out there who might be preparing for a similar transfer? .

Zach O'Ferrell: 21:27

Sure, Yeah. So that's, that's an understatement. So I came out to the Draper, Utah facility here, for my company. And I was one of the first engineers to come out here to to initiate those transfers from California. And for a period of seven or eight years straight. Most of my role, both as an engineer, then as a manager, eventually, as a lead of the engineering team here, was focused on transferring products. And so through that process, we transferred well over a dozen different major product lines, we're now actually in the process of doing outward transfers. So we've hit hit some of our capacity, and we're transferring out now. Right? And, and so I've learned both ways how to transfer products, I'd say, there are so many lessons learned so many different things that I've learned through that process that are very specific, very detailed. But in general, some some of the skill sets that I think I underestimated in the beginning, and then came to appreciate much more later on, was the value of making a good plan. And while in the beginning, I think I have a tendency as an engineer to just jump into solutions, as I mentioned earlier in the podcast. And it is so critical before embarking on an effort to get aligned on things like simple things like scope, what is it exactly that we're going to do? What is success going to look like? What are the factors that are working against us here, maybe understanding all of those aspects, so understanding risks, understanding potential opportunities that you might have with this transfer, all of that feels very mundane, and doesn't feel like you're making progress or taking action or driving results. But it is just so critical to get on the same page with others. When you embark on an effort like this. It came back to bite me a few times that we didn't do that, in my mind. And I was the one who had to pay the price later, by realizing that I had gone six months into a transfer and we weren't even aligned on what we were transferring. So I think that was a big lesson for me. I think it's a balance, you can you can obviously plan your way to death. But I think putting at least a lot of those initial things in place, understatement, I'm sorry, understandings, agreements, things like that are really critically important to set off on the right foot. And then it allows us to be engineers and just go execute, which is what we want to do.

Aaron Moncur: 24:06

Right? Yeah, yeah, no, I totally agree with that, as engineers, we want to get into the problem and just start start solving it right. And I think that at times, we can almost feel a little guilty if if we're not solving if we're not actively executing the solution to that problem. And we need to be careful about that we're actually getting ready to move to transfer into a larger facility right now. we've outgrown our current one, and we just need more space, more room to grow. And I have spent a considerable amount of time thinking about how are we going to move everything, just like the logistics of moving all this stuff from one building to another, while not taken a huge, huge blow to our productivity. And at a certain point, I started to feel like I'm spending way too much time just thinking about this and planning what we do. Hire a bunch of people and do it. Hire some movers and do it. But I think that the time have spent planning for it is going to really pay dividends even though I'm starting to get a little itchy and just want to want to take some action.

Zach O'Ferrell: 25:12

Yeah, it's always a fine balance. It's really hard to know, when do I start? But that is the tough thing. And I'd say that's a lesson I'm still learning today.

Aaron Moncur: 25:21

Yeah. Well, another area in which you have experiences managing engineering teams, what are a few of the biggest challenges that you've encountered managing engineering and technology teams? And how have you addressed some of these challenges?

Zach O'Ferrell: 25:37

Sure, yeah. So currently, the size of my organization in total, including, so I manage managers, and then they have teams within them. In total, my organization size is about 50, or 60 people, including engineers, and technicians, technologists. And so I have a pretty diverse group that has a lot of different functions within engineering. And so I think, some of the some of the things that I've learned, number one is to adapt your engine, your managing style, to different people. And that seems pretty straightforward. And I think a lot of people would say, of course, you need to adapt. But it's easier said than done, when you're actually in a leadership position, being able to change not just maybe the words that you use, but the actual approach and style that you use when you're working with other people. Because I mean, my belief is that as a leader, you have to be the most flexible person in any relationship, you have to be willing to change and adapt, depending on what the needs of your employees are. So that you can continue to meet those needs and predict what's going to happen in the future with your team, you have to stay really engaged. The other thing is, don't underestimate the value of building up personal relationships with team members. Because the more the more comfortable everyone is, in a particular environment, the more willing they are to give feedback, especially constructive or critical feedback, which is really the only way that you can continue to improve as a manager, because you find the moment you enter management, no one wants to tell you anything ever, especially if it's bad. And so being able to find ways of getting that from people, no matter what that is finding ways of doing that, I think is really critically important. In terms of other types of challenges obvious, one of the most obvious ones to me is that generally, when we hire engineers, almost no one comes to us with a deep understanding of manufacturing, that's very, very difficult to find out a school, and we hire very much out of university, we think that's a strategic advantage for us finding very top talent out of the university and then training them internally. But that training process is very difficult and rigorous, and it can be challenging, because, like I said, oftentimes when people come out of school, they want to be very r&d focused, or they want to be very product focused. And process focus does not come naturally to many people. And so having to teach them that it can be a challenge. But I found that to be one of the areas where I get the most engaged. Personally, I love training, I love teaching, I love mentoring, I love coaching. I love all of those things, which is probably a big reason why I'm a manager now. So

Aaron Moncur: 28:18

That's fascinating. I had not heard anyone talk about I guess the difficulty with which engineers can move into a process environment. It's not something that's discussed very often in school, I certainly didn't hear about process engineering. If someone had asked me what's process engineering, blank stare, deer in the headlights? I don't know what that is. But ironically, I think that process engineering is arguably one of the more interesting sides of engineering. And as engineers were trained to think so linearly, that it's, it's such a natural fit the process side for many engineers, have you found that once new engineers, especially right out of school, who maybe don't really understand what process engineering is, have you found that that once they get a taste for it, it's really something that a lot of engineers enjoy and thrive in? Or have you found that there really is a very specific type of person type of engineer that can they can thrive in that environment and you have to weed through a lot of different people and to find that that right person or two.

Zach O'Ferrell: 29:24

I found exactly what you meant what you said in the first part, which is when we bring an engineer in and expose them to not just just a process mindset, but other tool sets, like Six Sigma, like Lean, they feel right at home. Most, if not all, of the engineers I work with once they actually get access to some of those tools and learnings. They are over the moon happy about how how deeply they can get into some of these processes and and learn and you're right it does feel very natural, which is strange that It's not covered in school. But I found at least, the feedback I've gotten is we have many, many black belt trained engineers, so Six Sigma Black Belt trained engineers within my organization. And almost all of them say that that black belt training that they went through was more transformative than their entire undergraduate experience. So they said, 'I'm getting that.'

Aaron Moncur: 30:20

Oh, man, that's huge.

Zach O'Ferrell: 30:22

Yeah.

Aaron Moncur: 30:22

Wow. Wow. I could see people listening to this right now thinking about or hearing about Six Sigma Black Belt training and thinking to themselves, that sounds really big and really scary. And like, it would take so much time, what is the the training of the certification lab for Black Belt Six Sigma?

Zach O'Ferrell: 30:43

Yeah, so there are actually a few different places that will do the certification. Our, my company actually has an internal program that we've grown from one of those and, and staffed ourselves to be able to train more and more people through generally, those certification processes can be anywhere from one to four weeks, just depends on which one, which one you're looking at. But they all cover the same basic content in terms of the DMAIC methodology, things like design of experiments have many of those tool sets. So they all cover the same thing, because we do want some consistency and what a Six Sigma Black Belt means. And all of them come along with a project. So that's a key a key difference, I think is, in order to get a black belt, you can't just show academic competency, you have to execute a high value project. And by high value, I mean something that has real world business results. And so you have to execute on that project and show that you can use all of the tool sets and drive a project to completion. And that that tends to be a very transformative experience for engineers to.

Aaron Moncur: 31:49

Excellent. So you work at Edwards Lifesciences, a big medical device company, lots of resources, lots of history, building on the shoulders of giants, I'm sure there's some of that that's going on there. And you have these systems or these processes in place. From a process standpoint, are there a few critical areas that you think smaller OEMs, that might have far less resources, and far less history and experience of the area, but still need to ensure that product quality is met? Where can they start? Yeah. This is a really huge question. And it could be taken in all sorts of different directions. I'm sure I'll I'll let you decide where you want to take it. But, let's say you're talking, talking with a startup device manufacturer, and they're starting from from the ground ground floor here as far as their processes, how would you advise that they design their processes? What are a couple of the two or three most important process related elements that you would suggest they think about and implement quickly?

Zach O'Ferrell: 32:58

Yeah, that's a tough question to answer, I think. I'll do my best. I think in a startup environment, obviously, smaller companies are going to be looking at smaller scales as well. And oftentimes, especially in medical devices, smaller scale means manual, so versus automatic. If you're in a pharmaceutical company that pumping out, let's say millions of doses of a vaccine, for instance, very much of that has to be fully automated. And so they have the luxury of having those automated solutions that are much more advanced, have integrated quality controls, things like that, as a smaller company, you're almost inevitably going to be dealing with manual processes. And so you have to think about an additional element beyond equipment, which is operator, and the person performing the process. So I think one, one thing new companies need to absolutely think about is how does my operator work with my machine? And how can those two be be joined together in harmony, I'll say, to produce the right outcome. And I think what what sometimes fails to happen is they design the equipment in and of itself without actually thinking about how someone's going to use it. And so that's everything from safety, I often see equipment coming without any thought behind safety. And you can have some serious issues which for a startup, if you have any worker' comp issue or something like th t, that's going to be a showsto per potentially. So I think s fety has to come really, really eavy. And then oftenti es to user interface. So am I pr viding something that's simple, easy to use, can I train someone quickly to do it? Because oftentimes, we don't think a out that and we rely on people' extensive training, which m ans you're not resilient to turn ver, which might happen also in a smaller environment. And so nderstanding I need to make th s thing as simple as quick a easy and well documen ed how it's used. Things like th t. So I'd say that's I'm not rea ly I'm not really getting too much out out here. But rea ly, I'd say those safety concern, then obviously interac ing with the operator are two big things that you got to cons der.

Aaron Moncur: 35:12

Yeah, no, that's great advice. Thank you for sharing that. I'm going to take another step out of the process world and ask what what are a few setbacks that you've had in your career and in your teams? And how have you dealt with them?

Zach O'Ferrell: 35:25

I thought a lot. A common saying, right, is that you, you definitely learn from your failures. And I'd say, I should be a genius by now. But I'm not. So for failures, a couple of really key things that have come up in my career. One big thing that happened pretty early on in my career was the the site I was working at, was issued a warning letter from the Food and Drug Administration. And a warning letter is one step, sometimes before a complete shut down. So unlike some other industries, the Food and Drug Administration has full authority to if they wanted to just say you are now done manufacturing, you can no longer manufacture this device, pull it from the market. And that's actually not that difficult for them to do. And it's happened many times before. We got the step right before that, which is the warning letter. And sometimes if companies don't respond properly to that warning letter, the consent decree or stoppage of manufacturing is the next step, we really, really, really did not want that to happen here. Because we had just initiated transfer of our flagship devices into the into the site. And if we were to go on consent decree, we would shut down worldwide supply of this product that is super critical to our patients. So I was part of the team that was looking at rewriting some of our validation procedures. So that's how I know IQ, OQ, PQ so well, because I was part of really diving deeper in there to make sure we had much better processes and procedures in place, we had to remediate a lot of work within our products and processes. And so I got to be a part of a lot of that. And I think that was a huge accelerated learning experience, because I got to learn a lot of things. Otherwise, I wouldn't have gotten for years. But because of the position I was in, because there weren't that many other people to take problems like this on, I was tasked with doing it. So I was I was given a lot of responsibility, not necessarily because others trusted me, but because they didn't have another choice. And I thought that was that was that was perfect. I was in the right place at the right time. To learn from that and gain that experience. Another one I made a pretty big mistake. It was around that same time, maybe a little bit later, I made a mistake, which was a failure to understand design requirements, actually. And I cost our company millions of dollars, because I failed to understand that right? Obviously, there's others involved in things like that it can't just be a one person thing, but I felt very responsible for that mistake. And ultimately, it turned into us making a change to a product that we should not have made, which ended up causing bad product, which we caught. But then we had to reverse that design change, scrap everything we had made. And that was a big one, that was a big one for me. So that that was where I really learned quite a bit about better understanding design changes. But I'll say I appreciate all of the leaders and coaches and mentors that I've had throughout my life who can look at a mistake like that, and not blame me, but say, 'How can we learn from this? And how can we move forward to get better?' So I'm really, really grateful to have leaders...

Aaron Moncur: 38:44

Yeah.

Zach O'Ferrell: 38:45

In my past, and now my present

Aaron Moncur: 38:48

So where do you think you would be if after and again, this is not just your mistake, there were there was a team involved, but maybe the manager, that group sees this problem and says, 'This is costing the company millions of dollars, you all of you in this group, you're all fired, you're gone.' Where do you think you would be if that had happened to compared to where you are now, where the managers were like,'Okay, this was a failure in the process, and maybe a lack of experience or education with some of the team members, but said, of just, going the nuclear route and firing everyone, let's learn from this, and let's see what we can how we can improve the future.'

Zach O'Ferrell: 39:26

Yeah, so I mean, obviously, it'd be a different company. But more fundamentally, I don't think I would be as good of a leader because it is hard. It is really difficult to become a good leader when if you're surrounded by bad examples constantly. And I think that to me, was a very defining moment where I realized yes, we do need to focus on the process, not not the people and and if you are always saying the people are the cause, you're never going to get to the actual root cause of any problem and fix it or make things better. And so I can tell you from each of those experiences. We as a company improved how we operate, we updated the process, we changed things. We said, what can we make better here, so that so that no one else is put in a position to make this mistake again, or have these issues again. And I've carried that forward into my management style. So I've tried very, very, very hard to never focus on whose fault it was or who did it. It's always how do we get to the root of this problem so that we can understand what the process failed? And how can we design a better process, not just manufacturing processes, but actual business processes or modes of operating, that can be better?

Aaron Moncur: 40:34

That's very well said, I think the last 30 seconds of you speaking was worth the price of admission for the entire episode right here. Very well said. Well, we're just about done here. We're gonna wrap things up in just a couple of minutes. But first, we have a question from a listener, I'm probably going to massacre his name. So I apologize in advance. It's Nui Uluwad Badami. And Nui asks, I would love to rapidly evolve my skills as a design and product development engineer for hardware devices, how have you or guests on the podcast, strategically implemented self directed learning as engineers, striking the balance between the structured curriculum of school and rapid learn as you go process required on the job? So I know there's a bit of a departure from what we've been talking about. But I thought we could just riff on this for a minute or two, I have some thoughts. I'll let you go first. If you have any thoughts that come to mind, right off the bat?

Zach O'Ferrell: 41:30

Sure, I'll give it a shot. So thanks for the question, Nui. I'd say for me, I obviously, well, not obviously, I view myself as a self learner, obviously, I have some education. So I have a bachelor's degree in a master's degree, those were very helpful for certain things. But at the same time, I have to be able to learn on my own and learn from my own experiences, or else I will never get any better than I was when I graduated from from school. And so one, one obvious thing is be getting feedback from others. So when you produce something, let's say if you're looking at to improve your designs, you've got to make sure that others are actually looking at your designs, and you're not just making them for yourself. So you have to find trusted people who will actually give you real feedback. And that's hard. That's easier said than done. But you do have number one is you absolutely have to find those people. So who are they who can actually critique your work, who can give you feedback on how you're doing and who can be be that person or people to work in a community that can give you that level of feedback, if you can find that, then a lot of it comes pretty naturally, honestly, because you can create your designs, you can get the feedback, you can continue to improve, and you can work toward a higher level of skill. The only other thing, at least for me personally, and this may not be an issue for everyone, I find it very difficult to do that level of learning. While I'm also doing my full time job, it's very challenging for me to do all of the things I have to do in my role now as director and learn on the side. And so I actually find ways in my personal life to learn new skills. So for instance, I have a passion for computer coding. But it's not something I ever do in my day to day job. But I do feel like understanding some level of computer coding can make me better at certain things and decision making or thinking through problems. And so on the side, I create and write different computer programs that I can send out to others and give feedback that are just fun, like old games and things like that. So I get really engaged there, I can do that kind of thing for fun. And it allows me to get better at that skill set. Whether or not it helps me at work.

Aaron Moncur: 43:39

That's great. I agree wholeheartedly with getting feedback from others. I've had a lot of mentors over the years, I continue to have a lot of mentors. And I think that going back to the crises that ou were talking about before, th y say never let a good crisis go to waste, right, there's a ways a lot that you can learn fr m a crisis. So flipping the len through which you see pr blems and seeing problems as o portunities for learni g, I think is a big one an im ortant tool for rapidly develop ng your skills. Another one, thi is more of a tactile or tac ical tool is taking apart exi ting devices and learning how they were designed. There's s much that you can learn, ther are 1000s of different mecha isms out there just mechanica ways of performing some actio. And there's no reason th t you should have to invent a l of those by yourself. Go out to a thrift store or something, ind some plastic toys or someth ng like that, and take th m apart and you can learn so uch about how they were designe and why they were desig ed that way from just expl ring these devices that are already out there. They've alrea y been designed someone's lready thought through it. and erify these mechanisms. So I th nk that's a really helpful st ategy is to find existing pro ucts, take them apart and se what you can learn from them All right, well, I think w we've done pretty well here. ach, is there anything that tha we haven't talked about tha you think we should have? O we should?

Zach O'Ferrell: 45:23

I don't think so. No, that was that was great conversation I loved covering those topics is perfect.

Aaron Moncur: 45:28

Okay, excellent. Well, how can people get ahold of you?

Zach O'Ferrell: 45:31

Yeah, sure. I'm really available on LinkedIn. So LinkedIn is definitely the easiest way you can find me just be my name. I'm very open on LinkedIn. And so I accept messages. I accept your new contacts and requests constantly. So that would be awesome. Love to hear from anybody. And I'm more than willing to connect.

Aaron Moncur: 45:49

Terrific, and I'll put a link to your LinkedIn profile in the show notes. Well, Zach, this has been delightful. Thank you so much for joining us and sharing some experiences and being a little vulnerable, sharing about some of the the problems that you've had and how you've learned from them and your career. I really appreciate your time. So thank you again for being with us on the Being an Engineer Podcast.

Zach O'Ferrell: 46:10

Sure. Thanks for the opportunity, Aaron.

Aaron Moncur: 46:16

I'm Aaron Moncur, founder of Pipeline Design & Engineering. If you liked what you heard today, please share the episode. To learn how your team can leverage our team's expertise developing turnkey equipment, custom fixtures and automated machines and with product design, visit us at teampipeline.us. Thanks for listening.