#378: Who Owns the Design Controls Process?

Etienne Nichols: Welcome to the global medical Device podcast, where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge direct from some of the world's leading medical device experts and companies.

Etienne Nichols: Hey guys, are you struggling with regulatory compliance, product development or clinical investigations? You can say goodbye to headaches with Greenlight Guru, the only quality management software and electronic data capture system built exclusively for medical devices. Streamline your processes, ensure compliance, and get your products to market faster. Join thousands of med tech professionals who trust Greenlight guru. Are you ready to accelerate your success? Visit Greenlight Guru today www. Dot Greenlight Dot Guru. FDA and ISO compliance can be daunting and oftentimes a complex process. Root quality systems makes it easy with their comprehensive compliance services. Whether you're preparing for an audit or need help with documenting your design, controls, risk management, or quality system, their experience team is there to support you every step of the way. Visit rookqs.com dot and achieve compliance together. That's rookqs.com dot.

Etienne Nichols: And with me today is Laura Mayer. Good to have you today, Laura. How are you doing?

Laura Maher: I'm doing pretty good. Happy to be here.

Etienne Nichols: Okay. I wanted to talk to you today about product development, specifically about design and development, or what was previously known before QMSR as design controls. And what made me think of this, just for those of you are listening on LinkedIn, sometimes I like to put out some polls, and I had a poll that had 364 votes, and the poll was, who should own the design and development documentation for medical devices? And so that documentation, we can read that in a different, a couple different ways. Is that just the documentation? Is it the entire process? I don't want you to read too much into it, but just think, who should own the design and development documentation for medical devices? Most likely the design controls or the trace matrix.

Laura Maher: I had kind of a unique experience. I started in quality, and so that's my background. But then I fell into product development, and I was that person responsible for filling out all of that documentation. So I just see a huge value in having ownership with someone who understands what the documentation should look like, but they also need to understand the product development process really well. So I think that's a it depends type question for me of like, there's just a lot of nuance that goes into it.

Etienne Nichols: Yeah, well, and that's what was funny is because when I put this poll up on, on LinkedIn, I mentioned there were 364 votes. Well, 80% of them said product development. Oh, it's got to be product development. And that's kind of what I was expecting. I was a little surprised that 6% said regulatory affairs and 10% said quality assurance, 4% said others. See the comments. And that's where I saw your comment, which was exactly as you just mentioned. It's really, it would be really great if you could find someone who has that PD mindset, but also has the Q, QE or QA experience so that they can have something of a Venn diagram.

Laura Maher: Yeah. And I think, like, for me, I did a course in design controls kind of early in my time there, and that really helped me understand because I would say, you know, product development engineers, and I'm not an engineer by training. And so I think that may be kind of what made a difference for me, is like, I wasn't fully designing. I was doing the quality engineering type work, helping launch products, helping scale up products, but not necessarily designing the product itself. But I think it's important to understand design controls really well. And I would say that both people on the quality side, if that's solely their focus, or people just on the development side, or even in regulatory, may not fully understand what's expected or what the format or the context of the information needs to be in, or kind of like the perspective of just being an auditor and looking at it and trying to understand it. So I think when you can find somebody that can look at all of those perspectives, I think you just overall end up with cleaner documentation that ultimately our goal for this, I mean, it's not going to regulators. That's not what we submit. It's what auditors look at and what our future engineering teams look at. You know, ten years down the road when we have all won the lottery. So it's like understanding your audience and presenting it in a way that makes sense for those audiences. And I think that's what's important.

Etienne Nichols: Yeah, and that's a, that's a good point, because sometimes we talk around this issue of design. Design controls, the, the, the term that I've really started to adopt for the person who I feel like should own this is the design assurance professional. And so to me, that's a cross pollination of product development, someone who indesign and someone who has that quality experience. So design assurance, to me, that term kind of encompasses both sets of experience. But maybe what we could, maybe what would be beneficial is to talk about what the expectations are for that person, because you mentioned you kind of fell into that role or grew into that role from a different direction than is traditionally expected. What were some of the things that you learned in that design controls course or through experience that really set you up for success? Do you feel like?

