Being an Engineer
Being an Engineer
S7E10 Daniel Gledhill | How to Win at People-Centered Leadership in Engineering Teams
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Daniel Gledhill is a seasoned manufacturing and engineering leader whose career bridges high-risk industrial operations and precision-driven medical device manufacturing. Daniel leads engineering teams responsible for multiple production areas supporting transcatheter heart valve delivery systems—products where quality, reliability, and patient safety are absolutely critical.
Daniel’s journey to medical devices began in heavy industry, where he worked as a process, chemical, and metallurgical engineer at Rio Tinto, including leadership roles at copper smelters overseeing sulfuric acid plants, powerhouses, and byproduct operations. These early roles shaped his systems-level thinking, comfort with complex processes, and respect for disciplined operations—skills that would later translate powerfully into regulated medical manufacturing environments.
Over nearly ten years at Edwards Lifesciences, Daniel has progressed from manufacturing management into senior engineering leadership, guiding teams through scale-up, process improvement, cross-functional collaboration, and organizational change. His work sits at the intersection of engineering, manufacturing, quality, and leadership—where decisions directly impact both operational performance and patient outcomes.
Daniel holds a Bachelor’s degree in Chemical Engineering from the University of Utah, along with an MBA from the University of Utah’s David Eccles School of Business. This combination of technical and business education informs his balanced approach to leadership—one that values data, people, and long-term system health over short-term wins.
In this conversation, we explore what it really means to lead engineering teams in medical device manufacturing, how leadership expectations evolve as engineers move into management, and what lessons from heavy industry can sharpen execution in highly regulated, patient-critical environments.
LINKS:
Guest LinkedIn: https://www.linkedin.com/in/daniel-gledhill-a6155237/
Guest website: https://www.edwards.com/
Aaron Moncur, host
Subscribe to the show to get notified so you don't miss new episodes every Friday.
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 like cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us at www.teampipeline.us
Watch the show on YouTube: www.youtube.com/@TeamPipelineus
I think that the thebiggest mistake that I see is, I think as we embrace a leadership role, we kind of go from that individual contributing role, or just as an engineer, as someone that likes to get things done, we feel like it's still on us to solve that problem and to make that change or it all falls on us to to have those those answers.
Aaron Moncur:Hello and welcome to the being an engineer podcast today, we are privileged to have Danny Gledhill with us, a manufacturing leader and change agent in the medical device industry, where he has overseen multiple production areas supporting transcatheter heart valve delivery systems, valves and accessories with a background spanning chemical engineering heavy industry and nearly a decade in life saving medical device manufacturing. Danny brings a rare blend of technical depth, operational rigor and people first leadership to everything he does. Danny, thank you so much for being with us today.
Daniel Gledhill:Yeah, it's great to be here. Aaron Thank you.
Aaron Moncur:All right, so what made you decide to become an engineer?
Unknown:Yeah, I think I took a little bit of a less conventional path. I think most engineers I talked to felt like either, you know, they had someone in their family who was an engineer, or someone just had had kind of linked them to it. I actually began my undergraduate in pre med, in chemistry, and was doing that path, and got, you know, two to three years into it, and kind of looked at what the next 10 years of my life were going to be like, and kind of thought, Is this really the path that I want to do? And met with some counselors at the university and looked at, okay, hey, these are the classes I've taken. What other options do I have? And chemical engineering lined up well with the chemistry background that I had. And so it was just kind of a switch. I looked at it. I looked at, okay, what are the options that I'll have coming out of chemical and, you know, engineering out of school. And it was a very broad base, because I didn't, I didn't know what I wanted to do. I didn't have this, you know, clear path. And I think that, I think a lot of us are actually that way, but maybe we're, we're afraid to admit it, that we maybe don't know exactly what we want to do when we're in school. And I was definitely in that path, but I wanted to have options, and so I looked at what, what opportunity was going to let me, you know, define my career as I go, and chemical engineering for me was that, and that was the pull there of just having a degree that was going to open doors for me and create opportunities.
Aaron Moncur:I know I was that way in college. I barely understood what an engineer was, right? I didn't have this grand plan. Yeah, I think you're right there. Probably a lot of us are. Are that way. So let's talk about the the work that you've done. You've led engineering teams responsible for transcatheter heart valves. First of all, tell us a little bit what the heck is a transcatheter heart valve. And then if you could talk just a little bit about, have there been significant differences leading teams in like patient critical medical device environments, versus different leadership roles that you've held in the past?
Daniel Gledhill:Yeah, absolutely. I The the standard for care for heart valve replacement is open heart surgery. So you would have your your chest opened up, you would have a pacemaker, or you'd have a bypass put in, and you would stop your heart and put a new valve in place, and then, you know, close up your your chest, and there's a pretty long repair process to That. Transcatheter heart valves is probably 10 to 15 years now, and it is an opportunity for a procedure where you can replace a valve in your heart without having to open up your chest. So an opportunity for you to replace your aortic valve and ultimately go home from the hospital the next day without the scars, feeling better, and so an enormous progressive step in in care for, you know, people suffering with aortic stenosis.
Aaron Moncur:That's That's amazing. My dad had open heart surgery back when I was in high school, and I remember it being a lengthy, uh, just getting over the trauma of the surgery, like it took him a while, right? I remember visiting him in the hospital, and he was going through recovery, and it was, it was rough. So to be able to go home the next day is kind of mind. Blowing How was the let's just get into a couple little details, because I'm curious here the the trans transcatheter valve procedure, is it? Is it entirely done via catheter, or is it laparoscopically assisted?
Daniel Gledhill:It's entirely done via catheter. So wow, the valve is compressed down, is is entered into your your artery, and push through your femoral artery, into your heart, and then expand it into place and and so it's an enormous change, like you. My dad had to have his aortic valve replaced, and his was replaced probably 15 years ago now. But I think the conversation with him about, hey, when that wears out and you need to get that replaced, you no longer have to go through what you went through. And for him, it's just yeah, I was, you know, in his words, was, I'm not sure if I want to do that again to now, you know, being able to go in and have it done in such a less invested, invasive ways, is really, you know what engineering in the med device Spaces has been able to provide to to the market and to the care of of humans.
Aaron Moncur:That's so incredible, just incredible, that such a sophisticated procedure can be done entirely via catheter, without any laparoscopic or otherwise supplements. Very, very cool, okay, the medical device base is heavily regulated for good reason. Have there been significant differences in terms of like leadership style or behaviors when you're leading a team that's regulated so heavy, heavily versus, you know, other engineering environments where there's really no regulation to speak of.
Unknown:I think the basis of leadership and motivating engineers is the same across industries. But I think one of the big changes, or lenses that you have to put on is really understanding what those boundaries are that you're working through, is really understand what went into this validation. Why was it done this way? What are the regulatory requirements? What are the patient requirements and the design requirements for this. And if you can put those pieces together and understand that picture as an engineer, then you can be creative and understand, how can I work within this space to make changes, make improvements. And so I think that's the biggest change, is just understanding the field that you're playing in and and how you can make and think like an engineer within that space.
Aaron Moncur:Let me dig a little bit deeper on that point. So if I put myself into the shoes of a medical device engineer, and I realized that the devices I'm developing could be used to save someone's life, and if I do a poor job developing this device, well, hopefully that gets caught with all the, you know, the procedures and regulations that are in place for good reason, but let's say something slips by that could be, you know, life threatening to a patient, right? If a faulty device is used, Have you have you seen engineers maybe get into analysis paralysis or or just be so worried that a device they produce is going to lead to a poor outcome that their their creative assets freeze up. And, you know, they they're not. They're maybe thinking more from a place of fear than than creativity. Is that ever something that you encounter? And if so, how do you, how do you coach engineers out of that?
Unknown:Yeah, I don't know that. It's as much the fear. I think maybe sometimes you'll see that from a frontline professional, someone who's actually hands on building the device of, Oh, what if I do this wrong? Really, on the on the engineering aspect. It's, you know, do do Am I understanding all the potential impacts of a change that I'm looking to make? And I think that's where maybe some of that fear or trepidation comes into play, because, hey, I know what we did in the past to say that this valve or this device was okay to use, but I'm looking to make this change. How do I know that I've checked all the boxes to make sure that it, you know, is is fully going to function for our patients the way that the design was impacted. And I think that's where we really try and connect the r, d groups, the process, design groups, our regulatory groups, to really pull all those different aspects in to really kind of look at it from those different aspects to get that confirmation. And you know, you don't, you don't need all of that just to do a test, to do a trial. And so I think it's, it's, you almost have to be even more creative, because the simple, straightforward way of testing this maybe doesn't work. Or. Uh, maybe you can't implement it in the easiest way. You actually have to get more creative for how can I continue to move and challenge the boundaries within the industry?
Aaron Moncur:Any examples that come to mind, and if not, that's fine, of of situations where or stories where, like your your team, had to get more creative because of exactly what you said and like how that evolved. What happened? Have you ever built a test fixture that didn't work well? Most engineers have, usually because of hidden pitfalls you wouldn't know to look for if you don't design fixtures all day. After watching this happen for years, we built a simple five step framework that gets fixtures right the first time, and we packaged it in a free guide called The Essential Guide to designing test fixtures. If you want more accurate, repeatable data and fewer redesigns, click the link in the show notes to grab the guide, get it, steal the framework and level up your fixture game.
Daniel Gledhill:Yeah, I think looking at a lot of the progress that that we made is looking at, okay, hey, this is where we want to go with you know, we're going to this. This device is already commercial, and now we're realizing that the the process that we're we're making this on is not sustainable long term, either due to cost, due to, you know, shift in supply chain, or whatever it is. And now having to look at, okay, what? What options do do we have, whether it's a complete revalidation or, you know, hey, is there a simpler way for us to, you know, stay within our current validation umbrella, but still make this change? And I think that's where our teams have really been creative to try and come up with, hey, rather than us having a two year span where we're going through validations and relaunching this product. Can we tweak the equipment? Can we look at bringing in an alternate vendor or a like, doing a like for like comparison, so that we can continue to build and supply our patients with these devices, but not have to go all the way back to the drawing board? And I think that's something that our teams have done multiple times to be able to continue to support the market and continue to build these devices.
Aaron Moncur:Yeah, that makes sense. Let's talk a little bit about scaling a medical device. Now, building a prototype is much different than manufacturing in high volume production, right? Eventually you can get a prototype to work enough tweaking and fiddling and you have something that does what it's supposed to do in production. That's obviously ultimately you get there as well. But an engineer can't sit there and tweak and fiddle with production device over and over and over. So what? What are some lessons that you've learned about going from prototype to to scaled up volume production? What are some some pitfalls that teams commonly run into? And how have you seen teams successfully navigate those pitfalls?
Daniel Gledhill:Yeah, I'd say the number one thing that's that's gotten me, or the teams that I've worked through, is kind of eliminating what you'd call either tribal, tribal knowledge, or, I guess, gray areas within your procedures. Because as if you're involved in the team that's designing this device, you have a ton of background information, and you take that background information, as you begin to create these procedures or processes, you fill in a lot of the gaps with that background information. And you don't always realize that you're, you understand it, and things make perfect sense because you're, you're connecting those gaps. And I think that's why it's so important to bring you know someone with without that knowledge and with a manufacturing history into that process so they can really look at things and say, Hey, this word doesn't make sense to me, or you say to hold it like this. But actually, it can be done several different ways. What way do you actually want the team to be doing this? And I think that's probably one of the biggest lessons learned is is really taking that step back in and looking at what what gaps are we filling with the knowledge, the intimate knowledge that we have from this device. And if we brought an entire new team in, an entire new team of support engineers, entire new team of frontline employees, an entirely new regulatory group would they be? Would they understand the intent as we developed and created this process? And I would say that would probably be the number one thing to really look at is, you know, have have we set up those teams for success, or are we relying on knowledge that currently is, is. Is just retained within people's history and their experience.
Aaron Moncur:Does that mostly come down to robust documentation? Or would you describe it in another way?
Daniel Gledhill:Yeah, I think that's a huge part of it. And in finding ways, like in a medical device procedure, you want to limit the wording that you use, but you you need it to be clear, because if, if you say someone has to hold something with their right hand, and then they hold it with their left hand, you know, ultimately, you're not following your procedures. And and you have a potential for a non conformance. And so you want to be as you know. You want to make sure that you document the things that are critical. And so as you go through that process, I think that's where you really can can dive in and understand, hey, what are the three or four different ways that someone could potentially interpret this? And are all of those ways okay? If they are, then I think we're okay with the way we've worded this. But if there's two or three different ways, like, No, we really don't want someone doing it that way, that we need to change the wording to understand that. And you're not going to get everything. And that's why you know documenting, you know within that the why behind the changes that you're making. I think it's not uncommon for someone on the commercial side to look back and see the history of something changing, and the documentation for why that was changed or what led to it is is not enough for someone without that background or that history to really understand that. So improving the the process, and making sure that the critical things, if it needs to be done this way, that it's called out, and then the background information as to the why, what have we learned? How did we learn it, and making sure that that's following the documentation along with the process, so that the teams have access to it
Aaron Moncur:in your roles. Have you most often been an environment where you're vertically integrated, and your teams internally are the ones who are doing the production assembly. You have operators and technicians who are doing that or sending it out to a contract manufacturer.
Daniel Gledhill:Yeah, we do a lot of both. I think coming out of covid, we realized that there were key areas that we needed to vertically integrate, and I think that's been something that we've been working heavily on, and so we've been heavily partnering with some of our suppliers, but then also heavily investing in vertical integration in key areas. So a lot of both
Aaron Moncur:any pro tips that you can share with the audience about how to work with a contract manufacturer when you're scaling up a new line, because it's difficult either way, right? But if you're doing it with an internal team, you have obviously more control and visibility over what people are doing, but sending it to a contract manufacturer, that's got to be kind of scary, right? You're sending your baby out to someone else and relying on them to do it right? Any pro tips or pieces of advice that you can share how to do that successfully?
Daniel Gledhill:Yeah, I think often we give, and I can only speak from, from my experiences, but we give a manufacturer, you know, 50 to 75% of the information, and expect to get 100% result. And I think that's often the piece is, are we truly investing in them as a partner? Are we, you know, committed to them being successful and helping support us? Often, there's a fine line between, you know, what you know, what IP do we want to share with them, what things do they truly need? But more often than not, I found that, you know, our suppliers want to do a good job and want to provide us with what we need, and maybe they're building things to the drawing, but we didn't communicate that, oh, we've only been, you know, using the upper spec of this drawing, or, you know, small changes like that. So I think if his understanding, hey, is this a supplier that we need to invest in as a partner and then truly treating them as a partner. And I think the times that we've done that, we've built really strong relationships where they've been willing to bend over backwards to make sure that we had what we need, even if it was, hey, we maybe didn't communicate well enough with you truly what we needed. And this is it's not it's your fault, it's our fault. It's how do we get through this? How do we fix it? And so for me, I think it's all about that relationship and investing in that relationship. And if you do, you'll get the rewards of of it wonderful.
Aaron Moncur:Okay, let's talk about leadership a little bit. Have you identified any any ways to successfully help a an individual contributor transition from that role into a leadership role, like, what? What does a successful process there look like? Obviously, it's not an overnight process, but there are, are there any individual elements that that you've seen to be. Very effective and contribute to a successful transition in that area.
Daniel Gledhill:Yeah, I think I would say two things on that, as as a leader. I think what, what my role is in helping facilitate that is, number one, to remove the boundaries. So I think often we feel like, Hey, someone has to report to me, for me to be a leader, or for me to impact them. And I think working through and understanding that you're going to become a leader long before you have direct reports. And there are so many opportunities to lead a project, to lead an initiative, to lead a team that doesn't report to you, and there are so many opportunities to do that. There are so many opportunities to mentor, to coach, and so I think that for me, it was, hey, I don't have direct reports that I can give to every engineer that wants one. But it was about removing those boundaries that I think people just put on, just because that's what they've seen, versus understanding how many opportunities there are just within the role that they're in, to begin to get feedback, and to begin to, you know, receive that feedback, and understand, you know, what, what do I like about this? And what do I not like about this? Because those are probably the most pleasant or the most enjoyable facets of managing people. And if you don't really enjoy that, then you're, you're probably not going to enjoy the rest of the things that that go with it. So I'd say that's number one, is just removing those boundaries and then facilitating the opportunity. You know, whether it's leading a project, whether it's aligning on mentorship of, Hey, these are some of the things that you're great at, and these are, this is needs that we have within the group. How do we, how do we drive that? I think leading Kaizen events was a big opportunity that we, we tried to leverage for some of our engineers. But I think if you can really focus on just removing those kind of mental boundaries that people have with people leadership, and then finding creative opportunities. Because I would say the strongest individual contributors that, that I've worked with are people leaders, and so the the difference between the two is is smaller than, I think we often think that it is. It's just of whether you know they're dealing with the administrative pieces of being that person's direct support and leader?
Aaron Moncur:Yeah, it's a good point that you don't need to have the role, title of leader, manager, director, whatever, in order to be a leader in a team. Yeah, absolutely. What are some common pitfalls that you see with new engineering leaders. Pipeline now offers procurement of custom machined parts at significantly lower costs without sacrificing speed or quality. We design and build custom machines ourselves, so we consume a lot of precision machined components over the past several years, we developed a proven overseas supply chain to support that work, and in 2025 we successfully piloted that capability with select customers. Now we're opening it up more broadly, if you'd like to see how our prices and lead times compare. Send us a drawing or two for quote, visit team pipeline.us. Or message me directly on LinkedIn.
Daniel Gledhill:Yeah, I think that the the biggest mistake that I see is, I think as we embrace a leadership role. We kind of go from that individual contributing role, or just as an engineer, as someone that likes to get things done, we feel like it's still on us to solve that problem and to make that change, or it all falls on us to to have those those answers. And I know I did that. I still sometimes do that, and I think that's probably the biggest, the biggest gap of when you're transitioning to understanding, okay, you know, my role is really to facilitate this getting solved and this getting done. And if you're able to coach and facilitate and mentor your team to come up with those solutions and to deliver those solutions. That's what success looks like in your role. But as a new manager, you're still your mindset is, what am I contributing to that? And it's so much more difficult to say, Okay, well, you know, I challenge this person. I asked them a question. I you know, how is, how is? How does that compare to, you know, me actually solving the problem? And the reality is, is there's so much more value in being able to, you know, facilitate that piece, but it's just not the way our brains are, are structured and set up to work, because we're just used to solving problems and being, you know, the person that's solving that. At that problem. And so maybe it still is solving the problem. You just got to change your mindset, set mindset as to, what is that that problem? And now the problem is, I need other people to solve these problems, and so how can I work through them to get the solutions and the creativity that I need?
Aaron Moncur:What does that look like in practice? Can you think of any specific situations that you can share a story, maybe where those points are illustrated, facilitating rather than the actual doing?
Daniel Gledhill:Yeah, I think I refer to a book that had a huge impact on me, and it's called managing to learn, and it walks you through. Okay, hey, someone comes to you with a problem. And I think for me personally, I can attest that, you know, if, if I'm pushed, if I'm in a rush, my natural state is just to give people the answers. And so, you know, when things get busy, someone comes to me and they're like, Hey, this is what I'm looking to do. I'll say, hey, well, I think you need to go this way. Because if you don't, you have this or this that you know that could impact you, or do you know, the validation here calls out that you needed to do it this way. And if you go that direction, you're going to have, you know this and this happen where you know, if you know, one of my engineers or someone comes to me and they say, Hey, this is kind of what I'm looking to do, you know, changing that conversation to be of, okay, how do you think that could impact the validation strategy for this? Well, you know, and they're kind of going through those and say, Okay, well, do you think that that will still meet the intent of the validation do you, you know? How? How do you think that your quality counterpart is going to look at this change, and so just asking some of those questions to leverage the knowledge that you have, but allowing that person to manage through the problem and solve the problem. And now you've created a an environment where they're like, hey, I can think through this. I can drive toward a solution, versus, I need to go to my manager, because I need to make sure that they're on board with the direction that I'm going, where you've now facilitated an environment of, okay, I I can go through this, and I can go back to my manager and say, Hey, this was my thought process. This is how I went through it. Do you see any gaps? Versus, hey, I need to know what to do. And so over time, it really changes that come from that that communication and that confidence that you build in your engineers, where they're a lot less reliable to you, you know, to to needing you to solve the the problem. I think that's the most rewarding thing for me as a people leader, is seeing an engineer come to me and say, Hey, I started thinking through this like this. This is how I approached it. These are the, you know, the things that I looked at, and then asking, Hey, do you see any gaps in how we've looked through this and and really finding value in seeing, okay, hey, I've really created an environment where I'm helping you be successful, versus, you know, clipping your wings essentially by saying, This is how you need to solve the problem.
Aaron Moncur:I love the strategy of using questions to provide feedback and guidance. Oftentimes, when a team member will come to me with a suggestion and I know, or at least, I think I know for one reason or another that it's not a good idea or it's going to lead to some less than ideal outcome. It's tempting to just say, No, don't do that. Do this, just like you were saying, right? But that can, over time, I think, breed a little bit of resentment if you're just telling people what to do and saying no to their ideas, even if no is the right answer to the idea. But using questions instead, I think, is a really powerful way to help the individual understand and get to that answer without you having to say, No, you know, asking the question, oh, that's a great idea, interesting. Thank you for thinking about this, what would happen if we were to execute on that idea? And, you know, considering this and this and that, and I found that pretty quickly people get there on their own and they're like, I mean, this just happened to me the other day. Someone came to me with an idea of, like, I don't know if that's going to work out the way you think it is. And so I just asked some questions. How do you see this part of it playing out? And what's going to happen at this point when this guy comes in, does this thing, and the team member, like, pretty quickly, was like, Oh yeah, you're right. I see what you're you're saying. And then there's, there's no resentment, right? You're not telling them, No, you're not telling them what to do, even you're just asking questions. And they get there all by themselves.
Daniel Gledhill:Yep, it's, it's a strong way to lead. And if you do it with a natural curiosity of, I just really want to understand what you're thinking, how you're going through this thought process. I think it just only strengthens your your relationship. Yeah.
Aaron Moncur:And the other great part about that is you. Might be wrong. Sometimes you might think the answer is no, but instead of just saying no, you ask the questions, and your team member gives you answers, and they might surprise you with something you hadn't thought about, which is another just great outcome of the question based feedback, absolutely. All right, there's a lot of data out there these days, right? There's data overload. Sometimes I feel like, how, how have you seen data change over the years, and especially in regards to how you make decisions?
Daniel Gledhill:Yeah, so medical devices is interesting because I came from the first five years of my career were in mining and going through and trying to understand how is this plan operating. And I always had an abundance of data. I had pie tags that I could look at. I could trend any valve, any part of the operation from my desk. If someone called me in the middle of night and said, Hey, things aren't looking well, I could log in and I could see exactly what was going on at the plant. I moved from that, and that just why. That just was my intro to industry. And I moved from that to medical device, where you know you're you're integrating fairly quickly. You don't the processes are still, you know, you're moving quickly. The equipment isn't as large or as big, and, and you're very reliant on operators and hands on techniques to build these. And I realized how little data we actually had, and, and, you know, just trying to understand, Okay, how are we making some of these decisions? Or, you know, all the data that we had was attribute and, you know, that was, you know, manually, just collected through, you know, scrap reports and different things. And so I think that that's a big difference within the medical device industry. And I think the a huge shift as we move forward is, how do we design and incorporate data integration SCADA into into our design processes, so that we can understand how our equipment is running, so that we're not reliant on an attribute, this product is good, this product is bad, but we can actually Look at variable data for our equipment. You know, even be one step upstream from our devices and looking at our equipment, hey, our equipment starting to shift or change, and those were pieces that we didn't even have any visibility or access to. And was a huge investment that we had put in over the last maybe five years to, you know, as I moved to a new area that had, you know, more data rich environment, we just didn't have access to that data. And so that was really the the shift. And the change is, how do we, how do we take the data that we have, number one, and put it into a format that we can access and we can look at? And me, coming from the mining industry, I always had this visualization of I want a schematic of the line. I want you to be able to click on any individual piece of equipment. And I want within that piece of equipment, you can see how everything is trending. If we have duplicate lines, you can trend pump that's on this line versus one that's on the other line. You can watch if it's a batch process. You can see how all the different processes, you know, are lining up across the different lines. So as an engineer, you can come in and you say, Hey, I've got these different trends that I look at every morning to see how my process is running and and that's really the direction of, how do we get data in in a way that's accessible to our teams? You know, SPC monitoring is huge in a manufacturing environment, is beginning to see changes within your process before they trigger a downtime or a loss of yield, and really looking at those things upstream. But the challenge is the infrastructure, the it, the IT, pieces of, hey, everything, what we do, is proprietary, you know, bringing in another company to help connect that data. Or, you know, SCADA is a validated within our systems. It's a validated connection. You know, some of that data is used to make accept or reject decisions for some of our devices, but that's not the case for maybe how we're running some of our equipment. And so all there are, there alternate pathways to make it a little bit easier to set up and and manage some of that data, and then really helping your engineering teams understand, okay, this is how we leverage data for monitoring our processes. And now, how do we also leverage data and use it for troubleshooting, to try and understand, hey, we have this variation. How do we understand where those variations are coming from? And so then it just once you have access to that data, then you can kind of go down the rabbit hole of, how do you set it up and structure it, and train your team to be able to look at it the right way? Because for me, I would say more than half of the. The results, or the things that you know, come to me and they say, Hey, this is what this data is showing me, you know, through that kind of question based approach, we generally get to the point of, you know, maybe what we thought was going on here, we really don't know, because we haven't either isolated enough variables. We haven't truly, you know, understood other impacts. We haven't limited, maybe our material variations, and so I think that's really how data has kind of integrated into the medical device space. But it's still just it's almost old school manufacturing, where it's just so hands on and labor intensive that unless you really invest in getting beyond attribute data and data that's tied to your product and your yield results, that's really, I think, the next level for how we design some of these processes and integrate that into them, so that we can have that control and that visibility upfront.
Aaron Moncur:Are those systems in place today, or is that kind of the next generation of medical device manufacturing?
Daniel Gledhill:Yeah, I think that I've seen it at some sites where they they've integrated those things already, and others where it just it maybe it doesn't make sense, because you're, maybe you're integrating on this device every two to three years. And so, you know, how much do you want to invest in those, in those systems, unless you can invest in a system that can then roll over device to device? But that's really the direction that I I'm seeing medical device manufacturing going really kind of following the TPS system and really trying to, you know, have a better hands on approach to the data. How we manufacture single piece flow, flow, where in the past, really, it's been, hey, this is a short term process. There's a lot of variability in it. It's very heavily reliant on on operators still, and so do are you going to get some of the benefit of some of those pieces. So as we move towards integrating more automation, more standard processes, I definitely think that that will be a huge transition we see in medical device over the next five to 15 years, and some lines are already going to be there. But my expertise with catheter manufacturing is just such an it's such a manual process that that's that's what you see.
Aaron Moncur:Is it so manual just because the the dexterity required to assemble these devices can't quite be duplicated by robots and machines yet? Or are there other reasons for that?
Daniel Gledhill:Yeah, I, I definitely think that if you were to commit to one iteration and just say, hey, we want to automate this and design processes to do this that you absolutely could. I think that the but the cost is, you know, and then, okay, how long until this device is obsolete? And so, when you're dealing with novel procedures and novel technologies, they're changing, you know, we whether it's every 2345, years, you're iterating on that, taking feedback from the patients, from the doctors, and trying to make improvements. And so there's just, there's times where maybe it, it doesn't make sense to invest that heavily in in a comprehensive manufacturing process. But if you know, hey, this is a critical part in making this device. We know we're going to continue to use this. Let's invest in this capability. Let's invest in in automation of maybe our laser processes, of, you know, laser setup. Let's remove the operator from the setup process in how we design and build this and those absolutely so it's finding the opportunities.
Aaron Moncur:Yeah, yeah. I'd love to hear from you how you measure success as a leader. And then second part to that question is, is there an experience that you can share, some story that you can share where, where you, as a leader, made a decision that had a meaningful impact on the outcome of a project or the team's morale or performance?
Daniel Gledhill:Yeah, absolutely. I think I'll go back to an initiative that we were trying to launch, and it was around operator suggestions. So at the time, I was in a operations role, so leading a team of supervisors and frontline employees, and we had worked to roll out a new suggestion program. The idea was to double down our investment and our frontline employees and get them engaged in the process, so that they are owning the process. They're owning changes in the process and how we're going to manage through that. And we had pulled a lot of operators, leads, supervisors, into this team. To create this. And, you know, soon after we launched, we brought the entire site in to, you know, kind of understand, you know, where, where we wanted to go with this, and just to kind of see how it was working within our team. And so we get everyone there, we're going through, kind of our tiered meeting structure that we had at the time, and the we had a few new suggestions. And so we just all right, let's read these new suggestions. And one of the suggestions from one of the employees was that the engineers and supervisors needed to take a class on the female anatomy to better understand when females or employees need to go to the bathroom, and I was just sitting in the back, just steaming and fortunate. Fortunately for me, it wasn't an opportunity to really kind of disappointed, as I was just say, okay, hey, we'll absolutely follow up on that and and luckily, I had a day or so to just kind of vet through it, talk with the supervisor. He's like, Yeah, I recently, you know, had to have a conversation. And wrote this employee up, because within a clean room environment, like it takes a while to change to to ungown, go out, go to the bathroom. And so it's like, hey, you know, things happen. But if it's, you know, continually, every day in between your scheduled breaks, you're going out. And so luckily for me, I had some time to kind of think through it. And as we were trying to launch this, I mean, this was one of our more outgoing frontline employees that was invested, but, you know, didn't really feel like, hey, what we had told is, hey, we're going to take every suggestion seriously. And so luckily, you know, I had the time to kind of think through it, to talk with the supervisor and and I came back and just, you know, pulled the operator off the line and said, Hey, I just want to thank you for using the system. I want to make sure that you know that we're going to follow up on these ideas. But for this idea, we thought that the best person to teach this class would be you, and she just immediately turned feet red and was like, no, no, no, that's not what I want. That's not and and it it just it opened up the opportunity to then turn what could have been a very negative thing into, okay, well, what did you want? What? What was your goal with this and, and she's like, Well, I was actually just, you know, venting because I was frustrated about something. It's like, Well, do you understand that maybe this isn't the right avenue to vent, because we really want to leverage the good ideas that you have and, and by managing through it that way, understanding her why, taking that time to coach, to understand where she was coming from, she became a changing, change agent for the for the whole program, and was able to shift kind of the direction that we were, we were trying to go, and how we were trying to manage that. And I think for me, that always, I'll use another example, actually, with within supervision is I had a team that I had launched. I'd hired them all, and I had gotten pulled into some other responsibilities, and I came back to that team and I was like, hey, I need you guys to do this, this and this. And the three of them just kind of got together and looked at me, and they said, you know, we don't really like working for you anymore. And I just was like, heartbroken. I was like, you know, this was a team that I had hand selected. I'd spent so much time with them. And I just like, you know, just took a couple seconds to kind of just absorb that. And I was like, you know, stop whatever I was doing. Yeah, exactly you know what? What do I what's going on? What's the change we used to come in. You used to ask how we were doing. You used to engage with us. Used to make us feel like we were the most important. And as I grew and became more busy, I realized that it was just more transactional. It was hey, this is what I need you to do. This is where I need you to go. And that, for me, was one of the biggest turning points for my leadership career, because it created and identified a weakness in me. Any any leader is going to get to the point where they have more to do than than they can they can get done and and once that happens, what are those things that maybe shift or change. And for me, it's more of Okay. I need to be more efficient in my time. And I need to be, you know, I need to have these transactions. I need to go and manage all these things when I was actually just doing more harm by shifting to to that when people are people, and they, they notice when, you know, hey, do you care about me? Do you care about are you investing in me, or are you just in you know, need me to get something done for you, and I think for me, and how I've measured my career is, you know, am I developing those relationships? Am I being at. I think the thing I like to say is, being present where I am is, hey, if someone's stopped me in the hall and I'm already linked to another meeting, say, Hey, give me one second. Type a little team's message or something. Hey, I'm running a little bit late. I'm not always great at that, but that's the best way to handle it. But then being present with that person, because that that is what's going to shift or change their perspective and and if you look at culture with an organization, you set all these bounds and all these words around culture, but culture is developed one interaction at a time. And you know, if I turn that interaction into something negative because I didn't have time for that person, versus being present where I am, and, you know, trying to be accountable for other places that I need to be, but really that taking that time upfront. And so some of those are some of the pieces that really shifted how I looked at leadership and how I looked at success. Because, like I kind of mentioned a little bit earlier, is it's, it's difficult as a leader to go from Hey, I accomplished this. I got this done. I I was able to solve this problem, to hey, I had this conversation with someone. I was able to kind of tweak their their mindset a little bit, or my team was able to accomplish these things. And at the end of the day, if you don't really kind of dig into what behaviors you're trying to drive, and did you have the interactions with people that were driving those behaviors? If you don't just change your perspective of what you're looking for for success, then I think it's really hard to see that success. And so I made it a point at the end of probably not every day, but at least the end of the week to kind of look back and say, Hey, these were some of those interactions that I had that I think really moved the needle and where we wanted to go. And then also retrospectively, said, Hey, this is maybe one that I could have handled better. And then taking the initiative to go and say, Hey, remember when we talked about this the other day? I realized that maybe I wasn't, as, you know, attentive to you as I needed to be. And I think more often than not, people were like, Oh, I didn't, I didn't feel that way, but I really appreciate you, you know, addressing that and being upfront with it. I think that is, that is what really drove that culture and that shift and that change, and really was what I found to be the most rewarding as a leader.
Aaron Moncur:Wonderful, wonderful stories. Thank you for sharing those. I think a lot of people are going to hear those and walk away with great insights that they can apply right away to their lives and their work environments, and probably beyond just work environments. But you're so right that everything we do is with and through people. And like you said, people are people, right? They're not machines. They do have feelings, and we need to be aware of those feelings. How great that this team that you'd put together felt comfortable enough coming to you and saying, We don't want to work for you anymore. I mean, as painful as that was, I'm sure, how wonderful that they felt comfortable enough with you, and that says a lot about you as well, to make such a candid statement, and it just led to such a wonderful outcome in the end, you know, I think this is a good opportunity. I recently came up with a new definition for the word leader, what it means to be a leader, and it just it dovetails so nicely into the stories that that you shared. So I'm going to share my definition now. It's a little woo, woo. I'll warn you up front, but my definition, I just came up with this last month, and I love it. I think it's so beautifully simple. A leader is a guide who loves you. And those two things have to be true. There has to be a guide, right? Someone who has knowledge or information that he or she can impart to you that's going to help you move from where you are right now to a better place, whatever that looks like for your situation. And then the second part, this leader, to be a leader, under my definition anyway, has to genuinely care about you. They have to care about you as a person. They have to have some love for you. And if they don't have those two things, then at least under my definition, that person is not a leader. But I look back in my life at all the people that I truly consider to be leaders who led me. And those two things are always true. They were a guide. They had some kind of knowledge to impart. They helped me move from where I was to a better place, and they cared about me. And I think if you, if you have those two things, and there's, there's a lot that can be done from a place of leadership. So that's my my Woo, woo, definition of what it is to be a leader.
Daniel Gledhill:I love it, I think, to the point that you brought up, if you look back through your career and you look at leaders and you look at people that influenced you or made a difference in your life, they're going to hit those two things 100% Yeah. And, and if you're in a position where you maybe aren't getting that, I think. That you can still learn by someone who's guiding you, but the people that are really going to impact your life and really help you get to an understanding of where you want to be and what you want to do and how you want to do it. So they're going to have both of those
Aaron Moncur:pieces Absolutely, yep. All right, Danny, well, let's wrap this up here. One more question. What is one thing that you have done or observed to accelerate the speed of engineering?
Daniel Gledhill:Yeah, I would say, you know, with with my role as a leader and more as a facilitator, I think the biggest piece for me is removing obstacles. And if we look at a an engineering environment or a manufacturing environment. I think those obstacles really are, what are things that my engineering team are doing that's not engineering and it I've had times where we've looked at that and it's been, you know, 7080, even 90% and so it's, how do we, how do we, you know, remove those things. How do we create systems or put, you know, how do we train others? How do we, you know, maybe get the technicians or get operators to buy into TPM and start doing some autonomous, autonomous maintenance on our policies. How do we get operators to do SPC monitoring, so that they're making shifts and changing and they're understanding the processes, so that monitoring some of these processes can be done by the teams that are out there and present, so that our engineers can invest in doing engineering work. So I would say, as a engineering leader, especially within manufacturing, I think it's with any in any industry. It's about removing obstacles and creating opportunities for your engineers to do engineering work and be creative, rather than just responsive and and and firefighting. There's always going to be a lot of that, but understanding where they're spending their time and creating and removing the obstacles that are keeping them from really doing work that is going to be meaningful to them and to the business.
Aaron Moncur:Wonderful advice. Fantastic. I agree strongly with that removing obstacles. I'm a I'm an impatient person by by nature. And one of the things that just frustrates me to no end is when I get slowed down. And this can happen for a variety of reasons. It could be, you know, an IT thing, the program, the whatever Microsoft Word I'm trying to work with, or the spreadsheet crashes, or something happens, and it just it drives me crazy when I can't do the things I know I'm supposed to be doing, because something has slowed me down. We were a fairly small team here at Pipeline. Got about 15 of us, and for a long time, the engineers were the project lead anyway, for any project that we took on, the engineer would would be the one who set up the project in our system and and then engineers, during the course of that project would, they would actually write POS and send POS to vendors when we needed to order things. And this was one of the things we identified that was slowing our engineers down. It was an obstacle that needed to be removed because that's not engineering work. And so we hired someone. We hired a project admin, and now this person does all of those things when a new project comes in, she sets it up. When the project is over, she closes it down, all those little, miniscule things that need to be done in the background for a company to operate efficiently. But it's not engineering work, right? And then she writes all the POS now as well, and it's it's had such a huge positive effect on how we run our projects, and frankly, the overall level of satisfaction with the engineers, because now they get to focus more of their time doing the engineering work that they love, as opposed to, you know, kind of administrative stuff that's really can be done by someone else.
Daniel Gledhill:Yeah, that's an awesome example.
Aaron Moncur:All right. Well, Danny, thank you so much for being with us. What a great episode. You've shared so much insight and knowledge with with all of us. I really appreciate it. How can people get in touch with you?
Daniel Gledhill:Yeah, I'm pretty active on on LinkedIn. I don't post a lot of things, but I do a lot of reading on LinkedIn, so I think connecting with me on LinkedIn would be a great first step, and love to continue this confirmation, this conversation there.
Aaron Moncur:Excellent. All right. Danny, thank you again, so much for being on the show today.
Daniel Gledhill:Yep, thank you.
Aaron Moncur:I'm Aaron Moncur, founder of pipeline design and engineering. If you liked what you heard today, please share the episode to learn how your team can leverage our team's expertise developing advanced manufacturing processes, automated machines and custom fixtures, complemented with product design and R and D. Services. Visit us at Team pipeline.us. To join a vibrant community of engineers online. Visit the wave. Dot, engineer, thank you for listening. Being an engineer has more than 300 episodes, and you don't have to listen to them in order if you're dealing with a specific challenge right now, there's a good chance we've already interviewed an engineer who's been through it. You can jump around, search by topic and listen to what's most relevant to you. See you on the next episode, you.
