In this episode of the Global Medical Device Podcast, host Etienne Nichols is joined by quality and regulatory expert Ashkon Rasooli to explore the essentials of creating a high-impact, non-burdensome Quality Management System (QMS).

Ashkon shares his four guiding principles for building an effective QMS—emphasizing quality over proceduralism, culture over mandate, redundancy over duplication, and conciseness over verbosity.

This conversation dives into strategies for optimizing QMS implementation, reducing overhead, and integrating quality culture company-wide. The episode wraps with tactical advice for new medical device founders on setting up their QMS for long-term success.

Key Timestamps:

• 00:02 – Intro to Greenlight Guru and Episode Topic
• 03:30 – Introducing Ashkon Rasooli and his background
• 05:15 – Defining the “Non-BS QMS” approach
• 06:45 – Principle #1: Quality Over Proceduralism
• 12:00 – Navigating deviations in QMS and avoiding extremes
• 14:45 – Principle #2: Culture Over Mandate
• 22:10 – Principle #3: Redundancy Over Duplication
• 29:30 – Principle #4: Conciseness Over Verbosity
• 37:00 – The Importance of Designing for Regulatory and Quality from the Start
• 46:30 – Tactical QMS advice for new medtech founders
• 57:00 – Wrapping Up and Key Takeaways

Standout Quotes:

1. "There is a cost to quality. But quality done right can also be an enormous value-add, not just a regulatory checkbox." – Ashkon Rasooli
2. "A QMS should serve quality and compliance, but it has to be intuitive for every person in your company. Complexity does not mean quality." – Ashkon Rasooli

3 Key Takeaways:

1. Quality Over Proceduralism: Focus on the intent and impact of QMS processes rather than rigid adherence to procedures that may not reflect the realities of your business.
2. Culture Over Mandate: Building a culture of quality involves engaging every employee, not just those in quality roles, to ensure shared responsibility and proactive efforts.
3. Design for Quality Early On: Engaging with quality and regulatory advisors at the architecture and design phase can prevent costly rework and optimize compliance pathways.

References:

• Ashkon Rasooli on LinkedIn
• Etienne Nichols’ LinkedIn
• Greenlight Guru’s QMS Software: www.greenlight.guru

MedTech 101:

QMS (Quality Management System) – A structured system of procedures and processes covering all aspects of design, development, manufacturing, and distribution to ensure product safety, effectiveness, and regulatory compliance. Essential for medtech companies seeking to market devices in most global markets.

Audience Engagement:

Poll Question: "Does your company treat quality as a compliance necessity or a business differentiator? Share your thoughts!"

Feedback:

Love this episode? Have ideas or topics you want us to cover? Email us at podcast@greenlight.guru and leave a review to help others discover the Global Medical Device Podcast.

Ashkon Rasooli: 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: Are you ready to take your medical device development to the next level? Greenlight GU is the leading QMS software built exclusively for the medtech industry. With Greenlight Guru, you'll stay compliant with global regulations while accelerating innovation and time to market. No more paper trails or complex spreadsheets, just a single source of truth to manage your entire product lifecycle. Join the growing list of medtech professionals who've made compliance easier and faster with Greenlight Guru. Learn more at www.greenlight.guru.

Etienne Nichols: Hey everyone, welcome back to the podcast. Today I want to talk about QMS as it's often seen as an obstacle, but the absolute best in class use it to their advantage. And I brought Ashkan Rasuli on. He's been on the podcast before. He gave an episode on AI. That was a really great episode. But maybe before we get into that. How are you doing, Ashkan?

Ashkon Rasooli: Doing good. How are you doing, Etienne?

Etienne Nichols: Good.

Etienne Nichols: So glad to have you with us today. Maybe I'll let you introduce the topic because this has kind of become your brand a little bit.

Ashkon Rasooli: Absolutely. I mean, today we're going to talk about the fundamentals QMS and specifically focus on how to optimally implement a qms. I have introduced the concept of a non BS QMS that play on the non burdensome principles by the FDA introduced, but at the end of the day speaks to the concept that a qms, despite having minimal overhead because there is a cost to quality, should be implemented in the least burdensome manner. And today we're going to talk about that.