Laura Maher: So I think we spend a lot of time on the definitions of the different design controls, starting with user needs, which if you look in ISO, if you look in the FDA regulations, it's not specifically stated that needs to be a column or a specific input to your matrix. But it's something that if you use our software you're familiar with. That's kind of where we start. But there are mentions in both of those documents of user needs are starting with what the patient needs are or the indications for use. So I think really kind of digging into that of you don't create, you don't engineer, and then figure out a use for it. We start with use case, we start with user needs and how to define those within our documentation, and then how do we translate those to workable user needs? How do we realize those and prove that through our outputs, and then a lot of time on verification and validation that some, these are all like sticky terms for people that don't always make sense of, like, what falls into verification, what falls into validation. So that course was incredible because it helped me understand what these definitions mean, what are realistic examples in a project or different types of projects. So it just kind of sets you up to just know how to present your project overall, write definitions. And when you show that you understand definitions, I feel like that puts auditors a little bit at ease because, you know, you look like, you know what you're talking about, at least.

Etienne Nichols: Well, I want to. I want to emphasize that maybe go down just a few more steps down that rabbit trail, if that's all right. And that is the audience you mentioned. You got to know who your audience is. Maybe it's not necessarily for the regulators. Can you talk a little bit more about that? Who is going to be looking at this design and development documentation? And how should you know? Who is it? Who's it really for?

Laura Maher: So it's for, you know, a lot of people in your organization. And from my experience, my, one of my first projects at my first medical device job outside of quality control was remediating dhfs. And so, you know, we were coming into these dhfs a decade after they created to understand kind of the approach to design because there'd been full team team over, or team turnover. Sorry. And so understanding the design, how they verified things, validated things, tested things. So you got to think about future engineers, because this product, we're not designing and creating this documentation just for launch. This is something that lasts the lifetime of your device. And anytime that you come back to it to make design changes or make second iterations of it, or release product extensions of it, we're coming back to this file and making sure that we're still meeting user needs, still meeting inputs with our changes, and documenting those changes within that. So it's really important for your engineers to understand why things happened and why you chose the things that you did. And then also that's the first thing. If you're a design firm or any company that creates designs, medical devices, an auditor comes in, they're going to ask for your most recent design history file. That's going to be the first thing they look at. And I've been in like FDA audit, ISO audits for FDA. They're going to look at 510 products. We had a mix of class one. ISO is just going to look at probably most recent, most recent one or two. You know, we have a lot of CMD customers that are coming into the market and I think a lot of times, you know, they're approaching the design and development with the same process, but a different kind of format, and often wonder what the importance is of this design and development file, including the trace matrix. And it's always to help other people understand your device and your approach to designing it and making sure that it's safe and effective. So I always try to like it. I think getting too technical, I guess, in the wording of some of these documentations can be a little bit of a killer. We've got all of our reports, protocols to data to kind of back that, but our trace matrix and kind of what we present needs to be clean. It needs to be concise and understandable and follow a nice flow as you go through.

Etienne Nichols: Yeah, it's a collaborative document. And I think a lot of the comments in my poll, when I put that on LinkedIn, a lot of the comments kind of spoke to that needs to be a collaborative document. Who's going to own it? One of the assumptions we need to tease out when we're talking about who should own something like the design and documentation for a medical device is what's the purpose of owning it, is the product development team. They're going to own it for a little while, perhaps because they're designing it. Maybe the quality team is going to take ownership at some point because they're going to be defending it. The regulatory team is going to be taking all this information and building out something to submit. So everybody has a stake in this as far as ownership goes, who's actually implementing the wording. There's going to be a point man. And in my experience, sometimes it's been the project manager, but maybe they don't really have the medical device experience. They have project management experience, but maybe not the medical device experience. And so when I look at this design assurance professional, I look at it as that is the person who is almost a gatekeeper for the document itself. And I'm going to, I'm going to throw one other person out there because I mentioned the project manager, they're making sure the project's happening. There's also the project lead who might be the very experienced engineer who is doing genuine engineering things. They are, is submersed in CAD, whether it's solidwork, solid edge, whatever. And they don't really want to do any documentation. That's the personality that you usually have. So those two people are kind of a tug of war for control. One's leading the engineers down the engineering path, one's project management, who's got a report to management. And I almost see this design assurance person as a third person who is almost an interpreter or translator. What are your thoughts?

