Brendan: Hi, everybody. Welcome to PodRocket. I'm Brendan. I'm on the engineering team here at LogRocket and joining us as our guest is Dave Hauenstein. Hey, Dave. Dave Hauenstein: Hey, what's up? Brendan: Dave is the vice president of engineering at Particle Health, New York and previously he was at Better Mortgage where he scaled the engineering team from five to 120. And before that, Dave, you and I worked together for many, many years. So really excited to have you on the podcast and talk about some of the different things around building APIs, scaling engineering organizations. A lot of the stuff that I think we've talked about a lot and realize would be great to sort of bring to the LogRocket Podcast. Dave Hauenstein: Yeah. Awesome. I'm glad to be here and those are all things that I love talking about. Brendan: Awesome. So before we dive in, do you want to give a quick overview of what you're doing at Particle Health? I know you started there in January. So tell us a little bit about the company, about your role and sort of where you guys are going. Dave Hauenstein: Yeah. For sure. So, like you mentioned, I'm VP of engineering at Particle. I think this is my seventh week now so I'm still relatively new there. Particle health is a very, very cool company. The way that I think we describe it pretty often is we're the Plaid for healthcare basically. So in the same way that Plaid provides a developer friendly contract on top of fragmented financial data, Particle Health does the same for patient medical records. Dave Hauenstein: So there's this really complex and fragmented network where patient records come from and there's all this legislation that's changing year over year that makes this data more available. So someone has to act as the orchestrator on top of that. And that's what Particle Health does. We have a simple API on top of these complex networks and we're able to connect over 300 million patient records. And our customers make requests to our API, we return that data in a format called fire R4, which is a relatively new and modern JSON format for describing patient medical records. Dave Hauenstein: You give us basic demographic data, name, date of birth, address, et cetera, we do the look up. And the founders have an incredible clarity of vision and strength in their conviction for how to solve these problems. And it's just such a cool and fun opportunity. I feel very privileged. The folks on the team are wonderful and brilliant and it's just an awesome opportunity for me. Brendan: Awesome. And I think it might be a little bit fun to talk about kind of how you came to running engineering organizations and a little bit about your sort of career story in general. I think in the early 2000s you started out in a punk band and now you're a VP of engineering. So that's quite a track. Dave Hauenstein: Yeah. It's kind of funny. It feels like no part of my story was deliberate at all. I kind of just ended up here through a series of random decisions seemingly. I was in high school, I was in a band and my band needed a website and I had a friend who took a web design class and so I asked them to help me and it kind of spiraled from there. I started doing websites for my friend's bands and all through college I wrote code. I don't have a formal background or education in software engineering. Back in the early 2000s there was no bootcamps or none that I was aware of. Dave Hauenstein: And I thought coding was fun. I didn't think to go to school for it and kind of turned it into a career. So I don't know, eight or nine years professionally writing code and kind of accidentally got into the management track. I remember I was talking to a manager colleague of mine at a company early on in my career and we partnered together pretty often. Dave Hauenstein: And he asked, when was I going to take the jump? When was I going to become a manager? And I remember thinking that's not for me. The problems that I want to solve and the way that I want to solve them are all with code. But that's changed over time obviously. Brendan: Yeah. I think it's funny to hear you say that it feels kind of chaotic and a little bit random where you end up in your career. I feel like when we listen to career advice podcasts and blogs, it's all so structured where you think about your career track and you think about career ladders and it's all laid out in front of you and that's important. Brendan: And I think for some people that's definitely a reality, but there's also just a level of kind of depending on where you are and depending what opportunities happen to show up at the company that you're part of as it grows or changes over time that has so much influence on where your career goes. Dave Hauenstein: Yeah. I think that's true. And the advice I give to folks that ask about going from IC to management is think about what you want to do long term that earlier you get into management, the longer you're going to spend moving away from coding and writing code on a day-to-day basis. So I think it's important to think about managing your career long term in that regard. I mean, for me I just didn't really start thinking about career management until I got into management actually. And it did feel a bit random until I started, I guess, putting a plan together. Brendan: Yeah. Is that something you feel like anyone who wants to get into management has to do or is it the kind of thing where you can try management see if it's for you? I definitely think there's been a lot of talk about there being a sort of porous boundary between management roles and technical roles in the industry. Dave Hauenstein: Yeah. I think a lot of about this. So corporate culture I think has led folks to seeing management as a promotion where you get paid more as a manager and you have influence by way of authority and things like that. I think that's all bad. I don't think that those are good incentives for people to go into management. I think good reasons to go into management are that you care about the people that you're working with and you want to think about their career trajectory and kind of help them move to the next step, move to the next level in whatever career trajectory that is. Dave Hauenstein: Maybe as a manager, you also care about the operational stuff. So you value planning and kind of turning that plan into it something that you can execute and deliver on. And you don't mind doing stakeholder management and partnering with stakeholders. So I think those are better reasons to go into management. Management is a deeply privileged position to be in once you get there. You do performance reviews. And when you're doing performance reviews, you give someone feedback. Dave Hauenstein: Sometimes that feedback is positive and that's exciting, but sometimes it's constructive and critical and that can be hard. You make recommendations on raises and bonuses. This privilege does wield influence. And I think managers have to act very conscientiously and be incredibly well intentioned. So management is a shift in career in my opinion. Code is no longer the primary tool for solving the problems that you're solving. The problems that you solve as a manager require a different toolkit. Dave Hauenstein: I break management into three different categories. It's people, projects, and technology systems. So as a manager I think you have to be uncompromisingly people first at all times. When it comes to the projects, the buck stops with you. You're accountable for the work of your team. And you're probably thinking less about line level code and more about technology systems. Dave Hauenstein: Everything from maybe the services your team owns to how does the software get built and released and into production. And then how do you run it. Your team is probably on call for that software. So you're thinking much more I think about systems topologies than you are about line level code in a lot of ways. Brendan: So something I've always said to people is that if you think that getting into management is going to give you more of a feeling of control, you are just sorely mistaken. Going into a management role means giving up so much of the control that you feel as an engineer because ultimately exactly what you said, Dave, that you are accountable for the work that other people are doing and your job is to empower them to do that work and be successful and deliver a really high quality software product. Brendan: But the things that you can control to make that happen are limited. You can't do the work of six people on your team to make the software good. You have to lead through people and you have to sort of recognize that. You cannot manage every piece of it that you need to sort of manage the team at a high level and trust them to do the work, which I think is definitely hard for people who see management as an opportunity, not just a real influence, but to sort of have a really strong influence on the direction of the work that's getting done on the team. Dave Hauenstein: Yeah. And I think what I said as a corporate culture has led folks to seeing management as a promotion. And I think a tactical way to talk about this is how can companies make that not the case, make management not necessarily be a promotion? Be a lateral move for an engineer. So something that I learned while at Better especially as we were growing the organization so quickly is what does a really good career ladder look like for folks? Dave Hauenstein: And we created a leveling system where individual contributor software engineers can be promoted all the way up to reporting into the CTO while still being an individual contributor position without having to kind of branch off and go through that management track. So you have engineering managers and staff engineers kind of at the same level as peers with one another. They get paid the same. They have the same amount of influence over the surface area that they're working on. Dave Hauenstein: And I think that's incredibly important because not everybody doesn't career ambitious wants to go into management. They want to keep coding. They want to solve the hardest business problems that we have with code as their primary tool. And that's a good interview question for somebody who's a candidate talking to companies to ask them about. Dave Hauenstein: I think if you're going through the interview processing, you have an offer on the table, ask about the management culture. If you don't want to go into management, make sure that the company is aligning the incentives to stay in that IC career path for as long as folks want to be. Brendan: Yeah. And this is definitely not a new concept. If you think all the way back to mythical end month in the ‘70s, Fred Brooks was writing about this exact thing of making sure that sort of managers and software architects were treated as equals by their organizations. But it also it still feels something like that we get wrong a lot. Brendan: That it's more the exception than the rule when an organization really does a good job of aligning the career track so that people can stay in an IC role and be successful in the long-term and have a lot of career growth opportunities without management if that's not for them. Why do you think that is? Why do you think that's so hard to get right? Dave Hauenstein: Oh, man. I don't know. I mean, I think it's because a lot of this stuff is really soft. There is no definitive playbook for how to do this. Over the last 20 years, I mean, so many new processes and frameworks have come out for how to think about managing and leading and structuring organizations. Spotify had a really popular one at some point in the, I don't know, late or early 2010s or whenever it was where they talked about guilds and they had this whole matrix management thing. Dave Hauenstein: So I don't know. At the end of the day I think that people get it wrong because there's no definitive playbook and sometimes people just want to make it up as they go. But I think I'm seeing more companies think this way in terms of creating an individual contributor software engineer career ladder that is kind of running in parallel to the management career track, which I think is just such a good thing. Brendan: Yeah. And I think a couple weeks ago we talked to Derek Stolee, who's a principal engineer at GitHub and we were talking to him about that sort of very senior level and the IC track and about Will Larson's staff engineer book that he published last year. And one of the things that seems true to me from those conversation and reading that book is that engineering management roles tend to be fairly similar at different organizations like managing software engineers, managing a roadmap. Brendan: There's a lot of consistency in what that means especially on the product side between organizations doing different things, but these very senior IC roles, staff engineers, principal engineers, tend to be very, very specific to the organization they're a part of. Maybe they're devoted to solving an incredibly hard technical problem at the crux of that business. Brendan: Maybe they're sort of scaling the company systems in a way that's different than anyone else in the industry. And so I think it's almost like there's just so much more variability in what that role can look like. That as a company, like you said, you can't graft a career ladder from another organization into yours. You have to figure out what do really senior engineers in the organization do to create leverage? Dave Hauenstein: Yeah. I think that's right. I mean, when I joined Particle one of the first things I started working on was a career ladder for the organization. And I think the worst thing that I could have done is start from scratch and write it myself in kind of a vacuum. So I partnered with a couple of the engineers on the team and we worked closely together on defining what that looks like. And I think there's a couple reasons for doing it that way. One, you're right. Dave Hauenstein: There is a lot of variability in what folks and how roles are defined in organization, what the culture of a particular organization is and what the right framework for leadership project management, software releasing. I think there's a lot of variability there. So the career ladder was shaped so much by input from the folks on the team, but also it's important to do it that way too because it's the foundation for I think scaling and growing the company. Dave Hauenstein: Your interview process is probably evaluating for the competencies you think are most important. And those competencies that you think are important are probably articulated in your career ladder. Your review process is also probably kind of articulated in the context of the career ladder. People are evaluated based on where they're at in the career ladder. Dave Hauenstein: So you want to be able to capture company's culture, the values and the ideals of the people that have been at the company in that career ladder as something foundational to scaling an organization, or growing an organization, or evolving an organization. I think that's one of the key ways to kind of take the vision that the organization has and codify it long-term. Brendan: Yeah. And I think one of probably those really important alignment points where especially as a company is growing, as a startup you're constantly scaling and thinking about scaling and thinking about how you're going to solve the problems caused by scaling, codifying those values and reflecting those values of the team as it exists now in those types of documents and career ladders feels like an important way that you sort of build trust that everyone is aligned with what we value as we're growing. Dave Hauenstein: Yeah. I think that's right. Brendan: So that seems like a perfect segue to talk about some of the work you've done and experience you have scaling organizations and some of what you've learned from that. I think at the top I said you started on a team of five engineers at Better and by the time you left it was 120. Oh, my God. That's 25 times as many engineers in two and a half years. Can you sort of maybe start from a really sort of basic place? Why does anyone ever even need to scale an engineering team that fast? Dave Hauenstein: Oh, man, that's a juicy question. I mean, what does an organization get out of having a much larger software engineering team? I mean, Better went from, I think when I joined it was about 25 to 30 software engineers. I maintained that I was hired before they hit 30. But I don't have a perfect recall for it. And I think by the time I left the engineering team was I don't know, 375, 400, something like that. So the engineering team grew so much. So I think what ends up happening when you have a much larger team is that you can just parallelize more work. Dave Hauenstein: You can just get more things done at one time for an organization and you can also specialize. When you have 25 engineers, you probably don't have a five to 10 person infrastructure team or a five to 10 person data team. When you have 350 engineers you have a 30 to 50 person data or infrastructure team in some instances. So you can just further specialize so much. Opportunity cost early on in a startup is potentially existential. Dave Hauenstein: So I think what you're doing is you're building a feature to the MVP. And then you're moving on to the next thing. You're focusing on breadth of the surface area for the overarching product MVP. Once you've reached product market fit, opportunity cost is no longer existential. I don't think. So you can focus on your core competencies and continuing to evolve them, but you can take bigger bets. Dave Hauenstein: If you think about your staffing across the org as kind of a portfolio in the same way that you think about your financial investment strategy as a portfolio, you're probably investing in some more risky things that might not pan out. But you're also probably spending a significant amount of time on your core competencies. So I think just having a larger engineering team allows you to do more specialized further and reduce opportunity costs while being able to take on bigger bets at the same time. Brendan: Maybe to play devil's advocate here though. I think there's also if you think about an efficiency curve of how engineering teams grow, it's easy to imagine you add 100 engineers to your company and there's just so much inefficiency that's created and people are tripping over each other and your processes can't keep up that the engineers you're hiring aren't actually adding any more value even if they're sort of all writing code. How do you think about creating processes or teams within the organization to make sure that you're actually getting the value out of the next 100 engineers when you're hiring that quickly? Dave Hauenstein: Yeah. I mean, and I'm going to be honest. I'm not an advocate of going from 25 to 400 in in a two year period or something like that. I think it's super hard and you end up... There is a lot of things you trip over. I don't know. I read a tweet or a blog post recently where someone was like, I'm less impressed about the size of the team and more are impressed by what you can do with a smaller team. And when you and I worked together I think that's what we focused on so much. Dave Hauenstein: Engineering team size was a constraint and we had way more to do than the people we had to do the work. But I think that constraint allowed us to be so effective as a small team. And that is to me such an interesting problem to be solving. So I don't know. I mean, you're right, the first six months of growing really quickly, but what I noticed is there's a couple things that's happening to every different person within the org. So from a software engineering perspective. Dave Hauenstein: So the folks that were there when the org was small, they had a huge amount of autonomy. I think at that point individuals were the unit of concurrency for value delivery. So when you want a new feature, you go ask one person, they do the stakeholder management, they do the requirements gathering, and then they go and they build it. Then they move on to the next thing. When you're a lot larger, teams become that unit of concurrency. So you give the problem to the team and the team then goes and attacks it and solves it. But that's a big cultural shift for the human beings on the team. Dave Hauenstein: So I think if you have been at the company from five to 30, you see it operating one way and it just changes so much and I think it could be hard. There's a lot more process. It could feel like you might be losing some autonomy in a lot of ways and I think that's really hard. And I think what good leaders will do is just have a tremendous amount of empathy for those folks and figure out how to make it work for them. And I think that's so important. The new folks that are joining the organization I think can see it as a bit chaotic. Dave Hauenstein: There are just as many new people in the first three to six months as there are people that have been at the company for a long time. So you're putting a tremendous amount of stress and pressure on the people who've been at the company who have institutional knowledge, who are training up the new folks. So I think as a new person in org like this, it could be pretty hard and challenging as well to kind of know where you fit in and how you fit in until things settle down a bit. Your whole team might be a brand new team in some instances. Dave Hauenstein: So, again, this is another area where I think leaders just have to have a people first mentality, to have to have empathy for the human beings that are in the organization. The third category of people I will mention is just the stakeholders, the business side. They're used to working with engineers one on one. They're used to looking at the feature that was built and playing with that feature. But now stakeholders have to move to a mode where they're looking at metrics. Dave Hauenstein: Their contract is no longer the look and feel of the feature. It's the metric. Did this feature or did this class of features move the needle for the business? Did it create operational efficiency where we expected it to? Did it increase conversion at the aspect of the funnel or the area of the funnel that we care about? And I think as a stakeholder that comes with coaching. Engineering leaders, engineers should be coaching stakeholders because I think there could be a lot of friction there. Brendan: Yeah. What do you mean by coaching stakeholders? What does that look like? Dave Hauenstein: I think a lot of it is education. Why is this changing? Why can't I look at the features? Well, you can't look at the features because there's so many new ones that are popping up with such a larger organization at this point. And I think that can be a challenge for folks that are going through the process of seeing the engineering team grow so much and operating in a different model. So I think just having empathy for those folks, just talking them through why this is changing. Dave Hauenstein: I spent a huge amount of my time at Better talking to our head of operations, our head of sales, folks like that to talk to them about why these changes are happening and what they can expect. And I think it went a long way in terms of relationship and trust building. And it gave the engineering team the space that they need to get done what they had to do in the way that they need to do it. And I think that was really important. Brendan: Yeah. That resonates with me a lot. I think LogRocket our engineering team is kind of right in that growth phase of transitioning from the paradigm where people get things done to teams get things done. And we're having to basically rethink all of our processes and all of our ways of communicating with different parts of the org just because we're so used to working one way and we're trying to sort of shift pretty quickly everything at the same time about how our engineering team works. Brendan: And it's really fun and exciting and it's also definitely a challenge to sort of see all of those pieces moving at the same time. One of the other things I think goes hand in hand with growing an organization is hiring. I think anyone who is sort of responsible for hiring engineers or anyone who is job hunting right now knows that the market is very competitive. Everyone wants to hire engineers. There's a lot of VC money out there. How do you think about hiring for scale, but still keeping your standards high and keeping the engineers that you're bringing into the organization strong? Dave Hauenstein: I think just some philosophical things really quickly. I mean, I think the interview process as the first evaluation that a person on the engineering team will have. And the interview process is one, the review process is kind of the next one. And both of these things should be rooted in the same foundation, as I mentioned earlier. So the career ladder and the competencies that you define there. So you should be evaluating people for what you will also be reviewing them for at some point. Dave Hauenstein: So build out an engineering interview process that tests for those competencies and does so consistently across the board. The questions are exactly the same. Engineers are trained on those questions. They're exactly the same from candidate to candidate, nothing ever kind of changes, unless obviously it's a different role, but if it's the same role nothing changes. So I think that's really, really important, have our engineering career ladder, have a rubric and then have questions that evaluate for that rubric. Dave Hauenstein: Those questions should be technical, of course, and they should. I'm a big believer in behavioral interview questions as well where you ask people to talk about their story over questions where it's kind of situational. But kind of I feel like I'm diverging a little bit here. So I guess that's the foundation I think. So when you're hiring at scale versus when you're kind of hiring much more slowly, I think you have a choice between kind of specificity and a general skillset. Specific skillset and on a general skillset. Dave Hauenstein: So if what you want is the person that if you hire to kind of ramp up really quickly, then hire for that specific skillset that you want. Hire engineers that no GCP, go lang, and have worked in healthcare before. But if you're hiring a lot of folks at once you probably can't do that. The pool just is too small. You want to increase the pool size. So rather than hire for specific skillset, hire for a general skill. Your lead time, the time it takes you to go from interviewing candidates to hiring candidates will be shorter in this case. Dave Hauenstein: However, it might take longer for those folks to ramp internally. So you have to have good training programs. And I think just be uncompromising in your interview process. Keeping the bar high is about making sure that the rubrics and the interview questions are testing for those things and doing a good job testing for those things. And then don't change them. Let the pressure of hitting growth targets compromise the integrity of the interview process. That's super important I think. Brendan: Yeah. And I really like your framing of viewing both the interview process and the questions you ask and how you evaluate candidates and the career ladder as kind of both things that directly descend from your organization's values and the engineering team's values. And they're kind of just different ways of expressing that same thing. Dave Hauenstein: Yeah. I mean, in a most ideal situation, you have your company values, you know what they are, you build your career ladder on top of those company values and view those values into your career ladder. And then you build your evaluation processes on top of that. So your interview process and your performance review process. I think that's something we did pretty well at Better and I think that worked really well. Brendan: Another thing I think that you hear a lot as teams are scaling and changing is an anxiety from people about the culture changing or losing the culture that makes our team really good. It makes our team great to be a part of. How do you think about the ways that culture changes when you grow a team quickly and does that even matter or is that just kind of the wrong framing? Dave Hauenstein: This is the number one question I got from candidates that I interviewed at Better. I interviewed over 600 people while I was there. And this question was the one that came up so often. And I think it's a complicated answer. It's really hard to answer. I think the probably shortest way to answer this when somebody asks is how do you maintain the culture that you've built is you just don't. So many things change over the course of growing an organization really quickly. Dave Hauenstein: The processes have to change. What you do at 25 people is very different for what you do at 200 people, from planning to delivery. You hire new leaders into the organization and those leaders come from different places and they have different ways of doing things. So there's just some things that are going to change no matter what. But I think that there are things that you don't want to change. There are really, really important values that you have that you don't want to compromise on. Dave Hauenstein: And I think some of those things will change for the better as you bring on new folks with different backgrounds and different experiences. And some of those things just require a different mechanism for holding the organization accountable for maintaining those cultural values. So here's, I don't know, this is like a contrived example, but you value short iteration cycles as an engineering and product team. So if you do that so what does that mean? Dave Hauenstein: It means you're releasing to production or early and often. Your PRs are probably smaller. There are fewer lines of code. You can release a feature in the morning, see how it performed by measuring it and then release an iteration of that feature by the afternoon to change something. So when you're really small, you're a five person or 10 person engineering team, you can elbow the engineer next to you and say, hey, that PR didn't have any tests. Dave Hauenstein: So add tests, fix it. But when you're a 200 person organization, convention is no longer the way that you can enforce these kinds of things. So if you value a culture of iterative development cycles and tight feedback loops, then you probably need a programmatic way of enforcing that. You can't rely on convention. So you ensure that teams maintain a high degree of test coverage, for example, by measuring that and then by holding managers accountable or tech leads accountable for ensuring that their team is keeping that test coverage up to speed. Dave Hauenstein: So I don't know, kind of long roundabout way of saying that there are things that you value that you don't want to change and you've just got to change the enforcement mechanism. You could change the enforcement mechanism through codifying them and programmatically enforcing them and you can put them in the career ladder and hold people accountable in reviews for doing that. And then there are things that are just going to change and that's okay. And I think you should embrace that change especially if it's really good change as your scaling graph. Brendan: One last thing I thought it would be really interesting to talk about. I mean, our perspective is obviously as managers, but I think a lot of people who might be interviewing to join a startup that's growing quickly or join a scaling company would kind of want to know what should I look for in a company if I want to have this experience and join a fast scaling engineering team, what should I look for? What should be red flags? What should I ask in an interview? Dave Hauenstein: So first and foremost, I think being at a hyper scaling company, a company that's growing fast, was a massive and wonderful education for me. I learned so much going through that process. So I think it's an incredible opportunity if folks have the opportunity to do that. There's a ton of VC money right now and a lot of companies are using it to hire engineers and grow them. So there's probably a bunch of people listening to this that have this opportunity. Dave Hauenstein: I think make sure you go into it with the expectations that things will be a bit chaotic and ask questions that help you understand what that chaos looks like. Are the principled constraints that an organization has the right ones? So what do they value? Do they value tight feedback loops, and tight iteration cycles, and close feedback loops? Do they value having IC career ladder that goes up to the CTO on top of a management career ladder? I think the same things you'd ask at any company I think that those things are all really foundational and really important. Dave Hauenstein: But I mean, ask the interviewer what is the messiest part of growing really quickly? I think I was very, very candid and very honest with candidates that asked me those questions. And, I mean, you might have three managers in a year or in 18 months or something. So ask about how the company thinks about the org design and the org design how it's changing and shifting and how that might impact you. Dave Hauenstein: Will you have multiple managers? Is it okay? Do you feel okay about that? Will the team that you get assigned to change very quickly? I think all those things are totally feasible. They can and probably will happen so be prepared. Brendan: Yeah. And I guess the flip side of that question, you're one of the first five, 10 engineers. You've been in the basement. You've done the work to get that initial product market fit and now the team is about to start scaling quickly. What should you know to continue to be successful when the organization is twice that size or four times that size? Dave Hauenstein: If you're going to join an engineering organization as the first five people, or as the first six people on the team, I think you care a huge amount of making a big impact and you care about autonomy, shaping the feature, shaping the solution to the problem kind of independently. I think those are things you probably care a lot about. So how is your manager going to kind of help you maintain that autonomy while also knowing that the culture is going to shift? Dave Hauenstein: You're probably going to be the team is going to take on the problem versus the individuals. What does that mean for you? How is your manager and your organization looking out for you to make sure that you still have autonomy, that you can still make a big impact in the way that you probably did as a five or six person team? I think that's really, really important. Your manager has to, I don't know what the right way of framing this is, but I think managers should take an individualist approach to the people that they manage versus treating everybody exactly the same. Dave Hauenstein: That's what I think equity is about. So thinking about the specific circumstances a person is in and kind of working with them to create the same kind of impact that they would want to have. So I would say that's probably the most important thing. If you're in that situation and the organization is about the scale around you, how is your manager going to help you maintain that autonomy that impact as the org grows and changes? Brendan: Yeah. That's great. Dave, I think that's probably a good place to wrap up. Thank you so much for joining us on PodRocket today. Is there anything that you want to plug for our listeners or point them at? Dave Hauenstein: Yeah. I mean, if you are interested in Particle Health and want to come work with me, reach out. I'd love to talk to you. Otherwise, that's it. Thank you so much for having me. I loved this conversation. I feel like there's 10 more topics we can talk about. But appreciate you guys having me. Thank you. Brian: Thanks for listening to PodRocket. Find us at PodRocketPod on Twitter or you could always email me even though that's not a popular option. It's brian@logrocket.