Etienne Nichols: You had mentioned that you have principles that you follow and that you've broken this down into four principles. So maybe we can go through that. And at the very end, just so people know, what I would like to end with is a lightning round where say a founder says, hey, I just found out we're a medical device company and we have to have a qms. I don't even know what that those letters stand for. What do I start with? Do you? And we'll just kind of go through that a little bit in the more tactical sense. But let's start with these principles. Take it away.

Ashkon Rasooli: Absolutely. And these principles are kind of modeled after the principles of the Agile Manifesto. For those of you that have ever tried developing Agile software and studying the Agile methodology. You know, my background is very software and AI focused and therefore this was top of mind. It is also very much informed by my experience doing quality management work, doing non quality management work, but also leading quality management systems to certifications. And it is four principles. The first one has to do with quality over proceduralism. And what I mean by that is there is often a mistake made where a QMS is seen as a set of procedures embodied in documents that you have to stick to line by line without an understanding of what those procedures are meant to do, the intent behind the procedure. There always needs to be an understanding of what the point of for example document control procedure, cap on non conformance risk management. Every single one of these procedures ultimately has an intent and the intent is a component of big Q quality. And so the first principle is that when you're implementing a QMS you got to approach it that way. Yes, a QMS is compromised of a set of documents, procedures, work instructions, records, objective evidence of compliance basically to those procedures and work instructions. But all of that is with the intent to ensure quality. And so there may come a time where you realize the procedure requires deviating from. And if you're constantly deviating from your procedure, then you gotta update the procedure. That's not a good procedure.

Etienne Nichols: And I wanna talk about the deviation just briefly. Cause different points in my career, I've had different experiences where one VP of quality might dictate we are not having any deviat deviations. Whereas in others that you have no choice or you're not shipping product, but.

Etienne Nichols: Where'S the fine line and how do.

Etienne Nichols: People handle deviations before that change?

Ashkon Rasooli: No, that's a very good point. And I will say either extreme is not optimal because at the end of the day you gotta keep. The one thing that shouldn't change in your implementation of QMS is a focus on quality and the objective of the quality management system. Now, with the ever changing circumstances of your business, your team, your market, it is only inevitable. It's only a matter of time before a pre established procedure ends up needing, updating, needs, deviating from. So the VP that mandates the procedure and absolutely does not accept any deviations is most likely being too strict, either adding too much burden to the team or sometimes not even ensuring quality because the procedure isn't adapting to the realities of the business. On the other hand, procedures are there to ensure consistency in quality because consistency is a fundamental part of quality. And if you've got a VP that is constantly deviating, allowing deviations, if you got a team that for whatever reason is constantly deviating, what that tells me is this procedure doesn't fit the realities of that business. Therefore that procedure needs updating. Now Mark can argue there might be other scenarios for this, like the team just needs retraining. People don't have the right culture. But looking specifically within the scope of QMS design and architecture, that's what that tells me.

Etienne Nichols: Okay, so the first one was checklist mentality. What's the second principle?

Ashkon Rasooli: Yeah, quality over proceduralism is the first one. Second one is culture over mandate. You've probably heard this said over and over again. Quality is everyone's business. Quality is not just quality's business. When you look at the work done to ensure quality at any company, a very small part of it is done by the team titled quality. Most of the work is actually done by non quality people. And you know, title quality is what I'm talking about.

Etienne Nichols: Right? Right.