Laura Maher: I agree. I would say it's almost like a technical writer, like your design assurance person person should understand or I guess be more of a big picture type role, sort of like the project manager, where they kind of have an understanding, or maybe they're involved with more meetings than just engineers or just quality so that they can stay a part of that big picture and understand what's going on. But again, they need the technical background so that they can write. It depends on what the scope of that design engineer is or design assurance engineer, because for me, I was writing all of the documentation because nobody else wanted to write. And I somewhat not to pat myself on the back, I'm fairly good at technical writing. So, like, it just kind of worked out that way that I ended up being that person to do all of the documentation. But it's just, you know, someone that can understand the whole project, that can understand the design side or understand the engineering aspect of it, understand what's going to want to be seen, or have a good understanding of, like, sampling size or you, you know, maybe even be a bit of a designer or regulatory consultant in that regard of like, knowing the right approach to testing or maybe what testing needs to get done throughout and kind of guiding that. So, yeah, I can see that being kind of more, maybe more under project managing of like, being the technical writer or more involved with the doing than the project manager.

Etienne Nichols: I guess I was a project manager for a drug delivery combination product. But prior to that I was working as a project manager, which is how I got my PMP as a project manager on a regulatory project that had to deal with manufacturing. A lot of regulatory, a lot of purchasing, a lot of quality. And just because we were remediating a lot of about 250 class two medical devices to make sure that they were UDI compliant with direct part marking. So I say all that, say I had to meet with a lot of management. I had to make sure we were on timelines and so forth, make sure that we were in the schedule for all the different fixtures that needed to be validated and made and so forth. Right hand man who is really granular and, and without him, it would not have worked. And I almost see him as this design assurance person. He was the one checking every drawing that came through and making sure he under, he had a, understood the, the network of traceability that had to, that was going to impact every DMR and DHR.

Laura Maher: Yeah.

Etienne Nichols: So yeah, that, that was, that was really helpful. And that's kind of how I see this design assurance person working in medical device companies.

Laura Maher: You brought up something, DMR. I didn't even think about that because I was responsible for making sure that that happened because there's so much, I don't know that quality always gets involved with like the DMR, other than it's a quality document that needs to be managed in the quality system, but the details of it, but kind of knowing the structure of what it should look like, the information that goes in there, where to go into the design outputs and verifications to get that information. But yeah, it's just kind of a big coordinated effort because there's just so much documentation that needs to come out from the design and development file, the DMR, the procedures. I feel like DMR is also a little bit confusing because DMR is a document, it's a procedure level document, but it's also, to me, a file as well that contains, you know, the IQ OQPQs that you did, anything else like that, your procedure lists for that particular product. But yeah, there's just a lot, there's a lot that has to get done and has to be coordinated across and.

doing this to myself for ISO: 1345

Laura Maher: If you could develop a design assurance person, have them be evolved at every step of the way. And I think that's kind of the value that I had, is I got pulled into a project and I started at voice of customer stage of like go. Literally going to hospitals, talking to nurses, talking to clinicians, giving them prototypes and doing prototyping myself and then kind of moving into the scale up of it. And then, you know, the design changes or they ended up being just a memo to file in that case, like a pretty simple change. And then through launch and marketing it and doing studies with it and things like that, it just gives you a good perspective on who needs to know what and kind of what goes into every single step. And I think you appreciate, you appreciate the design file a little bit more there because you, you've been through everything, so it's a little bit easier to tell a story of how we got there. I feel like I'm very lucky in having that opportunity to start beginning to end. I know with larger companies you're just, you do a thing and that's the thing that you do. And I have experience with that too, where it's like your tech file part is hazardous substances. That's what you're going to do and that's all you're going to do as part of this. So I don't know if you can get the opportunity to follow something start to finish. It's a really great perspective for creating a solid design file, I think.

Etienne Nichols: Absolutely. And, you know, some of these bigger companies, I think Medtronic comes to mind that I believe have the title design assurance or design assurance manager. They have this specific role that is design assurance. And I, I'm looking forward to interviewing some of them. I have some of them on my list so that I can get a better sense of what that means for that particular company. I'm sure it's obviously varies from company to company, but that's something that you mentioned. If you could grow a design assurance professional, how would you do it? Pulling them into every one of those different situations or scenarios or just following that? I think it's a good practice. So, yeah. This question, who should own the design and development documentation for medical devices? If you just put that in their hands, would you. Maybe, maybe we should ask this. Would you put the trace matrix and the risk matrix and that person stands and say you own the development of this document, see if we're going to.

Laura Maher: Bring risk into it? That's a harder question. I think that definitely depends on someone's background with risk management and if they like risk management. So is that risk management is either like, I really feel like it's a love it or hate it type thing. I particularly enjoy it. So I was happy to own, I mean, we were tiny teams, so I mean, I just did everything anyway. So I don't know. I think that's a tough question of who you put the risk into. I think someone should own it. But, you know, risk needs to really be a collaborative process all the way through, like where design controls. You can pretty much, as a one person, you know, team, just take the every, all the information you're getting and kind of map that out and do design reviews to make sure we agree. I feel like anytime you're building out a risk matrix, that needs to be a conversation and a collaboration and brainstorming type activity, because it's all about creativity and thinking about how everything can go wrong or how when things are going right, things can still go wrong.

Etienne Nichols: So we talked about definitions at the very beginning, so it might be worth looking at definitions again. Just at this point. When I use the word own, how would I define that? You own the success and the failure. It's really just your responsibility to make sure it happens. I guess that's the way I look at that. And so that design assurance professional doing that job with the design controls. Let me use the example of a project manager. The project manager is responsible for a project, but he doesn't actually, at least in my experience, it seems weird, you feel like you're not really doing a whole lot because a good project manager is the hub of communication and they're making sure communication flows. Now, there have been good times that I've seen good project managers, and I've experienced it where I wasn't doing that very well. But, but they're a hub of communication, and I think this is a similar, they really need to have that, that experience. So I think I agree with you. I don't know whether I would put that same person as the hub of communication or the, for risk management at the way they would with design traceability, but I agree. I think both of those should be collaborative documents that multiple people have stakes in. But who, who is ultimately the hub of communication? They might be different people.

Laura Maher: Yep. And you mentioned the project management thing, and I feel like this person that we're talking about this unicorn that people laid on their team to do their design.

Etienne Nichols: Yes.

Laura Maher: With project management, you feel a bad project manager. And then when you're under a good project manager, and not necessarily, some projects are just not everybody's thing, but when you're under a good project manager, things just go smoothly. And a lot of times if you don't spend time with your project manager, you'd be like, oh, what does this person do? They're the reason that your life is going smoothly, probably because they're communicating with everybody and getting all of the updates and keeping you on track and giving you a clear picture of what's happening. So I think, I think there is some project management skillset that would go into being a design assurance person of like, having good communication skills, knowing kind of when to bring resources in, and knowing when it's time to bring the whole team together. When it comes to design reviews, I could see, I could see that design assurance person maybe pushing when design reviews happen or seeing kind of good times for that to happen and making sure that gets facilitated. The right people are there. I things like that.

Etienne Nichols: I'm out for just a second because you said facilitating when design reviews happen. So I want to ask you your opinion on this. Design reviews versus stage reviews or phase reviews, whichever you want to call it. I have a, I have a personal preference on this, and it's actually okay. It's a strong opinions held loosely situations, you know, I don't know if maybe it's strong opinion held very tightly. I don't know. But design reviews, the way I look at them and define them as, that's a technical review, and if that's how you're using it, I definitely agree where that design assurance professional, they really needs to be pushing, hey, we are ready for a technical review. In this component of our design, you know, this sub assembly is ready. Let's have a technical review. Let's have a design review. Whereas the project manager is, should be in charge of stage reviews. And that's a company, company wide situation where we are going to look at our manufacturing processes. Are all the machines validated? We have a Iqoku PQ on the line. Are we going to do it this way? Have we gotten all of our suppliers vetted out? Are we at the right stage? All the. It's a stage review. Are we moving on to the next stage where we are? But they're two different things that can sometimes be conflated. What are your thoughts?

Laura Maher: I would say that they are different things that sometimes coincide. But I would agree design review is design focused, except for maybe when you get to design transfer, then I could see that being like a stage review and a design review coming together to make sure, you know, design transfer is happening and that we're coordinated on that front. But yeah, definitely different things that can sometimes align.

Etienne Nichols: And, you know, I think maybe this role differentiation or consolidation, however you want to look at it, historically, project manager is doing the role of design assurance, unless they've offloaded that to their lead engineer, where they're doing the documentation. But ordinarily, at least in my experience, I've seen those two kind of a tug of war with that design control trace matrix. And as a result, each one has their own opinion on when the quote unquote design review should take place. Project manager has his view of company. You know, I'm thinking of a company stage review where everybody needs to be involved and the lead engineer is thinking, I'm thinking of design review, technical review. So those are kind of a tug of war, almost like, no, it should be this date. No, it should be this date, because we're not ready. Whatever. If we were able to pull out this third person with design assurance manager and give them specific, hey, I. These are your responsibilities. This design controls trace matrix, and you work with the project engineer on the risk matrix. However, you want to lay that out where the project manager is again able to focus on that phase type or stage type review, you could almost separate those finely and have two different people responsible for two different types of reviews.