Ashkon Rasooli: The quality management system team has the big picture defining procedures, but for it to be effective there needs to be a culture. And when I talk about culture, what I mean that everyone at the company understands the goal of the quality management system, what quality means for their product, how it fits within the business, the business vision and the mission as a whole. But then more importantly, what role they play in that bigger picture. And with that understanding, you will have individuals autonomously having quality in mind and doing work with quality in mind. This is as opposed to a team that only does quality management system work because the quality regulatory team tells them they have to. They're going to do whatever satisfies that team's requirements. They're not going to go a bit beyond. But also even that little they do, they're going to do begrudgingly. They're going to be resentful about and it is only inevitable that the quality of that documentation is poor and it becomes a self fulfilling prophecy that the documentation is just an after the fact checklist with absolutely no value to quality. And we see that over and over again. So the difference between culture versus mandate is culture is everyone understands quality and proactively wants to do what they can do for quality versus mandating is there is a procedure that says I have to do this, it's a mandate. I'll give you an example. I've worked at companies where software engineers would refuse to code unless there was a approved version of software requirements. There was an understanding of what the point of software requirements were and that if they coded before software requirements were formally approved, that would be a waste of everyone's time. And then I've been at companies where software Engineers deployed, you know, bug fixes and quality has to catch them. Now when you look at those two scenarios, going back to the ultimate topic of this conversation about, you know, least burdensome, the second scenario is a lot more burdensome. Even though initially you think the software engineers are not having a documentation they're pushing and all that, at the end of it, we have to go back, catch that, roll back that release, put in the right documentation and plus all of that retrospectively, all of that duplicate effort. Big picture, the company lost a lot of resources to achieve the same outcome. And so again, another principle of the non bs QMS is culture over mandate. Because I believe implementing a culture of quality is a lot more efficient than mandating quality.

Etienne Nichols: Culture is an interesting one and it's slippery and it's hard to really grab hold of. But one of the definitions I've heard, I can't remember who first told me this, but people like us do things like this and that tells you what the culture is because everybody has a culture of some sort. And so the people like us do things like this kind of tells you what that is. How do you shift that culture or educate companies to embrace a culture of quality? Do you have any thoughts on how to even accomplish that?

Ashkon Rasooli: Absolutely. And I will say, even in building the culture, quality is everyone's business. So even in the culture building part of quality, it is a shared responsibility. I can speak to what a QMS team can do best in building the culture and that is to have, you know, I'm going to go through the other principles as well. But to have a QMS in the non bs fashion, in the sense that your procedures are easy to understand, they get to the point they have the right content in there and they do the right amount of training. Your trainings are actually effective. Very often you see training programs that are not effective. They're a simple read and acknowledge of a procedure that is full of, you know, vague words and fluff that people read and just check off and not remember any of it. And so that is the role of the quality management system teams. Then there is the role that top management, top executive management plays, which has to do with prioritizing quality when you're setting company wide initiatives. Because at the end of the day, every individual at the company is going to have a list of goals and initiatives and if there's no room allocated for doing quality work, it's just going to get deprioritized. And so you are not able to build it into the culture. And so again, executive Management has a very big responsibility in understanding quality, its requirements, its resource allocation. Once you put those two in place, I have found more often than not than not that people just want to do the right thing. And so when people are convinced of what quality is about and they have the right information and they have the resources, you will see cultures shape and you will see cultures. And the thing about cultures is they have inertia. Once you shape them, everyone new coming in will start adopting it, especially because it makes sense. If it doesn't make sense, people are going to obviously resist it. But when it makes sense that we do things this way because, and the because is more than someone said so.

Etienne Nichols: Right, right.

Ashkon Rasooli: Then people adopt it.

Etienne Nichols: What about the third one? And maybe I should stop asking you some side questions because I think you're going to answer it as we go along. But yeah, go ahead.

Ashkon Rasooli: No, no, these are great clarifying questions. So the third one is redundancy over duplication. With a lot of quality management systems I've seen there. This speaks more to the point of document management and QMS architecture. Often I've seen the same piece of information be captured in multiple templates and therefore multiple records that are built off of that template. The same piece of instruction be captured across multiple procedures, multiple work instructions. The problem with that is it is inevitable over time, as people get busy, as time goes by, that you're going to update one piece of one instance of that information and you're not going to have time to go align it across the board. I therefore very much favor and believe it is the non burdensome way to include by reference and not by explicit inclusion. Because what happens is it is only a matter of time before what you've got there is misalignment, or if you have a really good quality management system team that keeps track of the many places that needs to be updated, it is going to be an overhead. There is going to be an overhead associated with that. Now this is opposed to having redundancy. Sometimes you need redundancy and system design. Redundancy is a risk control measure. It could be a risk control measure in a process that you have. Redundancy could also be a design feature. Right. But this is not the same thing as having duplicate content in your documentation. Yeah, I'm stopping for any questions.