Laura Maher: I think it makes sense to me, and I think sometimes people with design reviews, the only requirement is that you have a design review with all the relevant parties. And so that could be your final review that is satisfying the requirement. Any reviews that happen in the middle, those are what's going to be most beneficial for your team and the process to make the project move smoothly, move forward. So I try not to. People get caught up in like, oh, I need to do, you know, three throughout the process at this stage and this stays and this stage. Or, you know, we got teams doing agile product development now. So that whole sage gate thing doesn't always work for those of us used to waterfall, we might be doing it at the sprint level of doing a design review. So I think it's, you know, don't get too caught up on what a review is called in the middle, you're doing what works best for the team and making sure the project's moving forward and things make sense. And then, you know, sure, you have your design final design review. That's satisfying the requirements.

essional, I'm thinking of ISO: 1345

Laura Maher: Yeah, well, I think, like, design review is, I think a lot of times we get too caught up even in, like, oh, I got to meet the requirements. But what, what's the, what's the intent behind the requirement and for design use? It's to make sure that we design the right device and we designed it correctly with stakeholders involved and somebody independent from that process involved. And so, yeah, I think especially kind of early in my project experience, you know, the team, we were all pretty fresh to design controls and, like, feeling, like, very rigid in the stricture of, like, oh, we've got to meet all the requirements, but, like, not really putting a whole lot of thought behind, like, why, why are we doing this in the first place or what, what is the goal that we're trying to get out of it? So.

Etienne Nichols: Yeah, no, that's good. That's, that's a good point. A lot of people, I mean, a lot of people who do design controls might be doing it for the first time because I think a lot of innovation happens in these smaller companies that might get bought up by larger companies later on, so.

Laura Maher: And, yeah, that's generally my experience, like being an onboard and implementation guru here at Greenlight. I meet with a lot of customers who are approaching this for the first time, and they're very new to all of it. The definitions, the process, design reviews, they're new to everything. And I think that more often than not, that's kind of be. Kind of what, what's happening with teams is that, you know, except for the very, very large corporations like Stryker or Medtronic that are, you know, well oiled machines.

Etienne Nichols: Well, yeah, I don't know. I almost, I almost have a flip. I almost have a flip side. Not a poke fun at anybody. But some of the experience I've had with some of the larger companies is that they're rigid in a different regard in that they're focused on, this is how it's always been done, this is how I learned it, whereas, well, is that actually required? You know, so, I mean, it's. They could both have their pros and cons not to. Yeah, no, I know what you mean, though.

Laura Maher: But I think it's like, you know, if you're fresh to it, I think that, you know, it can be really scary and be like, oh, God, I've got to get this right. But, like, I think it's bringing in the spirit of quality and innovation to the process. And if you know what the standards and regulations require, they're not constrictive. They're just telling you how to make sure that you're doing it right and that you go into the design process with that of like, I'm making a safe device and I'm making an effective device and it's got to be something that's feasible to manufacturers so that I can make sure that it can be delivered to people. But also from the perspective of, like, you know, I'm creating this documentation from the start so that my engineers, ten years down the road, understand my thought process today and that when regulators or standard bodies come to my organization, I can communicate this effectively to them. For startup companies, like, having that spirit, I think is just as important as knowing the definitions of everything and having that experience.

Etienne Nichols: The why behind, why are we doing this? Yeah. Not just arbitrary set of rules. Standard. It's interesting we use that word in industry so often that I think we forget how it is used outside industry. If you think, oh, this is the standard this is the baseline expectation that is pretty universal. That's, I mean, that's kind of, if you look at the definition of the word standard, I mean, I keep going back to definitions. Why? What am I doing? You just said, well, let's focus on the spirit, which I agree.

Laura Maher: Well, you have to know, to focus on the spirit, you have to know the definition. But we don't want to get too caught up in the definition or feel like it's constricting anything. Know the why and I have that quality mindset. Have that, you know, why are we here mindset. We're improving patient quality of life. And so I think when you're talking about bigger corporations, we get too caught up in our specific role and making sure that we're doing the process exactly how it's been done for the past ten years, 20 years, and kind of losing that spirit of quality and innovation as we go through.