Etienne Nichols: Yeah, yeah, yeah. No, this is really good. And do you have any examples of redundancy in a positive sense? And I can just think from a, from a podcasting standpoint, you know, having two microphones so you, if one fails, you Catch the. Catch it with the other ones. Because the old military is saying two is one and one is none. But any suggestions or recommendations from a medical device standpoint?

Ashkon Rasooli: Absolutely. So, you know, cybersecurity is hot these days. And one of the things that you are required to have in your security operations is what we call a backup and disaster recovery procedure. Right. And so that's an example of redundancy. You may have everything in an electronic quality management system or other tools for that matter. You want to be able to, in case of a power outage, in case of a natural disaster, still be able to function and operate. And so you create for your core necessities of your operation a paper backup. Right. Is that duplicate content? Sure. But there is a reason for that. It is a risk mitigation. So that is not what I'm referring to when I say duplication. That is redundancy.

Etienne Nichols: Yeah, yeah. Okay. What's number four?

Ashkon Rasooli: Yeah, number four is conciseness over verbosity. And I've somewhat alluded to this already. At the end of the day, I believe words matter and words are powerful and they have values and they must be treated with respect. There should not be a single word in the QMS that does not serve a purpose. The QMS serves the purpose of ensuring equality and, you know, on a smaller margin, compliance to regulations. If a word in a QMS does not serve that, it should come out on the extreme end of violating this principle. You see a lot of procedures that have a lot of fluff that you could have removed and nothing of value would have changed. Nothing materially would have changed in the intent of the procedure. This type of procedure often ends up being like the least effective in terms of understanding because you read a lot of words without actually learning anything, without having any substance. And so if you want to have a, you know, non BS qms, what you gotta have is procedures that are straight to the point. You are gonna have, you know, non quality people reading these procedures and training to them. And they by design have less of a stake in what the procedure says. They just wanna know on their end what is the big picture and where do they fit, what do they need to know. And so to get straight to that and not say much more and much more fluff rounded, that makes it a lot easier to manage. It often goes hand in hand with what I said with the prior principle of not having duplication of content. So these two kind of relate to each other. You will have less duplication, you will have much bigger bang for the buck of A procedure.

Etienne Nichols: I love that one. When I edit things, I edit for a certain. Well, I write for a certain way. First I write for myself because I want to write something. You know, I'm writing something and then I write for, well, who's actually going to read it. So I edit it for that person. And then the third person I edit for is who hates me or who really dislikes whatever it is that I have to say or typically disagrees. And I try to meet that person and so. Okay, Etienne, how is this applicable here when you're writing for an sop? I can't help it. I'm getting a little excited about this point. A lot of times what I think SOPs are written for is for the inspection for when the FDA shows up. That's what we write them for because we want to cover ourselves in so many ways. And in, in a way that's good. But I think they should first be written to meet the company's needs and then edit it for the actual person who's going to be reading it so that he understands it. And then you edit it for the inspection. What do you think though?

Ashkon Rasooli: 100%. I think I actually think of QMS the way I think of products that the QMS manages. Right. And with products we talk about defining the user groups and the use cases. Right? And with the QMS too, we got to define the audience, the user group and the use cases. And the. There are the top level 3 user groups for a QMS. The first one is the auditor. This could be the internal auditor. This could be an external person looking at it if you have a client that is doing a supplier audit, or it could be a regulator like the fda. Right? That's the third group. They do not belong to your organization. As someone who's seen this for the first time, they just want to ensure that you are complying with regulations, you are ensuring quality as appropriate. The second group is non quality management system people. Their use case of this procedure is understanding again, big picture and small picture. Big picture. How does this process ensure quality? What piece of quality does this ensure? Small picture. What role do I play in that? What are the requirements from me? The third user group is the quality management system group that has to maintain it right? At the end of the day, they are tasked with maintaining what is a very complicated system and it grows in complexity exponentially as a company grows. You want to optimally meet the needs of those three user needs. Three user groups. Now this does speak to optimal QMS structure as well, because there are times where you're going to decide the language that satisfies an auditor is not going to be the language that is appropriate for an internal user. And so you create two different documents that talk to each other. And this has to be a case by case thing. You want to have structures in your QMS and you're going to have the auditor friendly sets of documents which then point to, let's say, process implementation of work instruction that is more non regulatory person friendly. Right. So what I just said also speaks to how you optimally design your qms. But you got to keep those three user groups in mind. And one of the primary culprits of having, you know, burden in the QMS is the fact that we try to fit all three into the same sentence. We forget one user group, we just don't address the needs of all three.