Etienne Nichols: Well, I'll put a link in the show notes to my poll. It was, it was a couple weeks ago, maybe months by the time you've gotten this, but I would love to hear anybody's additional thoughts. If you want to go to the link at LinkedIn to let me know what you think. Who should own the design and development documentation for medical devices? Are you in that 17% that thinks it's someone other than product development or do you, do you disagree in any way? I'd love to hear what your thoughts are or if you have thoughts on this design assurance professional. I think it's going to be in a potentially emerging role in the future. The larger companies have already adopted it. So I'd be curious to see how.

Laura Maher: I think it's more started seeing that role like more recently, at least maybe in the last five to ten years of that being a role that's actually advertised versus just quality engineer. But you don't see it across all organizations. Part of that is probably size. It's kind of hard to justify just one person who's owning that. When you have a small team, it's going to be your, like you said, project manager is design assurance engineer.

Etienne Nichols: As there's some people who probably reach out and say, well, I've seen a design assurance role for the last 50 years, you know, so, yeah, maybe I've, maybe I've been living under a rock, but I'd love to, love to hear what anybody's thoughts are. Any last thoughts? Piece of advice for people owning whoever it is that owns their design controls, trace matrix design and development process, whatever it's called. Now with QMSrdem, I think seeking out.

Laura Maher: Training, talking to other people in industry, gives you that confidence and understanding of what needs to happen, what needs to be documented, how it needs to be documented. Participate in audits, when you get to see firsthand what your auditor is asking for and looking at, and the questions that get generated from that documentation really helps, too. Like, I started to think about, like, how can I keep someone from asking a question in the documentation, or how can I explain it in a way that we're not creating rabbit holes. Not that we should, you know, we shouldn't be scared of that, but we also kind of, the goal is to keep people from getting too deep into everything. So just, just try to get those different perspectives, see if you can participate in other parts of the product development process and have an open mind.

Etienne Nichols: And, yeah, it's maybe, maybe we'll kind of just throw a few things out there as we kind of close. But you got me thinking about what are the skills needed for this? If it was, if I'm going to go out and hire a design assurance professional, what are the skills needed to fulfill this role? If I just kind of repeat back to you what I've already heard you say, some of the project management skills, communication skills and ability organization, the technical writing, and the ability to actually document those things. But you also mentioned going out and seeing voice of the customer. So being able to take what, go to those meetings, take all of that information and compile that. Maybe that's more of that technical writing skill and the ability to do that. But then the last thing I would say is a knowledge of the standards and regulations, curiosity about why is this a rule? Is this a rule and why is this a rule? Anything to add?

Laura Maher: No, I think all of that is good. Maybe a little bit of engineering background. Like I said, I'm not an engineer, but I, you know, spending time with engineers, understanding what their challenges are in terms of, like, cost and supplier management and things like that. But, yeah, just, I think it's one of those things like bioengineers in and of themselves, which I'm not one, but it's kind of like a multidisciplinary subject of learning a little bit of everything so that we can be effective in these types of, like, design assurance type roles, but kind of having that spirit of learning and growing and flexibility. Yeah.

Etienne Nichols: Thank you so much, Laura. I really appreciate it. We'll put a link in the show notes if you want to find out how to get a hold of Laura. And thank you so much any, well, I already asked you last words. I'll ask you one last time. Any last things that you want to point people to or anything like that?

Laura Maher: I think we have an ultimate guide to bringing a medical device to market, and that document is really incredible because we're looking at bringing a device to market from a lot of different perspectives. And that I think Tom Rish is our guru author on that one. I think it's a really great place to go if you're new to design and development.

Etienne Nichols: Fantastic. I'll put a link to that in the show notes as well. All right. Thank you so much, Laura. Really appreciate you being on the show. We'll let you get back to it. Cass, thank you for listening, and we will see you all next time. Take care.

Etienne Nichols: Thank you so much for listening. If you enjoyed this episode, can I ask a special favor from you? Can you leave us a review on iTunes? I know most of us have never.

Etienne Nichols: Done that before, but if you're listening.

Etienne Nichols: On the phone, look at the iTunes app. Scroll down to the bottom where it says leave a review. It's actually really easy. Same thing with computer. Just look for that. Leave a review button.

Etienne Nichols: This helps us.

Etienne Nichols: This helps others find us, and it lets us know how we're doing. Also, I'd personally love to hear from you on LinkedIn. Reach out to me. I read and respond to every message because hearing your feedback is the only.

Etienne Nichols: Way I'm going to get better.

Etienne Nichols: Thanks again for listening and we'll see you next time.