Etienne Nichols: Okay. Concise versus verbosity. Redundancy over duplication.

Etienne Nichols: Culture versus mandate.

Etienne Nichols: Remind me the first one. I don't think I wrote it down correctly.

Ashkon Rasooli: Quality versus proceduralism.

Etienne Nichols: Quality versus proceduralism.

Etienne Nichols: Proceduralism.

Etienne Nichols: That's a word I can't pronounce.

Ashkon Rasooli: Takes practice.

Etienne Nichols: Okay, that's really good. I really like those four principles. So let's kind of skip to our lightning round where I have this imaginary scenario where someone calls you up on the phone, says ashcon, I just found out I'm a medical device company. I thought we were just going to be doing some kind of nasal cleanse thing and we're going to be over the counter, whatever, I don't know. But it's. It turns out we're a medical device and we, maybe we're class two, we'll just use it as for. For putting up our boundaries. What is this qms? And how do I start? Do you just come up with this big stack of all right, here's 40 SOPs, let's get cracking. Or what's step one? Yeah, so that is what not to.

Etienne Nichols: Yeah.

Ashkon Rasooli: So geography, business and product information, those become inputs into identifying the regulations. That's compliance. But the second question every business has to ask themselves because the first set everybody asks themselves anyways because they have to.

Etienne Nichols: Yeah.

Ashkon Rasooli: The second question everyone has to ask themselves is what role does quality play? What does quality look like for my product? And there's a spectrum and you got to define where on the spectrum you are on the low end of the spectrum. I'm going to have the absolute minimum quality necessary for me to get to market. Quality is just a means to an end for me. I'm just trying to clear the regulatory hurdle on the far end of that spectrum is quality is actually part of my business plan. It is what differentiates me in the marketplace. I want to be known for quality because at that point quality becomes part of your product requirements. Where you decide as a company you would land on that spectrum also is a very important factor in designing your quality management system. You know, we've got even non medical device examples of this where companies try to differentiate themselves by quality and obviously they charge a premium for it. They kind of fit into a niche, high value, therefore high price corner of the market. You know, we've got companies like Toyota that are known for their reliability in the car. You know, when you think of quality, those are the names that kind of come to mind. Quality could be in service. You know, when you ask about companies like, you know, Costco and Nordstrom, everybody thinks of good customer service. Right. Quality customer service. Right. That's kind of what differentiates them. And people, you know, pay the premiums for those. So this applies to the medical device. Similarly, do you want to be differentiated by quality or is quality just a means to an end? But after you identify your quality requirements at the executive level and then you identify your compliance requirements, that's when we get into designing your QMS optimally. And that's when that non BS manifesto comes in.

Etienne Nichols: Yeah.

Ashkon Rasooli: You apply those principles and design your qms.

Etienne Nichols: How does Greenlight Guru line up in your mind for that, if you don't mind me asking?

Ashkon Rasooli: No, for sure. So I see Greenlight Guru or any EQMs or any tool for that matter, because you know, I mentioned my background in software and there's a lot of non EQMS tools involved in software development. There's like bug tracking, there's deployment management, there's customer complaint tracking. So there's often a suite of software products that underlie basically the quality management system. You basically pull in information these products, when used appropriately and why using appropriately? I mean configure it appropriately for the process you've decided you need based on, you know, your QMS design, they save a ton of time and a ton of confusion. They enable further possibilities for your business as well. I have worked with paper based QMS systems. Good luck with remote work on that. Right. I have worked in environments where when we wanted to do a product validation, the set of protocols were pushed around on a cart. There were, you know, easily thousands of pages of a test protocol which then needed to be approved. And so we would push the cart around to different approvers. And you can imagine how effective that was and how efficient that was. So in terms of introducing efficiency, the tool enables having a non bs QMS by operationally streamlining it.

Etienne Nichols: Yeah, it doesn't automatically get you there. I get that. It's one of those things, I think, where we shape our tools and that our tools shape us.

Ashkon Rasooli: Yeah.

Etienne Nichols: So you want to shape it correctly. Absolutely.

Ashkon Rasooli: 100%. Yeah. You know, one of the. I've been involved in countless process optimization projects and different environments and one of the biggest pitfalls is to define the project as pick a tool.

Etienne Nichols: Yeah.

Ashkon Rasooli: It is often pick a tool and design a process that goes with the tool and define everything that goes around it in terms of user instructions, rollout, transition and what maintenance is going to look like. You need to have all of that in scope of your project and then you're going to make the right decisions.

Etienne Nichols: Very cool. Any other piece of advice you have for this theoretical founder who's interested in setting up his qms?

Ashkon Rasooli: I talked about, you know, early engagement, defining where quality fits within your general business model. I talked little about adequately resourcing it. After you've done that.

Etienne Nichols: I actually, I meant to go back and emphasize something because that spectrum of where you fall on the quality spectrum I think is actually really powerful. Because if you're a medical device, okay, there's a certain bar you have to reach. And if you want to make quality your differentiator, I think it's. You know, in the past I've heard people say, well, you should all every company should do that. Well, no industry does. Every company make themselves the absolute best as far as quality goes. It's just not even possible. There is a Hierarchy. And I think that's a more realistic approach to looking at that because you're right. There's always in every industry, it's typically one company that sets quality apart as their differentiator. And I've never heard anyone else kind of highlight that. So I thought that was really interesting.

Ashkon Rasooli: That you pointed that out 100%. And like, we gotta acknowledge as quality professionals that there is a cost to quality. This is why quality products cost more than non quality products, medical device or otherwise. There is a cost to quality. The question is, you know, how much is quality worth to you, to your, to your consumers? It is often also underestimated the value that quality brings because it is only highlighted when something goes wrong. It is really. I have yet to see a nice effective characterization of the cost of poor quality. Right. Lack of quality. There is a huge cost to that. It is hard to quantify that. Let's say for your finance team, prospectively, when it happens, all plans get derailed. You gotta put teams on fighting fires. You gotta go back and redo work which would have initially been done correctly at a fraction of the time and effort. Right there was, you know, the analysis. I'm gonna give you a software example for software defects. Most of them can be traced back to the requirements not being defined at the very beginning of the product development phase. Not defined accurately, correctly or comprehensively. This would have been a lot easier to catch. The cost of these software bugs to fix exponentially go up the later you fix them. Right. Same thing happens with non software products. And so one of the problems we have in determining the value of quality and balancing that against the cost of quality is that we cannot prospectively estimate. But that does exist. That is the reality that we got to keep in mind. And then with that in mind, identify where we want our quality bar.

Etienne Nichols: Yeah. Okay. Any other piece of advice for this founder, this theoretical founder who is realizes that he has to set up this QMS and really is trying to figure out where to begin.

Etienne Nichols: I really like the design for regulatory. My mind was just kind of spinning on that a little bit. When you talked about from a software perspective, it's a good lesson. I think I would expect physical product manufacturers probably think about it to a certain degree, but to isolate any potential changes to one section of your design so that your potential design verification or future verifications, if you have any kind of risk issues can be isolated to the to that section or any high risk areas that's really? That's really powerful.

Ashkon Rasooli: Another, you know, impact of risk is, you know, if you do early risk assessment, even at the high level, and you don't do a full detailed fmea, for example, just do a high level risk assessment right there and then you can identify, you know, we are going to need risk controls at the gross high level, you know, level in these areas. And therefore what you think is going to take you six months is actually going to take you three months because you also have to build X, Y and Z. Right. And so it just helps you have greater, more accurate estimates.

Etienne Nichols: Yeah, very cool. Well, any other, in your, in your brand that you're building, any other pieces of advice, any last pieces, words of wisdom before we close it out?

Etienne Nichols: Yeah, really cool. Thank you so much, Ashkan. I appreciate it. I always enjoy getting to talk to you and look forward to the next time. Those of you been listening, but listen to the global medical advice podcast, we'll let you get back to it, but until 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 done that before, but if you're listening 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. 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.